GitHub found that exposing more than 100 tools made agents worse because their context windows filled up and the agents became confused and forgetful.
2
The remote server uses OAuth, scope-based tool filtering, a stateless architecture, and Redis session storage so it can handle changing configurations across horizontally scaled instances.
3
GitHub is moving toward automatic server discovery and compositional tool use, while still testing ways to make large tool collections usable without forcing users to configure them manually.
Summary
Sam Morrow describes how GitHub built and scaled its remote MCP server after the public launch of its local server. The first problem was tool growth. More than 100 tools made agents less effective, so GitHub grouped tools, reduced initial context, shortened API responses, and combined multi-step operations behind intent-based tools. Morrow is direct about the limits of configuration: most users kept the default settings even when better tool-selection options existed. Security is another major concern. GitHub supports OAuth 2.1 and PKCE, filters tools according to token scopes, and uses step-up authorization when a user needs more access. The production server is stateless, creates an SDK server instance for each request, and uses Redis for session storage. GitHub reports millions of downloads and millions of weekly tool calls. Morrow expects automatic discovery and compositional tools to make thousands of tools practical, although the current ecosystem is still experimental.
GitHub's tool collection grew faster than agents could use it
After GitHub's public launch, community contributions quickly expanded its platform coverage. The server picked up more than 100 tools across repositories, issues, pull requests, Actions, projects, and other areas. Morrow says agents became worse after about a month of feature growth because their context windows filled more quickly. The problem was not simply the number of capabilities. The tools and their descriptions were being placed directly into the agent's context, where too much information made agents confused and forgetful. GitHub did not want to remove useful individual tools because its users have very different workflows. That left the team looking for ways to reduce context while preserving access.
Tool sets helped technically, but most users did not configure them
GitHub added tool sets, which group related product tools so users can choose the areas they need. The team also tried dynamic tool selection, where an agent discovers a set and enables it when needed. Morrow built an unreleased retrieval-based version for semantic tool search and discovery. These approaches did not solve the default-user problem. Most people did not edit the JSON configuration, so they continued to load the default collection. Morrow connects this to missing or rejected grouping features in the MCP specification and to client limitations. GitHub's read-only mode illustrates the gap. About 17% of users use it, but clients generally do not expose the corresponding hint as a way to filter servers.
Reducing both input and output tokens made the server easier for agents to use
GitHub studied how people used the remote server and made the initial tool collection more specific to common cases. Morrow says this reduced the initial context load by about 49%. Grouping CRUD tools reduced it further, with the default configuration reaching roughly 40 tools and allowing users to expand or contract the selection. The team also shortened tool responses. In his list-pull-requests example, tailoring the returned fields cut output token use by more than 75%. Morrow describes token use as a moving target because the team keeps changing the server. GitHub has not ruled out approaches such as code mode, which could move more of the interaction into generated execution rather than exposing every operation directly.
Intent-based tools reduce failures by doing several API calls inside the server
GitHub also examined why tool calls failed and reports a success rate of roughly 95% or higher. Some failures remain unavoidable because agents may hallucinate repositories where they lack write permission. Other failures can be reduced by encoding the agent's intent into the tool surface. A server-side operation may perform five API calls when that produces a more reliable result. Doing those calls inside the server avoids extra agent round trips, saves context, and saves time. GitHub also began running evaluations to test tools against one another. Morrow says a description that makes an agent call a tool too often is as problematic as one that makes it avoid the tool. The goal is for tools to be selected at the right times within the whole tool pool.
OAuth and PKCE make the safer remote connection path easier to choose
Morrow describes plain-text access tokens as a serious MCP security problem. They are often stored where the agent can read them, remain valid for a long time, and have more permissions than necessary. GitHub chose remote HTTP and supports OAuth 2.1 so users do not need to download a local runtime. Morrow's team helped add proof key for code exchange, or PKCE, to GitHub's authorization server for client applications. GitHub considered dynamic client registration and rejected it because a proper implementation could create unbounded app records, complicate rate-limit grouping, and lack a reliable application identity. Morrow says GitHub is considering client ID metadata, which could make login easier, but he does not promise that support yet.
Prompt injection remains possible when powerful tools can reach private data
Morrow discusses an Invariant Labs demonstration of a prompt-injection exfiltration attack involving GitHub's MCP server. He accepts that GitHub provides tools that can enable this kind of attack when users enable them all, while also saying the problem applies to almost any agent setup. The usefulness of an agent can conflict directly with protecting private information. GitHub users have very different security requirements, from air-gapped GitHub Enterprise Server instances to agents running with broad token access. The server therefore has to accommodate different risk profiles while the wider agent ecosystem works on defenses. Morrow is clear that prompt injection and the related attack pattern are not solved, and that MCP alone does not create the problem.
Token scopes filter tools and allow access to increase only when needed
GitHub uses authorization information to reduce both risk and wasted context. When a user connects with a personal access token, the server immediately filters the available tools according to that token's scopes. OAuth connections can use step-up authorization. If a requested operation needs another scope, the server can return a scope challenge, ask the user for permission, and continue the call instead of failing outright. Morrow gives VS Code as an example. Its existing GitHub token may not have every permission required by a tool, so the user can start with a clean installation and approve broader access later. Server tokens also remove user-specific tools when no user is present, which eliminates recurring failure sources.
A stateless server with per-request setup supports horizontal scaling
GitHub runs its remote MCP server as a completely stateless service and uses Redis for session storage. Morrow contrasts this with MCP servers that keep a stateful process in a single instance. For each request, GitHub creates a new SDK server instance and adds the tools allowed by the request's configuration and policies. This lets the server build exactly the tool surface the client is permitted to use without relying on session affinity. Sessions are generally used to identify the client identity reported through MCP, rather than to hold the server's working state. Morrow says the service handles around 7 million tool calls per week and has scaled without session affinity. The per-request construction also fits GitHub's dynamic tool and permission filtering.
GitHub is testing human review and more compositional tool use
GitHub's Insiders mode exposes selected feature flags to people who want to try experiments. Morrow demonstrates MCP apps as a human-in-the-loop pattern. An agent can generate an issue, then give the user a chance to edit it before posting. He says this matters when the wording and reception of an issue are important, especially in professional open-source work. Looking ahead, he expects server discovery to become automatic and tool use to become more compositional. Tools could be piped into one another or stream data between operations. He points to Cloudflare's code mode, Anthropic's tool search API in Claude Code, and a similar API from OpenAI. Morrow expects thousands of tools to become normal, although users should not need to understand MCP or manually select them.
"The utility of agents is in conflict direct conflict with kind of protecting this stuff and it's like it's an active space trying to work out how to prevent these problems, but it's not solved."11:21
Who should watch
You are building a remote MCP server and need a production architecture that can scale without session affinity.
Your server exposes many tools and agents are filling their context, choosing the wrong operation, or failing on simple requests.
You need to add OAuth, permission-aware tool filtering, or human approval without giving an agent more access than the user intended.
