Scaling GitHub for your Agents — Sam Morrow, GitHub

What happens when adding the tools users request makes their agents worse? That was the problem facing the GitHub MCP Server, whose development Sam Morrow leads. GitHub open-sourced its local server in April 2025; by this talk, it had reached its first anniversary. Morrow reports that it was GitHub’s most-starred repository during its launch week, bringing a surge of contributions that filled gaps in platform coverage.

After roughly a month of additions, agents were becoming less effective at using GitHub and exhausting their context windows faster. Morrow recalls the tool count peaking above 100. The problem was not that GitHub lacked useful operations: it was that their definitions competed for space and attention before the agent had done any work.

Morrow points to LangChain’s February research on agent performance, consistent with the problem explored in Benchmarking Single Agent Performance. His distinction matters: more tools loaded directly into context do not necessarily make a better agent. Yet removing capabilities indiscriminately would leave users stranded. Repositories, issues, pull requests, Actions, and Projects all had legitimate users, and those users needed different subsets of GitHub.

The first response was to make tool exposure configurable. Morrow added toolsets, grouping related product tools so users could select what they needed. He also added dynamic discovery, allowing agents to find toolsets and enable them in chunks. A further prototype used retrieval for semantic tool search, but that version was never released.

These mechanisms did not remove the context problem because users kept the default settings. Editing a little JSON was enough to customize the server, but most people did not do it. Morrow also describes a protocol and client gap: several proposals for grouping tools in MCP had been rejected, leaving server-specific modes and configuration to supply behavior that might otherwise have been shared across clients.

Morrow reports that roughly 17% of users used GitHub’s read-only mode. That mode mapped directly to the MCP annotation readOnlyHint. A tool’s annotation fragment can express the relevant distinction in JSON:

{
  "annotations": {
    "readOnlyHint": true
  }
}

The annotation gives a client a basis for filtering its tool list; it does not create the filtering interface by itself. In Morrow’s account, clients were not exposing that choice, although some gateways might have begun doing so. For enterprise users who wanted only read operations, a standard annotation was therefore still being surfaced through a GitHub-specific mode.

If most people use the defaults, improving the defaults reaches them without requiring a setup task. GitHub examined remote-server usage and focused the initial tool surface on common workflows. Morrow reports an approximately 49% reduction in initial context load from that usage-driven change. Subsequent grouping of create, read, update, and delete operations reduced the load further. He describes the resulting default configuration as approximately 40 tools, with users still able to expand or contract it.

Tool definitions were only one source of context consumption. Every result returned to the agent could add another large payload. In the cited list_pull_requests example, Morrow reports that tailoring the returned fields removed more than 75% of output tokens. This was a separate optimization from reducing the initial tool list: the first saves context before work begins; the second saves it during the workflow.

These figures describe an evolving implementation, not fixed costs for GitHub MCP. Morrow says some optimization details were already dated when he presented them, and the server could differ substantially from what a user had tried a few months earlier. More advanced approaches, including code mode, remained under internal experimentation.

Reducing context did not eliminate execution failures. Morrow estimates that tool-call success was above 95% at the time of the talk. Agents could still hallucinate or attempt writes without knowing which repositories permitted them. The reported context reductions and success rate measure different things; the talk does not specify their tokenizer, baseline versions, measurement window, or success-rate denominator.

A useful tool can represent an agent’s intent rather than a single API endpoint. GitHub found preventable errors that could be handled inside the server. An operation might require five API calls to make it robust, but the server could perform that sequence behind one tool call. The agent then avoided repeatedly interpreting intermediate results and choosing the next API operation, saving round trips, context, and time.

The team also began running evaluations the previous year. Morrow refers to a companion article by his colleague Ksenia Bobrova, but the key design lesson is about evaluating tools together. A description optimized in isolation can make a tool win every selection, including requests it should not handle. A description that never attracts a call fails in the opposite direction. Evaluation must test both appropriate selection and appropriate non-selection within the competing tool surface.

Credential handling presented another defaults problem. Many MCP users had plaintext access tokens stored where their agents could reach them. Those tokens were frequently long-lived and overprivileged. Morrow does not frame this as a deliberate user preference: easy configuration and secure storage are difficult to deliver together. Clients need system keyrings or encrypted storage, as VS Code uses, so connecting a tool does not leave credentials exposed in ordinary configuration.

Remote HTTP offered a way to simplify connection without requiring users to install a local runtime. Morrow dates that protocol support to April 2025. He describes GitHub’s remote server as supporting OAuth 2.1 and says his team helped add Proof Key for Code Exchange, or PKCE, to GitHub’s authorization server to strengthen client authentication flows. The authentication behavior and experimental availability described here reflect his April 2026 account, rather than a current API compatibility guide.

OAuth did not automatically become the path of least resistance. Clients expected dynamic client registration, which GitHub considered and rejected. Morrow identifies three operational problems:

• Registration growth: dynamically created applications could produce an unbounded application database.
• Rate limits: the service needed a defensible way to group applications into rate-limit buckets.
• Application identity: dynamically registered clients did not provide a reliable app identity.

Those concerns made automatic registration a poor fit for GitHub’s authorization service, even if it simplified initial client setup.

