How to Verify an MCP Server Is Safe Before (and After) Your Agent Uses It

2026-07-11 · Dominion Observatory

You are about to let an AI agent call an MCP server. How do you know it is safe? The common answer — run a static scanner over its source — misses the two things that actually get agents compromised: what the running server does right now, and whether it quietly changes after you approved it.

Independent research across 9,695 MCP servers found that popularity and directory “verified” badges do not predict security. And in June 2026 Microsoft warned that a silently updated tool description can steer an agent into leaking data — a benchmark (MCPTox) measured a 72.8% attack success rate, with models almost never refusing. So a badge and a last-quarter scan are not evidence. Here are the four checks that are.

1. Is it a real, reachable endpoint?

Most “MCP servers” you find in registries are npm/pypi/github packages — source code, not a running service your agent can call. You cannot behaviorally verify a package page. First confirm the URL is a live endpoint that answers a tools/list request. If it does not respond, there is nothing to trust yet.

2. What tools does it actually expose?

Fetch the live tool manifest — the exact tool names, descriptions, and input schemas the server presents to your agent. This is the surface that can hijack an agent, because in MCP a tool description sits in the model's context right next to its real instructions. Read it once, deliberately, before you approve.

3. Has the manifest changed since you approved it? (drift)

This is the one static scans structurally cannot do. Record a baseline of the manifest, then re-check it over time. If a tool description or schema changes — especially a description gaining new “also send…” or “first fetch…” language — that is the tool-poisoning / rug-pull pattern, and it happens at runtime, after a human said yes. A one-time approval cannot catch it; baseline-and-diff can.

4. Does it behave reliably over time?

Beyond safety, does the server actually work — uptime, success rate, latency — measured from real calls, not claimed in a README? A server that passes a code review can still be dead, slow, or swapped in production.

Run checks 1–3 free, right now

Paste your server URL into the free MCP drift check: it confirms the endpoint is live, fetches and shows the current tool manifest, records a signed baseline, and tells you if anything has drifted since a prior check. No signup. Machine-readable version at /api/drift; the pre-invocation trust check with a signed diligence receipt is at /v1/preflight.

Automate check 3 — the one that needs to run forever

Drift is not a one-time event; it can happen any day after approval. Continuous monitoring ($29/mo) re-checks your server every ~20 minutes, fires a webhook the instant its manifest changes, and keeps a signed, tamper-evident attestation trail for your security or compliance review. That trail is the evidence a reviewer asks for — not a badge, and not a scan from last quarter.

Honest scope

None of this is a full security audit or a guarantee, and we say so. It is behavioral verification: is the endpoint live, what does it expose, has it changed, does it work. Servers we cannot reach are shown unrated — never given a fabricated score. That honesty is the point: a trust signal you can't check is just another badge.


Check any MCP server's trust score: dominionobservatory.com/check

Browse all 40,000+ servers: Server Directory

← Back to all articles