How do I make sure Claude actually calls the context MCP without every engineer editing their CLAUDE.md?

To make Claude call an MCP on every engineer's machine without anyone editing CLAUDE.md, ship three things from the organization: the server, the instruction to use it, and the server's own description of when it applies. Claude Code has an org layer for each. Managed settings are the policy file or admin-console settings that every machine in your organization reads, and they sit above anything a user or repo sets. The per-repo file stays untouched.

Why Claude skips a server it already has#

Often the server is connected and Claude never thinks of it. Claude Code defers MCP tools by default. Anthropic's docs say "only tool names and server instructions load at session start," and Claude searches for the full tool when a task seems to need it (Claude Code MCP docs). Claude decides from a tool name and a short paragraph. For example, a server named search that describes itself as "search tool" gives Claude no reason to call it before a refactor, so Claude opens the codebase instead.

The usual fix is a line in every CLAUDE.md, which is the per-person work you want to avoid, and it drifts. Our post on rules files vs a context engine covers why copies of one rule decay across repos, and what one instructions file can't fix covers the limits of the file itself.

Provide the server from managed settings#

Claude Code has a managed setting built for this. List the server under managedMcpServers and "every user gets the remote servers you list and keeps their own" (Claude Code managed MCP docs). Users "can't edit or remove a provided server," and it wins over a same-name server elsewhere. Leave out headers and each engineer signs in with OAuth as themselves. The key needs Claude Code v2.1.259 or later.

json{
  "managedMcpServers": {
    "context": { "type": "http", "url": "https://context.example.com/mcp" }
  },
  "claudeMd": "Before planning or changing unfamiliar code, call the context MCP's research tool and cite what it returns."
}

The claudeMd key carries the instruction in the same file. Anthropic's memory docs say it holds "managed CLAUDE.md content directly inside managed-settings.json" and loads "before user and project CLAUDE.md." Developers can exclude other CLAUDE.md files, "but not this one" (Claude Code memory docs). Deliver it by MDM, as a managed-settings.json at the system path, or from the claude.ai admin console. Only the admin-console route reaches cloud sessions (Claude Code settings docs).

One caution: Anthropic calls the managed CLAUDE.md guidance, not enforcement. It puts the line in front of Claude on every machine but does not force the call, and a session started with CLAUDE.md loading off skips it. For the hook that blocks an edit until the research call has run, see why agents ignore CLAUDE.md rules.

Or ship it as a plugin, so the skills come along#

A plugin bundles the server with skills that teach Claude when and how to use it. A skill is a SKILL.md file that Claude loads when its description matches the task. Force-enable the plugin with two managed keys: extraKnownMarketplaces registers the marketplace and enabledPlugins installs it "at the start of the user's next session." Disabling it at their own scope "doesn't stop it from loading, because managed settings take precedence" (Claude Code plugin admin docs).

json{
  "extraKnownMarketplaces": {
    "unblocked-skills": { "source": { "source": "github", "repo": "unblocked/skills" } }
  },
  "enabledPlugins": { "unblocked-skills@unblocked-skills": true }
}

Put the instruction in a skill, not a file. Claude Code "doesn't load a CLAUDE.md at the plugin root," and the plugin docs say to write instructions as skills (Claude Code plugin components docs). Unblocked's public plugin works this way: its manifest declares the hosted MCP server and ships skills such as unblocked-context-research that tell the agent when to research first (unblocked/skills). Agent skills vs rules files explains which layer should hold what.

Let the server describe itself#

The cheapest fix lives on the server. The MCP specification gives every server an optional instructions field: "natural-language guidance for LLMs on how to use this server effectively" (MCP specification). With tool search on, Anthropic says this field "help[s] Claude understand when to search for your tools," and asks authors to state what tasks the tools handle and when Claude should search for them (Claude Code MCP docs).

Wording changes what gets picked. In a February 2026 study of functionally equivalent servers competing for the same task, standard-compliant descriptions reached a 72% selection probability against a 20% baseline (Wang et al., arXiv). Two limits matter. Claude Code cuts server instructions at 4,096 characters, so the trigger belongs in the first sentence. And if one tool must be visible on every turn, the server author can mark it to load upfront with "anthropic/alwaysLoad": true in the tool's _meta. Do it for one tool, since each upfront tool costs context.

If you run the server yourself, rewrite its instructions as a trigger, for example: "Call this before planning a change, debugging an unfamiliar error, or answering why code works the way it does." If you buy it, read what it sends and what skills ship with it. Unblocked's docs pair each MCP tool with a skill that encodes "when to reach for each tool" and suggest a near-identical instruction line (Unblocked skills docs).

Check one laptop, then the fleet#

1. On a managed machine, run /status and look for the managed source under "Setting sources," then run /mcp and look for the server under Managed MCPs.
2. Give Claude a task where the code alone gives the wrong answer. Watch whether it calls the research tool before its first edit.
3. For the fleet, turn on OpenTelemetry export and set OTEL_LOG_TOOL_DETAILS=1 in the managed env block. Claude Code then records "MCP server and tool names in tool events," so you can count research calls per engineer per week (Claude Code managed MCP docs).
4. Contact any team with zero calls. Check for clients older than v2.1.259, which ignore managedMcpServers.

GitHub Copilot's enterprise managed-settings.json takes the same plugin keys. There, enabledPlugins "defines plugins that are automatically installed or blocked for all enterprise users," next to extraKnownMarketplaces and an allowedMcpServers allowlist (GitHub Copilot managed settings docs). Confirm Copilot reads your plugin's format before you rely on it, and see everyone connects their own MCP servers for mixed-tool teams.