Morrow presents client ID metadata as MCP’s emerging direction for easier login. He was advocating support inside GitHub, but explicitly made no commitment that it would ship. The desired user experience remained a secure connection that required less manual configuration.

Morrow accepts Invariant Labs’ GitHub MCP exfiltration demonstration as a valid attack. Enabling the relevant tools can give an agent the capabilities needed to retrieve private information and expose it elsewhere. The risk comes from the agent’s combination of access and actions, and extends beyond GitHub MCP—or MCP at all.

He points to Simon Willison’s lethal trifecta framing for this broader problem. Useful agents need access to information and the ability to act, but those same capabilities create routes for misuse when the agent encounters hostile instructions. Morrow describes that conflict as unresolved.

There is also no single deployment posture to optimize for. GitHub serves users with air-gapped Enterprise Server installations as well as cloud agents operating with extensive token access. Supporting those different environments means treating permissions and tool exposure as part of the product, while users continue experimenting with how much autonomy they are willing to grant.

Authorization can reduce both security exposure and wasted context without asking users to tune another configuration file. With a personal access token, GitHub MCP automatically filters available tools according to the token’s scopes. The credential itself supplies the information needed to narrow the tool surface.

OAuth supports a different path: step-up authorization. When an operation needs a missing scope, the server can issue a scope challenge rather than immediately ending the workflow:

1. The client receives the challenge for additional authorization.
2. The client asks the user whether to grant the scope.
3. If the user approves, the tool call can continue.

Morrow describes working with VS Code on this flow because it already held a GitHub token. A clean installation could start with that token and request additional permissions when needed, instead of requiring every possible permission up front.

Server tokens introduce a third case. A token used by an automated environment such as Actions may have no associated user, making user-specific tools inappropriate. Removing those tools prevents predictable failures and keeps unusable definitions out of context.

The resulting tool list reflects what the caller can actually do, rather than everything the server knows how to expose.

GitHub’s remote deployment uses stateless serving processes, Redis for session storage, and a conventional observability and debugging stack. That architecture can look unfamiliar if an MCP implementation begins as one long-lived, stateful server process. The distinction is between the lifetime of an SDK server object and the lifetime of the service handling traffic.

For every request, GitHub creates a new server instance in the SDK sense and adds its tools at the beginning. Configuration determines what the caller requested; permissions and applicable policies determine what the caller may use. Rebuilding the tool surface for that request makes these dynamic differences explicit without requiring a persistent server object for each user.

Morrow reports around seven million tool calls per week at this point in the talk, without session affinity. Requests do not need to return to the same serving process. Sessions primarily preserve the self-reported client identity supplied through MCP, allowing GitHub to understand which clients people use. Session storage therefore supports client identification without becoming a requirement to keep a particular process attached to a particular conversation.

GitHub exposes selected experiments through Insiders Mode, which activates feature flags for users who opt in. Morrow’s example is MCP Apps, available through Insiders but not generally released in his account.

The example gives the user a chance to edit an AI-generated issue before posting it. That review is especially useful in professional open source, where the wording and substance of an issue affect how maintainers receive it. The generated content is still a draft: the person can inspect and revise it before it becomes their public contribution. Morrow says he came to value this interaction because he cares how his issues are received and does not want them dismissed as bot-generated submissions.

Morrow’s forecast shifts from manually configuring a tool list toward automatic server discovery and compositional execution. Tools could behave more like Bash commands: one operation feeds another, and data streams through the sequence without requiring the model to mediate every intermediate result. He identifies Cloudflare’s Code Mode as one approach in that direction.

He also points to Anthropic’s tool-search API, which he describes as having recently arrived in Claude Code, and a similar API from OpenAI. If agents can discover relevant capabilities when needed, thousands of available tools could become normal without loading all of them into the initial context. That is a prediction, and it could reverse some earlier decisions to expose fewer tools.

In that future, users might express what they want to accomplish without knowing what MCP is; authorization setup and tool selection would happen with much less manual intervention. Morrow says the ecosystem is still experimental. He highlights harnesses such as Pi as opportunities to build unconventional clients and optimize these interactions, encouraging experiments that might spread as widely as the next Claw.

The closing figures show the scale of adoption and the community workload behind it. Morrow reports more than 11 million Docker downloads of the standard I/O server, which he says was not the most-used version. He also reports 126 contributors and more than 2,300 issues and pull requests. Separately, he describes the contribution pace as more than seven issues and pull requests per day for over a year. He tries to inspect almost everything eventually and continues to invite contributions.

Morrow reports almost 4,000 forks and nearly 30,000 stars, with tool traffic fast approaching eight million calls per week. That closing traffic snapshot follows his earlier figure of around seven million. He is interested in the unusual experiments people have built in forks without contributing them back. Growing activity creates pressure for maintainers and GitHub itself, but his invitation is to keep opening issues and pull requests.

The final audience question returns to piping tool calls. Morrow suggests a small, concrete experiment:

1. Take an MCP server’s read-only tools.
2. Wrap them in a command-line interface.
3. Give the CLI proper help text.
4. Let an agent use it and observe how it performs.

He describes this approach as surprisingly effective, while acknowledging that MCP CLI patterns are not fully worked out. It is a practical place to investigate composition: give the agent a discoverable command interface and see what it can accomplish with the tools already available.