MCP Server Review Checklist

The Model Context Protocol standardises how a model connects to tools and data. The protocol being standard does not make any particular server safe — a server is an API you have granted to something that decides for itself when to call it.

Server: _______________ Reviewer: _______________ Date: _______ Source: first-party / third-party — publisher: _______________

1. Provenance#

• [ ] Publisher known and identifiable
• [ ] Source code available and read, or the vendor is contractually accountable
• [ ] Version pinned, not floating
• [ ] Update path understood — who can change this server's behaviour, and how would we know?
• [ ] Dependencies reviewed

🔴 A third-party server updating itself changes what your model can do, without a change on your side. Pin it, and review updates as you would any dependency with production access.

2. Tool inventory — the blast radius table#

• [ ] Every tool listed, including ones that look trivial
• [ ] Read-only and write tools clearly separated
• [ ] Irreversible actions identified
• [ ] Tools not needed for the use case are disabled rather than left available
• [ ] Any tool that executes code, shell commands or arbitrary queries is flagged and justified

3. Scope and permissions#

• [ ] The server has its own credentials, not a human's and not a shared account
• [ ] Credentials scoped to the minimum the listed tools require
• [ ] Revocable in one action
• [ ] Cannot reach production data unless that is the explicit purpose
• [ ] Rate limits in place
• [ ] Filesystem or network access bounded, and the bounds verified

4. Tool descriptions are an attack surface#

• [ ] Descriptions read carefully — they are injected into the model's context
• [ ] No instruction-shaped text in a description ("always call this first", "ignore other tools")
• [ ] Descriptions do not leak internal identifiers, paths or credentials
• [ ] Parameter descriptions are accurate

🔴 A malicious or careless server can influence model behaviour purely through its tool descriptions, because those descriptions become part of the prompt. Read them as untrusted input, because that is what they are.

5. Data flow#

• [ ] What data leaves your environment, and to where
• [ ] Whether tool responses can contain content from untrusted sources
• [ ] Responses treated as untrusted input, not as instructions
• [ ] Personal or regulated data identified, with a lawful basis for the flow
• [ ] Logging excludes sensitive values

6. Transport and hosting#

• [ ] Local vs remote transport decided deliberately
• [ ] Remote connections authenticated and encrypted
• [ ] For remote servers: who operates it, in which jurisdiction
• [ ] Server cannot be reached by anything other than the intended client
• [ ] Failure behaviour defined — what the client does when the server is unavailable

7. Observability#

• [ ] Every tool call logged with arguments and result
• [ ] Logs retained long enough to investigate
• [ ] Cost or quota consumption visible where relevant
• [ ] Alert on error rate or unusual call volume
• [ ] You could reconstruct why a tool was called three days ago

8. Before connecting it to anything real#

• [ ] Exercised in an isolated environment first
• [ ] Behaviour observed when a tool errors
• [ ] Confirmed the model cannot be talked into a destructive call by content it reads
• [ ] Confirmation required for irreversible tools, and tested
• [ ] Disable path tested — you can cut it off in one action

Sign-off#

Back to MCP