MCP Server Self-Check

Are you checking one MCP server, or everything one agent is connected to?

The Rule of Two applies to a session, not to a server. An agent connected to three servers can hold all three properties across them while no single server holds more than one.

Confirm you have the right address

What this step does: establishes the exact address this server answers on, before anything is tested against it. MCP endpoints are fussy about the path: /mcp and /mcp/ are different addresses, and a server that answers one may redirect the other, or return nothing at all. Probe the wrong form and every later check reads as a false negative. Every later command inherits this answer, so it comes first.

Run from your own machine

# Try the address from your client config, then the trailing-slash variant
curl -sS -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://your-host/mcp
curl -sS -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://your-host/mcp/

200 ->
405 ->
401 ->

307 -> https://your-host/mcp/

404 ->
404 ->   (both forms)

How does the client reach this server?

What this step does: establishes whether there is a network listener at all. No command needed, the answer is already written in your client configuration.

Check on the machine running your MCP client

Open the client configuration (claude_desktop_config.json, mcp.json or equivalent). A command key means stdio. A url key means HTTP.

"github": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-github"]
}

"github": {
  "url": "https://mcp.example.com/mcp"
}

"github": {
  "url": "https://mcp.example.com/sse"
}

What is the listener bound to?

What this step does: shows which network interfaces the listener accepts connections from. Loopback means only this host can talk to it; every interface means anything that can route to the host can.

Run on the server host itself

# Linux
ss -tlnp | grep -E ':(3000|8000|8080|8443)'
# macOS
lsof -nP -iTCP -sTCP:LISTEN | grep -iE 'node|python|mcp'

LISTEN 0 4096  127.0.0.1:8000  users:(("python",pid=812,fd=6))

LISTEN 0 4096  0.0.0.0:8000  users:(("node",pid=291,fd=22))

(the listener is loopback, but nginx, Caddy or a
 cloud load balancer forwards public traffic to it)

(no output at all)

Can an outsider list the tools?

What this step does: asks the server for its tool list while carrying no credential, which is exactly what an attacker's first request looks like. A refusal here is a pass.

Run from outside the boundary, not from the host

curl -sS -D - -X POST https://your-host/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

HTTP/2 401
www-authenticate: Bearer error="invalid_token", ...

HTTP/2 200
content-type: application/json

{"jsonrpc":"2.0","id":1,"result":{"tools":[{"name":"read_file", ...

curl: (7) Failed to connect to your-host port 443
curl: (28) Connection timed out

Is the refusal telling clients how to authenticate?

What this step does: checks whether that 401 came from a real authorisation implementation. A 401 on its own does not show the server implements the authorisation specification, it shows something said no. Both answers are already in front of you: the first in the headers step 1.3 just printed, the second from one more command.

Same position as step 1.3, outside the boundary

www-authenticate: Bearer error="invalid_token",
  resource_metadata="https://your-host/.well-known/oauth-protected-resource/mcp"

www-authenticate: Bearer realm="mcp"

(or no www-authenticate line at all)

curl -isS https://your-host/.well-known/oauth-protected-resource

HTTP/2 200
{"resource":"https://your-host/mcp",
 "authorization_servers":["https://auth.example.com"], ...}

HTTP/2 404

Which specification era is the server in?

What this step does: establishes which protocol revision the server actually speaks, because later verdicts depend on it. The 2025-03-26 revision shipped OAuth 2.1 authorisation, and 2026-07-28 changed how a gate can be built.

Run from outside; add your bearer token if step 1.3 was refused

A correctly configured server rejects these at the authorisation layer before method routing, so both probes return 401. If that happens, re-run with -H 'Authorization: Bearer YOUR_TOKEN', or answer "authorisation blocked both probes" and the report will record the version as unknown rather than as a finding.

# Probe 1, legacy handshake. Propose the NEWEST version you know, not an old one.
curl -sS -X POST https://your-host/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
        "protocolVersion":"2025-11-25","capabilities":{},
        "clientInfo":{"name":"self-check","version":"1.0"}}}'

# Probe 2, modern discovery
curl -sS -X POST https://your-host/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -d '{"jsonrpc":"2.0","id":1,"method":"server/discover"}'

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-06-18", ...}}

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

Probe 1 answers, probe 2 method not found  = Legacy
Probe 1 and probe 2 both answer            = Dual era
Probe 1 method not found, probe 2 answers  = Modern

HTTP/2 401  (both probes)

An agent should hold at most two of these three properties at once

Published by Meta on 31 October 2025 as the Agents Rule of Two. The three properties are the ingredients of a prompt injection attack. Hold any two and the attack is missing a step: content can be read but nothing sensitive is in reach, or sensitive things are in reach but nothing gets out. Hold all three in one session and a single poisoned input can read your systems and send what it finds out of the building.

You do not need to work out the properties yourself. The tick lists below ask what your tools can do in plain terms, and the page derives the properties from your ticks. The cards above fill in as you go.

Tick anything any tool in scope can do

Capability, not intent: tick it if a tool could do it, even if you never ask it to. The page works out the three properties from your ticks, and the cards above fill in as you go. If nothing in a group applies, tick "none of these" so the check knows the group is answered.

What stands between a poisoned input and those tools?

One hard line here. The first four are mechanisms that work whether or not the model is fooled, and each one takes a property out of the attacker's reach. The fifth is software or instructions trying to spot the attack, which fails exactly when the attack is good. Tick what is actually in place.

These move the verdict

This does not move the verdict

Or

Do these calls run without a person watching?

This step checks whether a person is part of the loop when these calls run. Counts as unattended: scheduled jobs, CI triggers, background agents, or a client where you have selected approve-all or "don't ask again" for these tools. That last one is why this is a separate question: a permanently dismissed approval prompt is not a gate, and nothing in the server config records that it was dismissed.

Where did this server come from?

What this step does: establishes who controls when this server changes, and how much warning you get. A server you approved once can ship new tools, new descriptions or new scopes in its next release. Where it comes from decides whether anyone tells you first, and whether you could audit or rebuild what you are actually running.

Do you have a recorded tools/list response you could diff against today's?

What this step does: checks whether you could tell that this server changed. tools/list is the server's own inventory of its tools, their descriptions and their parameters; it is exactly what your agent sees and trusts. An already-approved server can change that inventory without prompting anyone for re-approval. A saved copy from the day you approved it is the baseline, and a diff against today's response is how drift shows up.