When MCP is worth it
MCP is for data and tools that are not just files in git: issue trackers, docs drives, a database you already allow.
If the job is only read and edit the repo, you do not need MCP yet.
Each server expands the blast radius. One server you understand beats five you copied.
Add, then prove it loaded
Follow today's official MCP pages for Claude Code. Config shapes move. Copy field names from the page you have open.
Prefer a project-level config you can PR if the team shares the server. User-level is fine for a personal experiment.
Restart or reload, then ask a read-only question that only that server can answer.
- Pick one server.
- Add it from official docs.
- Reload.
- Ask a read-only question.
Project versus user
Project config is the team contract. User config is your laptop. Do not leave a production token only in a personal file and then wonder why CI cannot see it.
If both define the same server name, you will debug ghosts. Keep one.
- One place per server name.
- PR project servers.
- Document the env var names, not the values.
Secrets stay out of git
Tokens live in the environment or a secret store. The config should name the variable, not the value.
Never paste a live key into the chat so the agent can 'just try it'.
Rotate anything that appeared in a screenshot or a log.
- Env var, not a literal.
- gitignore anything local.
- Rotate on leak.
Keep the first server small
Read-only docs search or a constrained issue reader is enough. A server that can email the company is not a week-one toy.
If a tool returns a novel, you will blow the context window and get worse edits.
- Read-only first.
- Narrow queries.
- One server.
Approve tool calls on purpose
Treat MCP tools like shell. A 'list' is not a 'delete'. Read the argument list.
Always-allow is a later luxury for a server you have already audited.
- Read the tool name.
- Read the path or query.
- Deny if it is larger than the job.
When it does not appear
Wrong directory, JSON typo, missing env, or the process cannot spawn. doctor and the client's MCP list are the first cut.
This site also has a generic debug-MCP guide. Use it after Code-specific checks.
- Valid config syntax.
- Env present in that shell.
- Server process actually starts.
MCP-stage mistakes
Pasting a team's full server list, including staging URLs.
Enabling write tools before a read-only success.
- Keys in JSON.
- Five servers on night one.
- No deny practice.
Done looks like this
You can name the server, the env var, and one read-only question it answered.
- One server.
- No secrets in git.
- Read-only proof.
- You know how to remove it.
- Writes still gated.
Next: compare Codex without a brand fight
The comparison chapter is about week-one fit, not a scoreboard.
If MCP is still red, jump to troubleshooting instead.