Claude Code MCP Security Checklist

Every MCP server you attach to Claude Code adds a new set of tools, a new credential and a new source of untrusted text, so review each one the way you would review a supplier integration.

Why MCP needs its own checklist

The Model Context Protocol is the standard way to give Claude Code tools beyond the file system and shell: a ticketing system, a database, a CRM, a browser. That is useful and it is also the point where a coding assistant becomes an agent acting on business systems. A server can run code on the developer's laptop, hold a live credential, and return text that the model will read as if it were part of the conversation. None of those three things is a reason not to use MCP. All three are reasons to check before connecting.

The checklist

1. Know who publishes the server and how it runs. A remote HTTP server runs on the vendor's infrastructure; a local stdio server is a program executed on the developer's machine, often via npx or uvx, which means it is arbitrary code from a package registry. Prefer the vendor's official server, pin versions where you can, and treat an unknown community server as you would any unknown dependency.

2. Choose the scope on purpose. Claude Code stores servers at local scope (this project, you only), user scope (all your projects) or project scope (a .mcp.json file committed to the repository). Project scope is the right place for a team server, and Claude Code asks each person to approve servers from .mcp.json before using them in interactive sessions. Note that claude -p and cloud sessions cannot show that prompt, so a server committed to the repository loads without asking there. Use disabledMcpjsonServers to block a specific one regardless of mode.

3. Keep secrets out of committed files. .mcp.json supports ${VAR} and ${VAR:-default} expansion in the command, arguments, environment, URL and headers. Reference the token from the environment; never write it into the file. Where the server supports OAuth, use that rather than a static header, because Claude Code refreshes and revokes it through /login and /logout.

4. Restrict OAuth scopes. If the server's authorisation server advertises more scopes than the workflow needs, set oauth.scopes in the server configuration to the approved subset. A server that only needs to read tickets should not hold write access.

5. Read the tool list before you trust it. Tool names and descriptions are sent to the model as text and can carry hidden instructions. Run /mcp after connecting, inspect the tools, and reject a server whose descriptions ask the model to do anything beyond the tool's function. The MCP tool poisoning checklist covers the specific patterns.

6. Put permission rules on MCP tools. Rules use the form mcp__server for every tool from a server or mcp__server__tool for one tool. Allow the read tools you have reviewed, put the tools that change records under ask rules, and deny anything the workflow does not need. Deny rules are evaluated first and cannot be overridden by an allow rule at another level. Server authors can also mark a tool as always requiring approval, which Claude Code honours even in bypass mode.

7. Treat tool output as untrusted input. A ticket body, a web page or a database row returned by an MCP tool can contain text that tries to redirect the agent. Keep the instructions in your prompt and settings, and keep the review gate for actions that send, publish or delete. Our note on MCP audit logging covers what to record.

8. Decide who may add servers for the organisation. Administrators can deploy a fixed server set with a managed MCP configuration, provide approved servers to everyone, and restrict others with allow and deny lists. Connectors configured in claude.ai flow into Claude Code automatically; on Team and Enterprise plans only admins can add them, and the organisation can set individual connector tools to ask on every call or block them entirely. disableClaudeAiConnectors turns that feed off where a repository should not see them.

9. Check status and keep a register. claude mcp list shows configured servers and warnings, including a missing environment variable or the same server name defined with different endpoints in two scopes. Keep a short register per repository: server, publisher, scope, credential type, scopes granted, owner, review date. It takes ten minutes and answers most audit questions.

10. Test removal and revocation. claude mcp remove <name> takes a server out; /logout removes stored MCP logins along with your own. Revoke the token on the vendor side as well. Do the exercise once during the pilot so you know it works before you need it in a hurry.

Where to start

Most teams connect one or two servers and stop. That is fine, and it is a good reason to do the checklist properly for those two rather than writing a policy for hundreds. If the goal is to give an agent access to an internal system that has no server yet, the MCP server design page explains how we build one with the permissions designed in from the start rather than bolted on afterwards.

Source basis

• Claude Code docs: connect Claude Code to tools via MCP
• Claude Code docs: managed MCP configuration
• Claude Code docs: security
• Model Context Protocol: introduction