AI Guides › Playbooks
By Nigel Guy · 8 min read
Most people add an MCP server the way they add a browser extension: someone recommends it, the install is one line, and it works on the first try. That first success feels like proof it is safe, and it proves nothing of the sort. The Claude Code MCP documentation opens its setup advice with a bolded line telling you to verify you trust each server before you connect it, and warns that servers which fetch external content can expose you to prompt injection. This playbook turns that warning into something you can do.
The rule: a server gets connected only after it has a filled-in Server Card. If you cannot answer one of the five questions, you do not connect it yet.
An MCP server is a bridge between Claude and something else: your files, a database, GitHub, a browser, a mailbox. Three things can go wrong, and they are different problems.
| Risk | What it looks like | Where Anthropic or the spec says so |
|---|---|---|
| The server itself is hostile or careless | A local (stdio) server is a program running on your machine with your privileges. A bad install command or package can read files or send data out. | MCP spec, "Local MCP Server Compromise" |
| The server carries someone else's instructions | A server that fetches web pages, issues, emails or documents can hand Claude text written by a stranger, phrased as instructions. That is prompt injection. | Claude Code MCP docs; Claude Code security page |
| The server can do too much | A connector with write or delete access means Claude can create, change or delete data in that app, and "Allow always" removes your chance to stop it. | Claude Help Centre, custom connectors |
Two facts make this your job rather than Anthropic's. First, Anthropic's security page says it reviews connectors against listing criteria before adding them to the Anthropic Directory, but does not security-audit or manage any MCP server. Second, the custom connectors help article describes custom connectors as connecting Claude to services "that have not been verified by Anthropic".
Fill this in for each server, in a note or a text file next to your project. Five rows, one line each.
| # | Question | What a pass looks like |
|---|---|---|
| 1 | Who built it, and where does the code live? | A named organisation you already trust, or code you can read (an official vendor repo, or one you wrote). Not "a link from a thread". |
| 2 | What exactly runs? | For a local server, you have read the full command and arguments, and you know what package it pulls. For a remote server, you know the exact URL and that it uses HTTPS. |
| 3 | Does it read content written by strangers? | Either no, or yes and you have written down which tools do it (web fetch, issue reader, inbox reader). Those tools never get "Allow always". |
| 4 | What can it change? | You have listed its write, send and delete tools, and requested the narrowest login scopes it offers. |
| 5 | How do you switch it off? | You know the remove command or the toggle, and where the config lives. |
Row 3 is the one people skip and the one that matters most. A server that only reads your own data is a contained risk. A server that reads stranger-written text and can send or change things is the combination to treat with real suspicion, because injected text can then turn into an action.
These commands are from the current Claude Code MCP docs.
claude mcp list, then claude mcp get <name> for anything you do not recognise. Inside a session, /mcp shows server status. Note that reviewing a project's .mcp.json does not show everything: servers at local or user scope, claude.ai connectors and plugins can all add servers too.--scope local (the default) keeps a server to the current project for you alone; --scope project writes it to .mcp.json for everyone who clones the repo; --scope user loads it in every project. Default to local until the card is filled in..mcp.json. Non-interactive runs (claude -p), the Agent SDK and cloud sessions load them without asking, so check .mcp.json before you script anything. claude mcp reset-project-choices clears earlier approvals if you said yes too quickly.mcp__<server>__<tool>. Allow the read-only tools you listed in row 3 and 4 by name, for example mcp__github__get_*, and leave write tools to prompt. An allow rule like mcp__* is skipped with a warning and approves nothing; a deny rule of mcp__* blocks every MCP tool.claude mcp remove <name>.In the Claude apps, custom connectors are added under Customize > Connectors on Pro and Max; on Team and Enterprise an Owner adds them under Organization settings > Connectors (the menu uses US spelling) first. The Help Centre's advice is the same card in different words: connect only to trusted servers, review requested permissions, limit scopes, watch for tool behaviour changing after updates, and keep "Allow always" for tools you are happy to run unsupervised. You can switch off individual tools from the "Search and tools" menu.
You run a two-person design studio and want Claude Code to read client feedback from your project tracker and draft replies. A colleague suggests a community MCP server for the tracker.
claude mcp add --transport http, and you finish the login with /mcp.get_ tools by name and leave posting and closing to prompt.claude mcp remove tracker.The card changed two decisions: which server you used and which tools run without asking.
Paste the server's README, its install command or config block, and its tool list. Fill in the bracketed parts.
You are a cautious security reviewer helping a small business decide whether to connect an MCP server to Claude.
Context:
- Server name: [SERVER_NAME]
- Where I found it: [SOURCE_URL_OR_WHO_RECOMMENDED_IT]
- How it would be installed (exact command or JSON config): [INSTALL_COMMAND_OR_CONFIG]
- Its documented tools and what they do: [TOOL_LIST]
- What I want it for: [MY_USE_CASE]
Goal: produce a filled-in Server Card so I can decide whether to connect it, and which tools to allow.
Steps:
1. Answer each of the five card questions in one or two lines: who built it and where the code lives; what exactly runs; which tools read content written by people outside my organisation; which tools can write, send or delete; how to remove it.
2. Flag anything in the install command that reaches beyond the server's stated job, such as sudo, deleting files, piping to a shell, or sending files to another host.
3. Sort the tools into three lists: safe to allow by name, keep on ask, deny.
4. Give a verdict: connect, connect with limits, or do not connect yet, with the single main reason.
Output format: a five-row table for the card, then the three tool lists, then the verdict in one sentence.
Constraints:
- Use only what is in the material I pasted. If something is missing, such as who maintains the code, say "unknown" and list it under "Questions to answer first" rather than guessing.
- Do not describe any server as safe or verified. Your job is to surface risks, not to vouch.
- If I have not given you the install command or tool list, ask for them before you start.
Before you answer, check: did every "safe to allow" tool avoid both stranger-written input and write access? If not, move it.
Fill in the five bracketed fields; leave nothing blank, or the model should stop and ask.