Monitor MCP server changes without a proxy

Capture a third-party MCP server's tools, schemas and descriptions on a schedule, then compare changes without intercepting agent traffic.

To monitor an MCP server's contract, capture its discoverable surface and compare it with a previous capture. You can do this as a consumer of a third-party server without changing its code or routing agents through a proxy. This detects observed contract changes; it is not an uptime or runtime-behavior guarantee.

#What scheduled captures can detect

Tools can disappear, inputs can become required, enums can narrow, or a tool's description can change its stated purpose. Resources, resource templates, prompt declarations, capabilities and server instructions are also part of the discoverable surface. See compatibility examples.

A baseline establishes the contract you observed. Only a later successful capture can tell you what changed. A failed connection must never be treated as an empty contract or a clean comparison.

#Start with the final public MCP URL

  1. Create an account with email and password.
  2. Add a public HTTP MCP endpoint, including its endpoint path. Use its final URL: hosted capture refuses redirects rather than forwarding credentials.
  3. If needed, open Authorization header (optional) and enter the header required by that server. Keep secrets out of the URL and tool descriptions.
  4. Wait for the first recorded baseline. Open its tools and declared argument paths to confirm this is the surface you expected.
  5. Choose Capture again for an immediate comparison, or keep scheduled captures enabled. Review the watch's cadence and alert threshold in Settings.

The initial hosted watch defaults to an hourly interval and a BREAKING alert threshold. Scheduling is checked by a 15-minute worker timer, so captures are not an exact wall-clock alarm. Alert findings appear in the console; configured webhooks can deliver them to your own system. No telemetry setup or API key is needed for the URL-first workflow. Full walkthrough.

#How do authorized servers differ?

A capture sees what the supplied credentials can discover. If different roles see different tool lists, one capture does not describe all roles. Use comparable authorization when comparing versions, and treat an authorization failure as a connection problem. The onboarding flow can replace authorization and retry without discarding the watch's history.

Hosted URL capture accepts a manually supplied Authorization header. It does not run an interactive OAuth login on your behalf. Private-network and local stdio servers need the approved-preview local workflow rather than a hosted URL. Public CLI distribution remains pending.

#Does monitoring invoke tools or intercept calls?

No. The inspector performs discovery, including advertised list methods; it does not invoke tool handlers. Scheduled inspection is independent of your agent's runtime requests. If MCP Inspect is unavailable, your agents still connect directly to the server.

Contract monitoring is different from request tracing. It does not tell you whether a particular task succeeded, how a handler behaved, or whether a tool has no consumers. Optional shape-only usage evidence has its own collection limits, and hosted usage queries remain pending.

#What can a periodic capture miss?

An endpoint may change and change back between captures. An outage may postpone a capture. Authorization can hide parts of the contract, and handler behavior can change without any discovery change. Keep your own integration tests and monitoring for those cases. A clean diff only describes the two observed contracts, not all behavior during the interval.

For a server you maintain, use contract checks before shipping as well as monitoring afterward. Breaking-change checks explain the approved-preview CI workflow and its evidence limits.