MCPmatic

MCP server security checklist

Published · Updated · Written against MCP spec 2026-07-28

This checklist pulls together what the MCP specification requires of servers and what its security best practices recommend. Items marked MUST or SHOULD come from the spec. The rest is practical advice. For the reasoning behind each item, read MCP security best practices.

Every tool#

  • Validate all tool inputs (spec: servers MUST). Don't trust the model to respect your schema.
  • Implement proper access controls (MUST). Check the caller's authorization on every call, including calls that pass a handle returned earlier.
  • Rate limit tool invocations (MUST).
  • Sanitize tool outputs (MUST). Content from the outside world flows straight back into the model's context.
  • Return tool execution errors with isError: true and an actionable message so the model can correct itself.
  • Set honest annotations, so clients can ask before destructive calls.

Tokens and credentials#

  • No token passthrough. Servers MUST NOT accept tokens that weren't issued for them. Validate the audience, and use your own credentials for downstream calls.
  • Minimise scopes. Broad up-front scopes widen the damage if a token leaks. Ask for what each operation needs.
  • Never put secrets in tool arguments, and never mirror sensitive parameters into headers with x-mcp-header (spec: SHOULD NOT).
  • Keep keys in environment variables or a secret store, never in the repo or in client config files.

Remote (HTTP) servers#

  • Guard against SSRF. If a tool fetches URLs, block internal and metadata addresses and validate redirects.
  • Make state handles random, non-guessable and bound to the user, and never treat a handle as authentication (MUST NOT).
  • If you proxy a third-party API with a shared OAuth client, get per-client user consent (MUST).

Local (stdio) servers#

  • Document exactly what the server can access. Local servers run with the user's permissions.
  • Prefer stdio. Don't leave an unauthenticated HTTP listener on localhost.
  • Publish from a verifiable source so users can check what they're installing.

Before release#

Sources#