Monitor the MCP servers your agents depend onNot just an HTTP 200

Yorker drives the full Streamable HTTP MCP session as a single unit: it sends an initialize request, validates that the response carries protocolVersion and capabilities, sends the notifications/initialized notification, then calls tools/list. From there it checks that the tools you expect are present, fingerprints each tool's input schema, description and annotations to detect changes against the previous run, and optionally runs tools/call against specific tools and asserts on the output. It can also check that the server rejects a session opened with no credentials. Session ids returned in the Mcp-Session-Id header are carried on every subsequent request, exactly as a real client would.

An HTTP 200 only tells you the process is listening. It does not tell you whether the initialize handshake succeeds, whether the tools your agents depend on are still in the catalog, whether a tool's input schema changed underneath you, or whether a tool call returns the right output. Yorker speaks JSON-RPC 2.0 and the MCP lifecycle, so it catches a broken handshake, a missing tool, a schema change, and a wrong tool result — none of which move the HTTP status code.

When detectSchemaDrift is enabled, each run computes separate SHA-256 hashes of every tool's inputSchema, description and annotations, using a deterministic, key-sorted JSON representation so equivalent definitions always hash identically. It diffs them against the previous run and reports each tool as added, removed or modified, with the parts that changed. It also records the server's reported name, version, protocol version and capabilities and reports when those change. The first run has no baseline to compare against, so it seeds one and reports no drift. Drift doesn't fail the check: it's recorded on the run, and you get notified by adding an alert rule with the mcp_schema_drift condition. Server changes are opt-in on that rule.

Yes. Published MCP attacks, often called tool poisoning or rug pulls, work by changing a tool after a client has approved it, frequently by hiding instructions in the tool's description, which the model reads but most users never see. Yorker flags any change to a tool's description, input schema or annotations on the next run, shows the description before and after in the Tools tab, and lists recent changes from the last 30 days. It reports that the definition changed; it doesn't judge whether the new text is malicious, so treat a description change on a server you depend on as something to review.

MCP tools can declare hints such as readOnlyHint and destructiveHint. Yorker compares them run to run and flags any hint that moves to the less safe side, for example readOnlyHint going from true to false, or an explicit readOnlyHint: true being removed, since clients then assume the tool may modify state. You can alert on escalations alone with changeTypes: [escalated].

Yes. With rejectUnauthenticated: true and auth configured, each run that completes the authenticated session then sends an initialize request with no credentials, and fails the check unless the server answers HTTP 401 or 403. An MCP endpoint that accepts anonymous sessions is open to anyone who finds the URL, and this turns that into something checked on every healthy run.

Yes. Each entry in testCalls names a tool, optional arguments, and an optional expectedOutputContains string. Yorker issues a tools/call, and if expectedOutputContains is set it serializes the JSON-RPC result and asserts the substring is present. A missing substring fails the check as an assertion failure; a JSON-RPC error returned by the tool fails it as an error. This turns a tool you depend on into a contract test that runs on a schedule.

MCP checks run on the same runners as HTTP and browser checks and emit standard OTLP into your own OTel backend: status, response time, location and any error for every run, and a synthetics.mcp.schema_drift event with counts and the affected tool names (including description changes, escalations and server changes) whenever drift is detected. The full tool catalog, per-tool hashes and drift detail are recorded in Yorker, on the Tools tab and through the API. A W3C traceparent is propagated to the MCP server so the check links into your distributed traces.

No. A full MCP session runs several JSON-RPC requests in sequence (handshake, tool catalog, drift detection, and any tool calls or access checks you configure) but bills as a single run at the HTTP rate: 10,000 HTTP + MCP runs a month on the free tier, unlimited on the $29.99 plan.