An MCP server is a tool supply line: your agents will call whatever it exposes, with your credentials, at machine speed. Before one joins the fleet — and periodically after — it deserves the same question you would ask any dependency: is it up, is it what it claims to be, and what exactly can it do?
The short answer
An MCP health probe is a structured check of a Model Context Protocol server before (and while) agents depend on it. It verifies five things: the server is reachable and answers on its transport (SSE or HTTP), its auth posture (does it demand credentials, and does it accept the ones it should refuse), the tool inventory it actually exposes — names, descriptions, and input shapes, compared against what you expected — and whether the result is written somewhere enforced, so a bad verdict blocks calls instead of decorating a report. Agent Auth Gateway's supply-chain scanner runs this probe: fetches are SSRF-guarded (public hosts only, no private IPs), time-boxed, and size-capped, and one click writes the verdict into the enforcement plane.
The five checks, in order
- Reachability. Does the endpoint answer at all, on the transport it advertises? A server that times out under probe will time out under your agent — mid-run, at the worst step.
- Transport behaviour. Does it speak the protocol cleanly — initialize, list, respond — or does it error, redirect oddly, or downgrade? Malformed protocol behaviour is where client-side bugs and surprises breed.
- Auth posture. Does it require authentication for its tools? Does it accept no credential, a wrong credential, an expired one? An MCP server that serves anyone who asks is a public tool wearing a private tool's trust.
- Tool inventory. The probe enumerates the tools the server exposes today — and the diff against the inventory you vetted is the finding. New tools, renamed tools, widened input schemas: each is a change to what your agents can be made to do, and tool descriptions themselves are an injection surface worth reading.
- Enforcement. A probe whose verdict lives in a PDF changes nothing. The verdict has to reach the enforcement plane: vetted once, the gateway's decision API enforces it on every subsequent tool call — and a failed re-vet revokes that standing automatically.
Healthy is a state, not a scan
Servers change: deploys, new tools, new owners. The probe is a re-runnable check, and the scanner keeps the verdict attached to the source so re-vetting is one click. Free workspaces can browse the curated threat-feed summary on the supply-chain page; scanning an MCP server URL of your own runs the full probe. The same page vets npm packages and skill repos — the other two supply lines agents drink from.
Pair the probe with the rest of the posture: per-agent credentials so a bad server meets a scoped identity, spend ceilings so a misbehaving tool has a budget-shaped blast radius, and the kill switch for the day a vetted server turns. Which tools an agent may touch at all is a separate, prior decision — your allowlist and denylist policies: the probe verifies the server, the policy decides what its tools are allowed to do.