What is a GitHub Org Context API?

A GitHub Org Context API turns your entire organization — every repo, owner, dependency, and review — into structured, LLM-ready context an AI agent can query in a single call. It’s the layer between raw GitHub data and the agents that need to actually understand your codebase.

Why the raw GitHub API isn’t enough

Agents are only as good as their context. The GitHub REST and GraphQL APIs return events and objects — commits, pull requests, files — not understanding. To answer “who owns the auth service?” or “what breaks if I change lib/db?”, an agent has to pull thousands of commits, blame every file, reconstruct the review graph, and stitch it all together — on every request.

• ›Events, not context. You get raw objects and have to compute the meaning yourself.
• ›Rate-limited. Rebuilding org context per request burns your GitHub quota fast.
• ›Rebuilt everywhere. Every tool and agent re-crawls the same organization, independently, and still ends up with text instead of relationships.

What “org context” actually means

A context API pre-computes the relationships and serves them as clean, cited JSON. EOS exposes six context surfaces over one org-scoped API:

• ›Ownership & expertise — GET /context/ownership — ranked owners of any file or module from real contribution history, plus a knowledge-concentration (bus-factor) signal.
• ›Architecture & dependency graph — GET /context/graph — modules, inter-file dependencies, and logical coupling (files that change together). Blast radius, answered.
• ›Contributor context — GET /context/contributors — per-person expertise and review history. Expertise and ownership, not productivity scoring.
• ›PR & review context — GET /context/pulls — the review graph: who reviews what, turnaround, and related past PRs.
• ›Semantic retrieval — POST /context/search — natural-language search over the org, returning LLM-ready chunks with citations to files, PRs, and people.
• ›Activity & hotspots — GET /context/activity — where change is concentrated right now.

Context, not raw events

The difference is pre-computation and relationships. Instead of crawling to guess who owns a path, an agent asks once:

curl "https://eos.dev/api/v1/context/ownership?repo=acme/app&path=services/auth" \
  -H "Authorization: Bearer eos_your_key"

— and gets ranked owners with evidence and citations. No crawl, no rate-limit math, no reconstruction. The API models the organization — people, ownership, dependencies, flow — not just the text of your code. That’s the line between a context API and a RAG-over-repo tool: RAG returns text chunks; a context API returns the org.

Built for agents: MCP and SDKs

The fastest way to give an agent org context is the official MCP server — every surface becomes a native tool, with zero glue code:

{
  "mcpServers": {
    "eos": {
      "command": "npx",
      "args": ["-y", "@eos-ai/mcp-server"],
      "env": { "EOS_API_KEY": "eos_your_key" }
    }
  }
}

Prefer code? The TypeScript SDK wraps every surface with types:

import { EosClient } from "@eos-ai/sdk";

const eos = new EosClient({ apiKey: process.env.EOS_API_KEY });
const { data } = await eos.context.ownership({ repo: "acme/app", path: "services/auth" });

And webhooks push context-change events, so your agents always call fresh context.

Who it’s for

• ›Platform & DevEx engineers standardizing how internal agents understand the codebase.
• ›AI dev-tool builders who need org context as a multi-tenant backend instead of rebuilding it in-house.
• ›Anyone wiring an agent — Claude, Cursor, Copilot — to real org knowledge.

Start in minutes

The free tier includes the full context surface and the MCP server — 5,000 context requests a month, no credit card. Grab a key, drop in the MCP server or the SDK, and make your first call. The developer overview walks through it end to end.