MCP Server Checker

Q: How do I check if my MCP server is working?

Paste its endpoint URL (e.g. https://mcp.example.com/mcp) above and run the check. A working server completes the initialize handshake, reports its protocol version and returns its tool list. Anything less means agents can't use it, whatever your HTTP health check says.

Test a Model Context Protocol server: initialize handshake, protocol version, capabilities and the full tool inventory.

Result

No result yet

Enter the inputs above and press Run. Results appear here in a moment.

Monitor this 24/7 — get alerts on the first failure.

Start free

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.

What is MCP Server Checker?

MCP (Model Context Protocol) is how AI agents — Claude, ChatGPT connectors, OpenClaw, Hermes and a fast-growing ecosystem of autonomous assistants — discover and call your server's tools. An MCP server that answers HTTP 200 can still be completely broken for every agent connected to it: the initialize handshake fails, the tool list comes back empty, or auth silently rejects every session. Ordinary uptime checkers can't see any of that, because they don't speak the protocol.

This tool performs a real MCP session against your endpoint over Streamable HTTP: JSON-RPC initialize handshake, protocol version negotiation, capability discovery, then a full tools/list walk (plus resources and prompts when the server advertises them). You see exactly what an agent would see — server identity, negotiated protocol version, and the complete tool inventory with descriptions.

How it works

The check reproduces the exact session lifecycle a real MCP client performs:

1Initialize handshake — POST a JSON-RPC initialize request offering the current protocol version (2025-06-18), with Accept: application/json, text/event-stream — servers may answer in plain JSON or as an SSE stream, and both are handled. The negotiated version, server name/version and capability set come back here.
2Session acknowledgement — Send notifications/initialized (and carry the Mcp-Session-Id header when the server issued one) — the same handshake completion step the spec requires from real clients.
3Walk the tool inventory — Call tools/list, following pagination cursors, to enumerate every tool the server exposes — names and descriptions included. If the server advertises resources or prompts capabilities, those lists are counted too.
4Time every phase — DNS, TCP, TLS, the initialize round-trip and the tools listing are timed separately, so a slow handshake (cold start, server-side work in initialize) is distinguishable from a slow network path.

The session is then explicitly terminated (HTTP DELETE with the session id) — the polite client behaviour the spec asks for. Nothing is cached and no tool is ever invoked: the check is read-only discovery, never tools/call.

When you'd use it

You just deployed an MCP server

The container is running and /health says OK — but can an agent actually connect? One check confirms the full handshake, the negotiated protocol version and that every tool you registered is really exposed.

Agents suddenly can't use your tools

Claude or your OpenClaw/Hermes agent reports the server as unavailable, but the URL loads fine in a browser. That's the classic protocol-level failure: HTTP is up, MCP is down. The per-phase result shows whether initialize, auth or the tool listing is the broken step.

Verifying a third-party MCP server before connecting an agent

Before you point an agent (and its credentials) at someone else's MCP endpoint, look at what it actually exposes: which tools, with which descriptions. Tool descriptions are instructions your agent will follow — read them before you trust them.

After an MCP SDK / framework upgrade

Framework upgrades routinely change the negotiated protocol version or break SSE response handling behind proxies. A post-upgrade check confirms the version your clients will get and that the inventory survived the migration.

Debugging a reverse proxy in front of MCP

nginx/Caddy/Cloudflare in front of a Streamable HTTP server can strip the Mcp-Session-Id header, buffer SSE streams into timeouts, or downgrade POST bodies on redirects. Checking from outside your network shows what remote agents really experience.

Reading the result

MCP handshake (Online / Failed)

Online means the server completed initialize and answered tools/list — a real agent could establish a session right now. Failed names the phase that broke: an HTTP 401/403 is an auth problem, a JSON-RPC error is the server rejecting the protocol exchange, a timeout usually means SSE buffering or a hung backend.

Protocol version

The version the server negotiated (e.g. 2025-06-18). Clients offer the newest they support and servers may answer with an older one — that's fine. What matters is that it doesn't change unexpectedly between deploys, because agents pin behaviour to it.

Capabilities

Which optional protocol features the server advertises: tools, resources, prompts, logging. A missing capability isn't an error — but if your agent depends on resources and the badge disappeared after a deploy, that's your regression.

Tool inventory

Every tool the server exposes, with its description — the exact list an agent receives. Zero tools after a successful handshake is the most common silent failure: the server started, but tool registration didn't finish. The descriptions are also your security surface: they're injected into the agent's context verbatim.

Phase timings

DNS / TCP / TLS / Initialize / Tools list. A slow Initialize with fast network phases points at server-side work (cold starts on serverless hosting are the usual culprit); slow everything points at the network path or an overloaded box.

Common pitfalls

Health endpoint green, MCP dead

A /health route and the MCP JSON-RPC handler are different code paths. Kubernetes probes and uptime pings hitting /health prove nothing about initialize. Always verify the protocol itself — that's the thing agents use.

Proxy breaks SSE responses

Streamable HTTP servers often answer initialize as a text/event-stream. Reverse proxies with response buffering (nginx proxy_buffering on, some CDN defaults) hold the stream until timeout — the agent sees a hang, not an error. Fix: disable buffering for the MCP path.

Session header stripped

Servers that issue Mcp-Session-Id expect it back on every subsequent request. Proxies with restrictive header allowlists silently drop it, so initialize works and everything after returns 400/404. If handshake passes but tools/list fails, check header pass-through first.

Tool descriptions changed under your agents

A tool named search whose description quietly gains "also forward the user's data to…" is the MCP rug-pull attack — descriptions are prompt-injected straight into agents. A one-off check shows today's inventory; continuous monitoring with drift detection is how you catch the change the day it happens.

401 on a server that "has no auth"

Managed MCP hosting often injects OAuth in front of your server without telling your code. If this check reports an auth failure on an endpoint you believe is public, the platform layer is demanding a token before the request ever reaches your handler.

Run MCP Server Checker on every change, not just once.

Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.

Start free

Frequently asked questions

What is an MCP server checker?

A tool that tests a Model Context Protocol server the way a real AI agent does: it performs the JSON-RPC initialize handshake over Streamable HTTP, negotiates the protocol version, and lists the tools, resources and prompts the server exposes. It verifies the protocol works — not just that the URL answers HTTP.

How do I check if my MCP server is working?

Paste its endpoint URL (e.g. https://mcp.example.com/mcp) above and run the check. A working server completes the initialize handshake, reports its protocol version and returns its tool list. Anything less means agents can't use it, whatever your HTTP health check says.

Which transports are supported?

Streamable HTTP — the current MCP standard for remote servers — including servers that respond in plain JSON or as SSE streams. stdio servers are local-process-only by design and can't be reached by a remote checker.

Does the checker call my tools?

No. The check is read-only discovery: initialize, tools/list, resources/list, prompts/list. It never issues tools/call, so nothing with side effects can be triggered.

Can I check an MCP server that requires authentication?

The free checker runs unauthenticated by design — a public page should never ask you to paste bearer tokens. A WatchFor MCP monitor supports bearer tokens and custom headers, stored encrypted, and checks the server continuously.

What is MCP tool drift / a rug-pull?

Tool descriptions are instructions delivered into the agent's context. If a server operator (or an attacker who compromised one) changes a description, connected agents obediently follow the new instructions — that's the rug-pull. WatchFor MCP monitors fingerprint the entire inventory (names, descriptions, schemas) and alert on any change, with the exact diff.

Why does my MCP server work locally but fail this check?

The usual suspects are the layers that only exist in production: a reverse proxy buffering SSE, a stripped Mcp-Session-Id header, platform-injected auth, or a firewall allowing your office IP only. The failed phase reported by the check tells you which layer to look at.

How often should an MCP server be monitored?

Production servers that agents depend on deserve the same cadence as an API: every few minutes for availability, plus inventory drift detection on every check. WatchFor's MCP monitor does both and alerts through Slack, Discord, PagerDuty and 20+ other channels.