Claude Code MCP servers: what to add first, and team rules
Claude Code adds MCP servers with claude mcp add, stores them at local, project or user scope, and asks before a project server loads. This page lists the servers worth adding first, the ones to hold back, and the permission rules that keep every MCP call reviewable.
What MCP does in Claude Code
Claude Code adds servers with claude mcp add and stores them in one of three scopes. Local scope is private to you in one project, user scope is private to you across projects, and project scope writes to .mcp.json in the repository root so the whole team gets the same servers through version control. In an interactive session, servers from .mcp.json show as pending until a person approves them, and approvals only count from a trusted folder, so a cloned repository cannot approve its own servers. Tool calls follow the normal permission system: allow, ask and deny rules use the form mcp__server__tool, or mcp__server for every tool on a server, and can be checked into .claude/settings.json. Organisations can set allowedMcpServers and deniedMcpServers in managed settings, which apply across every scope. The surrounding CLI loop, task brief, and reviewable diff live on CLI workflows.
MCP servers worth adding first
As of September 2026, these are the servers we see engineering teams use with Claude Code most. Each one exists as an official vendor server with a documented way to limit what it can do, and Claude Code lists Notion as its own HTTP example.
GitHub MCP server
Lets the agent read repositories, issues, pull requests, Actions runs and code scanning results without leaving the editor. Official server from GitHub, available hosted or self-run. Team rule: start with the --read-only flag and the repos, issues and pull_requests toolsets; enable write tools only for a named workflow.
Playwright MCP
Drives a real browser through accessibility snapshots so the agent can reproduce a bug or check a page after a change. Official server from Microsoft. Team rule: run it in isolated mode against local or staging origins, and treat any step that logs in or submits a form as an approval point.
Context7
Pulls current, version-specific library documentation into the run so the agent stops guessing at APIs. Published by Upstash, hosted at mcp.context7.com. Team rule: it only returns documentation, so it can sit on the default allowlist; keep the API key out of the shared config file.
Sentry MCP
Searches errors and performance data and reads issue context for the code the agent is fixing. Official server from Sentry, hosted at mcp.sentry.dev with OAuth. Team rule: scope the connection to one project, and keep the write scopes off until the team decides which triage actions the agent may take.
Linear MCP
Reads issues, projects and comments so the agent can work from the ticket instead of a pasted summary. Official server from Linear. Team rule: connect the readonly endpoint or the read OAuth scope first; issue creation and status changes stay with a person until reviewers ask for more.
Notion MCP
Searches and reads pages and databases, and can create or update them after OAuth. Official remote server from Notion; workspace owners control which clients may connect. Team rule: use a workspace connection limited to the engineering spaces the team actually reads, and keep page writes out of unattended runs.
Supabase MCP
Gives the agent schema and data access to a Supabase project, including Postgres queries. Official server from Supabase. Team rule: set read_only and project_scoped in the config and point it at a staging project, never at production.
Servers to keep off the default list
These are not bad servers. They are the ones teams add in week one and regret in week three, because they carry secrets, write to shared systems, or nobody can say who maintains them.
Slack MCP
The official Slack server can search and send messages as the connected user, and Slack requires workspace admins to approve every MCP client. That is a decision for the team and an admin, not a line in a repo config.
Figma MCP with canvas writes
The Figma server is useful for reading design context, but its write-to-canvas tools change design files other people own. Keep it on read tasks until designers agree on what the agent may touch.
Filesystem with broad roots
The reference filesystem server from the Model Context Protocol project restricts operations to allowed directories, but only if someone sets them narrowly. A home directory root turns every run into a full-disk agent.
Unmaintained database servers
The reference Postgres, SQLite and Redis servers were moved to an archived repository, and many community forks carry a connection string in plain text. Prefer a vendor server with a read-only flag, or none at all.
Team rules that make MCP reviewable
The point of these rules is that a reviewer can tell what Claude Code did, which server did it, and whether that was inside what the team agreed. None of them slow a run down once they are written.
One allowlist per repository
Write the approved servers into the shared config the team already version controls, and treat a new server like a new dependency: a pull request, a named owner, and a reason.
Read-only by default
Where the server offers a read-only flag, endpoint or scope, that is the starting point. Write access is a separate decision with a named workflow attached.
Approval for writes
Anything that creates a ticket, posts a message, changes a design file or writes to a database goes through a prompt or an explicit allow rule that a reviewer can see in the config.
Record which server produced which change
Ask the agent to name the tools it called in the pull request description, and keep the transcript or log attached, so a reviewer can trace a change back to a server call.
Review the diff before merge
The transcript shows what the agent thought it did. The diff, the test output and the tool log show what happened. Reviewers sign off on the second set.
Where training fits
A list like this only holds if the whole team applies it the same way. In the two-day workshop we set the allowlist up in the team's own repository with Claude Code, run real tasks against it, and write the rules above into the config and the review checklist. Delegate, Review, Own is the model we use to decide which MCP calls an agent may make on its own, which need a prompt, and which stay with an engineer, so the standard survives after the trainers leave.
Official references
Current product documentation we use when shaping this training topic.
Selected research
Representative field notes connected to this topic.
Claude Code 2.1.139 team conventions
May 17, 2026 · Claude Code 2.1.139 team conventions: a CLAUDE TOC, red-folder approvals, data-class tags on MCP connectors, and a weekly retro note.
Agentic Coding Breaks At The Handoff
Most teams do not lose control when an agent writes bad code. They lose it when nobody can explain the change ten minutes later. The handoff is the interface.
AI coding agents workflow guardrails for browser control
May 11, 2026 · Workflow guardrails for AI coding agents with browser control: child receipts, decision stubs, scope ledgers, and a supremacy clause reviewers can audit.
Claude Code MCP Server Ownership
Oct 11, 2026 · Set ownership, permissions, and rollout rules for MCP servers in a Claude Code team workflow.
searxng-ai-kit Turns SearXNG into an MCP Server
Jul 12, 2026 · Evaluate searxng-ai-kit on a public dependency question. Check query privacy, primary sources, exposed tools and local tests before accepting a patch.
CLAUDE_CODE_STOP_HOOK_BLOCK_CAP in Claude Code 2.1.143
May 16, 2026 · What CLAUDE_CODE_STOP_HOOK_BLOCK_CAP means in Claude Code 2.1.143, and how to investigate a repeatedly blocking Stop hook.
Related training topics
Have you tried these?
Run the change on one branch. The methodology puts that in Review: an engineer still owns the merge. Training is the team version of that step.
Bring this into your team
We tailor the training to your codebase, adoption stage, and review standards.