# 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](/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](https://app.mcprobe.dev/signup) 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](/docs/getting-started).

## 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](/docs/mcp-breaking-changes)
explain the approved-preview CI workflow and its evidence limits.