Validate MCP servers
the way agents call them.

Every layer of your MCP server, probed from where agents actually call it. Scroll to assemble the stack.

Reachability
can agents reach it
Tool quality
listed isn't working
PASS
Speed
time to result
829ms
Workflows
chains hold up
Drift
holding over time
Layer 1 / 5

Can agents reach it?

We run initialize and tools/list from home networks in the regions you care about — not a ping from your VPC.

Five layers, one verdict — reachable, working, fast, chained, and holding steady over time.

What we validate

Uptime on the URL isn't MCP health.

Discovery, tool calls, workflows, and transport — from home networks, on a schedule. Plain verdicts you can explain to your boss.

Reachability & discovery

Is the server there, and does the catalog match what you ship?

homeMCP

Probed from home networks

JSON-RPC calls go out from real residential nodes — not a datacenter pretending to be your agent's client.

Catalog snapshotCAPTURED
tools/list12
resources/list4
prompts/list3

Full catalog snapshot

Every run captures tools, resources, and prompts — the same discovery surface your agent SDK depends on.

Tool inventoryDRIFT
search_flightsREMOVED
book_hotelOK
lookup_orderOK

Tool inventory drift

Renamed, removed, or newly added tools get flagged between runs. Discovery alone isn't enough to catch silent regressions.

DiscoveryFAST
829ms

tools/list round trip

Discovery latency

Slow tools/list means slow first turns for users. We track discovery time as its own SLA, not just uptime.

Tool quality

Listing a tool isn't the same as it working.

Three layersALL PASS
can we call it?REACHED
respond properly?WELL-FORMED
actually work?DOES ITS JOB

Can we call it?

Three independent signals: reachability, a well-formed response, and output that actually matches what the tool claims to do.

tools/call
tools/call → lookup_order
{ order_id: "4821" }

tools/call, not just tools/list

We execute real tool calls with configured or auto-generated inputs — the failure mode uptime monitors never see.

AI reviewLOOKS GOOD

Output matches what the tool description claims?

Did it actually work?

A non-empty JSON-RPC result isn't success. AI review checks whether the output accomplished what the tool description promises.

Workflows

Real agents chain tools. We test the chain, not just one call.

1
2
3
create_cart → add_item → checkoutCHAINED

Connected steps

Multi-hop paths where one tool's output feeds the next — inferred from schemas, server hints, or your configured workflow JSON.

Runtime bindingCONFIRMED
create → { cart_id: "c-12" }

↓ extract

get(cart_id="c-12")

Confirmed at runtime

Planned links get upgraded when live responses extract real IDs — not guessed from tool names.

health
search
refund
status
NO GAPS

Every tool still covered

Tools outside a chain still get individual probes. No duplicate coverage, no gaps in the catalog.

Failures uptime misses

Green URL checks hide the failures users actually hit.

TransportCONTRACT
HTTP JSON-RPCSUPPORTED
SSEDROPPED
Streamable HTTPSUPPORTED

Transport drift

HTTP JSON-RPC vs SSE vs Streamable HTTP. We fail loudly when the contract changes — not as degraded latency.

Catalog by auth

anon · 3

authed · 7

Auth-bound catalogs

Probe with the same credentials your agent uses. Anonymous checks can show a healthy server your production client never sees.

node
gateway
origin

Gateway hops

Smithery and hosted connectors add a connection layer. We probe through the same gateway URL your agents use.

When it breaks, you know

Attribution, evidence, and one workspace for every modality.

AlertsFIRED
SlackSENT
WebhookSENT
PagerDutyPAGED

Alerts with attribution

Reachability vs invocation vs functional vs transport — Slack, webhooks, and PagerDuty with enough context to fix it.

Evidence bundleSIGNED
mcp-report.pdf
report.json
run_history.csv

Signed evidence bundles

MCP report PDF, JSON, and run history CSV for audit, compliance, and sharing with customers who ask for proof.

One workspaceLIVE
chatvoicemcp

Chat, voice, and MCP

MCP gets its own tab on the same agent. One workspace when you ship multiple surfaces.

FAQ

Common questions

QuestionAnswer
We ping the MCP URL and it's up. Why isn't that enough?A 200 on the URL doesn't mean tools/call works, the transport matches your client, or the tool catalog is what your agent expects. Uptime checks the address. We check the protocol.
Our agent SDK handles MCP. Why probe separately?The SDK sees its side. We see what a residential node gets when it speaks JSON-RPC — the same path Cursor, Claude Desktop, and your production gateway use.
We already run tools/list in CI. Isn't that enough?CI runs once, from one network, often without auth. We diff the catalog and exercise calls on a schedule from home networks.
Discovery passed. Aren't we done?Discovery only proves the menu exists. A tool can be listed and fail on every call — the most expensive kind of broken.
Do you test multi-step tool chains?Yes. We infer and execute connected tools/call sequences from schemas or your configured workflow, then test remaining tools individually.
Do you use the same auth our agent uses?Yes. Probes can carry the same bearer token or API key your agent uses, so you see the catalog and tools your production client actually gets.
What about hosted MCP gateways like Smithery?We probe through the same gateway URL your agents use, not just origin. Gateway connection failures are first-class verdicts, not silent timeouts.
What do we actually get back?Per-tool three-layer verdicts, workflow confidence labels, transport errors, and exportable MCP evidence bundles — PDF and JSON for audit.

See your agent the way the world sees it.

Start free