How to monitor MCP tool-description and schema changes

Published 25 September 2026 by Dominion Observatory, the service operator.

To monitor MCP tool changes, capture the tools/list response, retain an approved baseline, compare later successful captures, and send added, removed, description, or input-schema changes to a reviewer. An HTTP uptime check alone does not compare tool contracts.

A practical review workflow

Use an endpoint you own or have permission to monitor. Establish authentication, transport, initialization and pagination requirements.
Capture its tool names, descriptions and input schemas. Keep the baseline and the capture time.
Normalize JSON object key order and compare later captures. Treat failed captures separately from a successful empty tool list.
Send the changed fields and before/after references to the responsible owner.
Confirm whether the change was planned, rerun affected client tests, and approve a new baseline through your own change process.

See a synthetic worked example with downloadable before-and-after manifests.

Choose the control that matches your need

Need	Approach	Limit
Catch changes you release	Store manifests and compare them in CI	Does not observe later changes outside your release pipeline
Review changes to a public endpoint over time	Scheduled capture and change notifications	Depends on successful captures and delivery; does not block calls
Approve tools before each invocation	Client or gateway enforcement with a pinned contract	Requires integration into the execution path
Measure actual tool behavior or application correctness	Execution tests and application telemetry	Manifest comparisons alone cannot establish these properties

Where Dominion Observatory fits

Dominion's MCP Drift Monitor is a hosted option for owners of compatible public HTTPS endpoints. It compares tool names, descriptions and input schemas, records public manifest history, and supports email and optional HTTPS webhook alerts on detected changes.

US$29 per server per month. The subscription prioritizes active monitors in scheduled batches. There is no guaranteed detection interval, and alert delivery is best effort. New stored captures are Ed25519-signed; legacy captures remain unsigned. Verify signed_capture against /.well-known/capture-jwks.json. Change summaries are not separately signed. This plan does not automatically block an agent or establish security or legal compliance.

Compatibility checklist before paying

The endpoint must return a JSON or SSE tools/list response over public HTTPS.
Authentication, redirects, legacy GET-only SSE, paginated tool lists, and IPv6-only endpoints are not supported by this plan.
You must be authorized to publish the tool manifest and change history. Do not submit tokens or confidential definitions.
Checkout performs a compatibility check before opening Stripe. Ask for a baseline and test notification review if you need setup assistance.

Frequently asked questions

Does a changed description prove tool poisoning?

No. Descriptions and schemas change for legitimate reasons. Review the change with the operator; a manifest diff is evidence of a changed definition, not of intent.

Can the monitor miss a change?

Yes. A change can occur and revert between captures, or an endpoint or notification destination may be unavailable. Use in-path controls if a tool must never execute before review.

Can I use my own release checks instead?

Yes. Versioned manifests and CI comparisons may be sufficient when you control every release. Scheduled monitoring addresses observation between releases; decide whether that additional record is useful to your team.

Check the monitoring plan and start compatible endpoint setup, or ask about fit before subscribing.