--- title: Free MCP Server Checker description: Test a Model Context Protocol server the way an agent does — initialize handshake, protocol version, HTTPS, sign-in discovery and the full tool inventory — and get an A+ to F grade with the exact fix for every problem. Open servers are never marked down for being open. canonical: https://watchfor.io/mcp-server-checker --- [Back to all free tools](/free-tools) # MCP Server Checker Test a Model Context Protocol server the way an agent does — initialize handshake, protocol version, HTTPS, sign-in discovery and the full tool inventory — and get an A+ to F grade with the exact fix for every problem. Open servers are never marked down for being open. [How to use this tool](/blog/how-to-test-an-mcp-server) Result No result yet Fill in the form above and run it — the result appears here. Monitor this 24/7 — get alerted when a failure is confirmed. [Start free](/auth/sign-up) 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](/legal/terms). ## The MCP server grade scale Every check returns one of these grades with the exact reasons behind it. Open servers are never marked down for being open. A server that requires sign-in is graded on its transport and sign-in discovery only, and the result says so. A server we could not reach gets no grade at all. A+ Excellent Handshake works on the current protocol, over HTTPS, every tool has a description and an input schema, names are unique, and it answers quickly. A protected server also tells clients exactly where to sign in. A Good Works well, one step short: usually the previous protocol revision, a slightly slow answer, a very large tool list, or sign-in metadata that only sits at the well-known address. B Needs attention A real weakness agents will notice: tools without descriptions, an outdated protocol, slow answers, TLS older than 1.2, a certificate close to expiry, or capabilities that don't match what the server serves. C Weak Unsafe or hard to use: plain HTTP, secrets in the URL, duplicate tool names, tools without an input schema, or a protected server that doesn't publish how to sign in. F Failing Agents can't use it: the server answers but the handshake or tool listing breaks, the certificate isn't trusted, or it asks for credentials over plain HTTP. ## Every rule, in full The grade starts at A+ and each problem can only lower the ceiling, so the grade is always explained by the worst finding in the report. Rules version mcp-2026.10b . Grade at most When F The server answers but initialize fails: HTTP error (404, 5xx…), JSON-RPC error, or a reply that isn't valid JSON-RPC F tools/list fails after a successful handshake (unless the server never declared tools and answers "method not found") F The TLS certificate is not trusted, expired or for another name F Plain http:// on a server that requires sign-in C Plain http:// (no TLS) on a public host C Protected server (401) without OAuth Protected Resource Metadata (RFC 9728) — clients can't discover where to sign in C A secret in the URL: credentials before the host, or a query parameter such as token, key, api_key, secret, password, auth or sig C Two or more tools share a name C A tool without a usable input schema (a JSON object schema) C Certificate expires within 7 days C initialize answers without a protocolVersion B Protocol revision 2025-03-26 or 2024-11-05 (two or more revisions behind the newest handshake revision, 2025-11-25) B A tool without a description B A tool name outside the spec's guidance: 1–128 characters of A–Z, a–z, 0–9, _ - . B TLS 1.0 or 1.1 negotiated B Certificate expires within 14 days B Handshake over 3 s or the full check over 8 s B Capabilities don't match: tools served without declaring tools, or resources / prompts declared but their list call fails B Protected server whose authorization server publishes no discovery metadata (RFC 8414 / OpenID) A Protocol revision 2025-06-18 (one revision behind the newest handshake revision, 2025-11-25) A Handshake over 1.5 s or the full check over 4 s A More than 100 tools A tools declared but none listed A Sign-in metadata only at the well-known address, not linked from the 401's WWW-Authenticate header — Open, no sign-in: reported, never graded down — public servers can be open by design — Protected server: only transport and sign-in discovery are graded; the tools behind the login are not — Tool names over 64 characters (some clients cut them off) — A monitor that pins a protocol version offers that version; the server answering it is reported, not graded against newer revisions — Not graded: a server that speaks only the 2026-07-28 revision, which has no initialize handshake, rejects ours — that is not a fault of the server — Not graded: no answer from our location (DNS, connection refused or timed out, blocked, rate-limited) [How WatchFor grades everything the same way](/grades#mcp-server) ## 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. Every check ends in a WatchFor Grade from A+ to F (rules version mcp-2026.10b ). It starts at A+ and each problem can only cap it: a broken handshake, plain HTTP, a secret in the URL, duplicate tool names, tools without an input schema or description, an outdated protocol revision, slow answers, capabilities that don't match what the server serves. The reasons sit under the letter, worst first, each with the exact fix. Public servers are never marked down for being open, and a server we could not reach gets no grade at all rather than an F. ## How it works The check reproduces the exact session lifecycle a real MCP client performs: - 1 Initialize handshake — POST a JSON-RPC initialize request offering 2025-11-25 (the newest revision that still has the handshake), 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. - 2 Session 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. - 3 Walk 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. - 4 Check sign-in discovery on protected servers — When initialize is answered with 401, the checker follows the MCP authorization spec's discovery path without sending any credentials: the resource_metadata link in WWW-Authenticate , the OAuth 2.0 Protected Resource Metadata at /.well-known/oauth-protected-resource (RFC 9728), and the authorization server's own metadata (RFC 8414 or OpenID discovery). - 5 Time 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 . Finally the published rubric turns what was seen into the grade: every rule and the grade it allows is listed in the table on this page. ## 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 ### The grade (A+ to F) The letter is the highest grade the worst finding allows. A+ means the handshake works on the current protocol, over HTTPS, with a clean tool inventory and quick answers. Each finding under the letter carries a max badge — the grade it caps at — plus what it means and the exact fix. Not graded means we couldn't reach the server from our location (DNS, connection, timeout, rate limit, a firewall refusing probe traffic) — that is never counted against the server. ### Handshake (OK / Sign-in required / Failed) Handshake OK means the server completed initialize and answered tools/list — a real agent could establish a session right now. Sign-in required is a 401: the grade then covers transport and sign-in discovery only (marked Auth discovery only ). Handshake failed means the server answered but broke the exchange — an HTTP error such as 404 or 5xx, a JSON-RPC error, or a reply that isn't valid JSON-RPC. ### Protocol version The version the server negotiated (e.g. 2025-11-25 ). The checker offers 2025-11-25 , the newest revision with the initialize handshake, so answering with it is current. One revision behind ( 2025-06-18 ) caps the grade at A; two or more behind ( 2025-03-26 , 2024-11-05 ) at B — those servers miss icons, URL elicitation, structured tool output or the OAuth-based authorization rules. The specification's current revision, 2026-07-28 , drops the handshake altogether: a server that speaks only that revision rejects ours, and the check says so and gives no grade rather than calling it broken. Also watch 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. Tools without a description or an input schema, and names used twice, are flagged inline and count against the grade. 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 alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card. [Start free](/auth/sign-up) ## 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? Yes, partly. The free checker runs unauthenticated by design — a public page should never ask you to paste bearer tokens — so on a protected server it grades what an anonymous agent sees first: HTTPS and whether the server tells clients where to sign in (OAuth Protected Resource Metadata and the authorization server's metadata). The result is marked Auth discovery only . A WatchFor MCP monitor sends your bearer token or headers and grades the whole server, continuously, with the same rubric. How is the MCP server grade calculated? It starts at A+ and every finding can only cap it, so the worst finding sets the letter. A server that answers but breaks the handshake or tool listing, or presents an untrusted certificate, gets F. Plain HTTP, a secret in the URL, duplicate tool names, tools without an input schema, or a protected server without sign-in metadata cap at C. Missing descriptions, an outdated protocol, TLS below 1.2, slow answers or mismatched capabilities cap at B. The full rule table, with its rubric version, is on this page. Is a public MCP server without auth marked down? No. Being open is reported as information, never as a cap — plenty of servers (documentation search, public data) are open by design. The note just reminds you that anyone with the URL can call the tools, which matters only if they touch private data. 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. ## Related web tools - [Software Exposure CheckerSee which software versions your website reveals in its headers and HTML — web server, PHP, CMS, JavaScript libraries — and whether any is outdated, past end of life or has known CVEs. Graded A+ to F, with the fix for each. One plain GET, no signup.](/software-exposure-checker) - [PHP Version CheckerCheck your PHP version, EOL date and known CVEs — php2shell (CVE-2026-109618, CVE-2026-109619) first — from the headers your server already sends. Graded A+ to F, with the exact version to upgrade to. Passive: plain GET requests only, no signup.](/php-version-checker) - [SSL Certificate CheckInspect certificate validity, expiry, SANs, issuer and chain trust.](/ssl-checker) - [SSL/TLS GradeGrade a server's TLS config A+ to F — protocols, ciphers, forward secrecy, post-quantum, HSTS and certificate, with the exact reasons.](/ssl-grade-checker) --- Canonical page: https://watchfor.io/mcp-server-checker · Site guide: https://watchfor.io/llms.txt