Too many MCP tools? A smaller Claude Code configuration to try first

If Claude Code has too many MCP tools, first disable servers the current task does not need and narrow the remaining server's toolsets. Check tool discovery before changing models: current Claude Code can defer tool definitions, so a long list of connected servers does not prove that every schema is occupying the context window.

This is a configuration walkthrough for a read-only GitHub issue-triage job, checked on 31 October 2026. It is not a model benchmark, a claimed speedup or a promise of more subscription allowance. For the research behind overloaded agents, read our heavy-tool-load explainer.

Is the problem too many tools or a failed connection?

Start with one narrow task: find open issues about a named bug in one repository and return issue links, without commenting or editing anything. Keep the repository, prompt and model unchanged while you diagnose it.

Open /mcp inside Claude Code. A server needing authentication or blocked by project approval needs a connection fix, not a smaller context. Anthropic's MCP reference distinguishes these states and documents project-specific server toggles. Disable unrelated servers there rather than deleting their configuration.

Record the tools and context view before you change anything. Anthropic's cost-management guide recommends /context to inspect context consumption and /mcp to manage servers. Note which definitions are deferred rather than treating the installed-tool count as the loaded-token count.

Observation	First change to try	What it does not establish
Server needs authentication	Complete that server's normal sign-in	That the model cannot use tools
Unrelated servers are enabled	Toggle them off for this project	A new account permission boundary
GitHub exposes more capabilities than triage needs	Restrict toolsets and enable read-only mode	That every readable issue is trustworthy
Needed tool is deferred	Check discovery and make a specific request	That the tool is missing
Correct tool returns a huge body	Request narrower results or inspect a smaller scope	That shrinking the catalog alone fixes output size

How do you narrow GitHub MCP to read-only issues?

GitHub's remote-server documentation supports an issues toolset and a read-only header. A dedicated project configuration can look like this:

{
  "mcpServers": {
    "github-triage": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "X-MCP-Toolsets": "issues",
        "X-MCP-Readonly": "true"
      }
    }
  }
}

Merge this entry into your existing project .mcp.json; do not overwrite other entries. If you already have a broad GitHub connection, disable it during the comparison so you do not accidentally retain its tools alongside the restricted connection. Approve the project configuration and complete the server's documented authentication flow. No token belongs in the shared JSON example.

This configuration requests the issues group, not a universal three-tool limit. Inspect the resulting tool list after connecting. GitHub documents that unknown toolset names can be ignored, so a connected server alone is insufficient proof that your intended filter applied.

Need repository-file inspection as well? Deliberately add repos to the comma-separated toolsets and check the new inventory. GitHub's main README also documents exact individual-tool selection and says toolsets plus individual tools are additive. Do not assume an extra tool selection replaces a broad toolset.

Should you turn off Claude Code tool search?

Usually, that is the wrong first experiment. The current Anthropic MCP reference says unset or true defers MCP tools on supported models and deployments; false loads them upfront. auto is a threshold mode, not another spelling for the current unset default.

Leave the default alone while testing server scope. If your environment has an explicit ENABLE_TOOL_SEARCH=false, investigate why before removing it: gateway compatibility, managed policy and deployment support can affect discovery. Deferral reduces upfront definitions; filtering removes unneeded capabilities. They solve different problems.

Also check for alwaysLoad entries. A server deliberately configured to load upfront should be small and necessary. Do not copy someone else's description-length or threshold settings without first inspecting your own installed version and context view.

How do you compare the smaller configuration fairly?

Use fresh sessions and the same read-only prompt. Save the first result, then repeat after changing only the server scope. Our suggested scorecard is: correct repository, relevant issue links, no write attempts, no authentication failure, and a final answer supported by the returned issues. Record context usage and elapsed time, but do not interpret one faster response as a reliable performance gain.

We checked the example's JSON structure and header values against the maker documentation, not against an authenticated GitHub server. No accuracy or token-saving result is claimed. To test runtime behavior yourself, verify the exposed tools before allowing the agent to begin; if the required issue search is absent, fix the configuration rather than accepting an invented answer.

Does a smaller catalog change billing or safety?

It does not grant more plan capacity or pay a connected service's bill. Keep the Claude account route separate from server authentication. Our Claude subscription integration guide explains that boundary; apps on your Claude plan is the directory.

For example, Conductor is a workspace option, not proof that every embedded runtime shares these exact settings. Inspect the actual Claude Code process before applying this recipe.

Finally, read-only is not permission to expose every private repository. Anthropic's security guidance treats external tool content as a potential prompt-injection source. Restrict account access, keep secrets out of prompts, and review returned links. A smaller catalog helps focus the task; it does not make the retrieved material authoritative.