MCP Server Security Checklist: 20 Checks Before You Put an MCP Endpoint on the Public Internet

🔐 MCP Security · Updated October 2026 · 4 min read · by Jacob Campbell

An MCP server is an API that AI agents call on behalf of people. That makes it an API with an unusual threat model: the caller is a model that can be manipulated by text it read elsewhere, the person behind it may not see each call, and anything your server returns may be read by another model next. Most MCP security problems are ordinary API mistakes made worse by that chain. This checklist gives 20 checks for a public, website-hosted MCP server, grouped by layer, with the reasoning for each.

Key facts

• 20 checks — Transport, auth, input, output, abuse and operations
• Origin — Must be validated on Streamable HTTP endpoints
• No passthrough — Servers must not forward tokens issued for someone else
• Untrusted — Every string from or to an agent

Transport (checks 1 to 4)

1. HTTPS only. Redirect or refuse plain HTTP.
2. Validate the Origin header on every request. The Streamable HTTP specification requires servers to do this, to stop a malicious web page from talking to a server through a visitor’s browser (DNS rebinding).
3. Bind local development servers to 127.0.0.1, never 0.0.0.0.
4. Treat session IDs as untrusted identifiers: random, unguessable, never used as proof of identity on their own.

Authorization (checks 5 to 8)

5. Decide per tool what is public. Read-only business facts can be public; anything that writes, reveals personal data or costs money should not be anonymous.
6. Publish OAuth protected-resource metadata (RFC 9728) at /.well-known/oauth-protected-resource for protected servers, as the MCP authorization spec requires.
7. Validate token audience. Accept only tokens issued for your server.
8. Never pass tokens through. MCP’s security guidance forbids forwarding a client’s token to another API; it creates a confused-deputy problem and bypasses that API’s controls.

Input (checks 9 to 12)

9. Validate every argument against the tool’s input schema on the server, not just in the client.
10. Bound everything: string lengths, array sizes, numeric ranges, result counts.
11. No raw query or path arguments. A tool that accepts SQL, shell or file paths is an incident waiting for a prompt.
12. Parameterise every database call and escape output by context.

Output and prompt injection (checks 13 to 15)

13. Treat text submitted through tools as hostile. A quote request from an agent can contain instructions aimed at whoever reads it next, human or model. Store and display it as data.
14. Keep tool descriptions honest and static. Tool descriptions are read by models; a description that changes after a user approved the server (sometimes called a rug pull) or hides instructions (tool poisoning) is a known attack pattern. Version them and do not generate them from user content.
15. Return only what the tool promises, matched to its output schema. No internal IDs, emails or debug fields.

Abuse (checks 16 to 18)

16. Rate-limit by IP and by tool, tighter on write tools.
17. Annotate tools truthfully (readOnlyHint, destructiveHint and the rest) so clients ask users before risky calls. Annotations are hints; enforce the rules server-side too.
18. Add friction to anything that triggers a human: lead and booking tools should de-duplicate and cap per sender.

Operations (checks 19 and 20)

19. Safe errors. JSON-RPC error codes and short messages; no stack traces, paths or secrets.
20. Log calls with tool, client name, IP and outcome, and review them. Our guide to AI crawlers in server logs covers the log side.

Testing it

Call your own server with malformed JSON, oversized arguments, a hostile Origin, and text containing instructions, and check what comes back. WebAgentScan tests the agent-facing surface as one of its scoring pillars (Agent Security, 18 points) and withholds findings that would help an attacker until domain ownership is verified; see what WebAgentScan checks. The AI Indexing Pack ships a PHP MCP server with rate limiting, input validation and annotations already in place.

Related reading

• Add an MCP server to your website — Tools, transports, annotations and security for a public site.
• What WebAgentScan checks — The six scoring pillars, what each one tests, and how to read the result.
• Where to list your MCP server — The official registry, directories, and what each asks for.
• Agent discovery files explained — agents.txt, agent cards, server cards and the .well-known tree.
• Custom MCPs for your company — Connecting AI to your own systems, securely.
• AI Indexing Pack — The file-drop kit: MCP server, Markdown pages, llms.txt, discovery files and bot access control for any PHP site.
• WebAgentScan — Scores a site out of 100 for AI-agent readiness, MCP quality and security. Paid plans from $9 a month.

Frequently asked questions

Why must an MCP server validate the Origin header?

The Streamable HTTP transport specification requires it, to prevent DNS rebinding attacks in which a malicious web page talks to the server through a visitor's browser.

What is token passthrough in MCP?

Forwarding a token a client gave you to another API. MCP security guidance forbids it because it creates a confused-deputy problem and bypasses the downstream API's controls.

What is tool poisoning?

Hiding instructions for the model inside a tool description or output. Keep descriptions static, honest and versioned.

Should a public MCP server need authentication?

Read-only public facts can be anonymous. Tools that write, reveal personal data or cost money should require authorization.

Are MCP tool annotations a security control?

No. They are hints that help clients decide when to ask the user. The server must still enforce its own rules.

How do I test my MCP server's security?

Send malformed, oversized and hostile requests yourself and inspect responses, and use a scanner such as WebAgentScan that tests agent-facing security.