Two scopes, two different purposes:
| Scope | File | For |
|---|---|---|
| Project | .mcp.json (committed) |
Shared team tooling |
| User | ~/.claude.json |
Personal / experimental servers |
Credentials use environment-variable expansion — ${GITHUB_TOKEN} in the config — so the configuration file itself commits safely to version control while the actual secret never does.
Tools from every configured server are discovered at connection time and available simultaneously. Combined with §3's tool-count effect, this means adding MCP servers casually — without pruning or scoping — degrades tool selection reliability across the whole agent, not just for the new server's own tools.
MCP resources are a distinct concept from tools: they expose content catalogs (issue summaries, document hierarchies, database schemas), giving an agent visibility into what's available without spending exploratory tool calls to discover it. Resources are for catalogs; tools are for actions.
Two judgment calls the exam tests directly:
- Enrich thin MCP tool descriptions so the agent doesn't quietly prefer a well-understood built-in instead. A one-line
jira_searchloses toGrep— the agent will search a local checkout rather than query the actual system of record, and the fix is strengthening the MCP tool's description, not removing the built-in. - Prefer community servers for standard integrations (Jira, GitHub, Slack) and reserve custom server development for genuinely team-specific workflows — building a bespoke server for a commodity integration is more effort than the problem warrants.
The discriminator: scope by who actually needs it — a whole team, or just you. And when an agent ignores an available MCP tool in favor of a built-in, the tool's description is the first thing to fix, not the built-in's availability.