How to Probe an MCP Server (Without Installing Anything)

Every MCP server you connect to an agent is a new trust boundary. Before you wire one in, you should know what it reveals about itself — and you can find out in five minutes without installing a single package.

Why this matters now

The MCP ecosystem grew faster than its security posture. Trend Micro's 2026 survey found 492 MCP servers exposed on the public internet with zero authentication and no encryption. BlueRock's analysis of 7,000+ servers found 36.7% potentially vulnerable to SSRF — a server that fetches URLs on your behalf can be pointed at your internal network. The CoSAI MCP Security white paper (January 2026) catalogs 12 threat categories and roughly 40 distinct threats in the protocol layer alone.

The uncomfortable part: most of these servers are reachable by anyone who knows the endpoint. The question isn't whether attackers can talk to them. It's whether you know what they're saying.

What a handshake reveals

MCP servers speak JSON-RPC over HTTP. The initialize call is the protocol's handshake — and it's remarkably chatty. A single request tells you:

• Server identity — the serverInfo block names the implementation and version
• Protocol version — which MCP spec the server actually speaks
• Tool disclosure — a follow-up tools/list call enumerates every tool the server exposes, with names and input schemas
• Auth posture — a 401 or 403 tells you the server enforces access control; a 200 with a full tool list tells you it doesn't

That last one is the finding that matters. A server that answers tools/list to an anonymous caller is a server that will answer it to anyone.

The five-minute probe

Step 1 — Find the endpoint. MCP servers commonly expose /mcp or /sse. If you have a base URL, try both.

Step 2 — Send the handshake. The probe tool at darinor.com/tools/mcp-probe does this for you: paste the URL, and it sends a standard initialize request, then a tools/list, and reports what comes back. It runs entirely in your browser — nothing is uploaded, no server-side scanner involved.

Step 3 — Read the disclosure. Three things to look for:

• Server name and version — is this the server you think it is? Version strings matter: old MCP implementations have known protocol-level bugs.
• Tool list — every tool name and its input schema. A filesystem server exposing read_file and write_file is a different risk profile than a fetch server exposing get_url.
• Auth behavior — did it answer anonymously? If yes, that's your finding.

Step 4 — If the browser can't reach it (CORS), use the curl fallback. The probe hands you a copyable curl sequence when the server doesn't allow cross-origin requests. Run it from your terminal — same handshake, same disclosure.

Step 5 — Decide. The probe is a triage, not a clearance. A server that discloses tools anonymously is not automatically malicious — but it is automatically reachable, and that changes how you should treat it. Pin the version, scope the permissions, and never auto-approve its tools.

What a probe does NOT tell you

Be honest about the limits. A handshake probe cannot detect:

• Semantic prompt injection — a tool description that reads benign but instructs the model to exfiltrate data. No static check catches this; it requires behavioral testing.
• SSRF depth — whether a fetch-style tool can reach your internal network. That's a test you run in a sandbox, not a handshake.
• Supply-chain risk — whether the server's dependencies are pinned and trustworthy. That's a separate check: MCP Supply Chain Checker scans configs for unpinned versions, auto-install flags, and mutable sources.

The pattern

Probe before you trust. The handshake is free, it's fast, and it tells you more than most teams ever check. Run it on every MCP server you connect — including the ones your teammates added to the shared config last week.

Probe an MCP server now →