Your MCP server is about to be
plugged into someone's AI.
Is it safe?

Free security scan for Model Context Protocol servers. Paste your endpoint and get a grade in ~30 seconds — 45+ read-only checks across the current 2026-07-28 stateless revision and its predecessors — protocol conformance, OAuth behaviour, DNS-rebinding defence, header/body agreement, tool-poisoning patterns and information leaks — every finding mapped to its control and to the OWASP MCP Top 10.

Read-only, safe probes. We never call your tools. Auth-gated server? Add a staging token for a full-depth scan. By scanning you confirm you're authorized to test the target — see Terms.

Why this exists

MCP became the standard way to plug tools into AI assistants — and the plugs went in faster than anyone inspected them.

40+CVEs against MCP implementations, Jan–Apr 2026
~200,000servers assessed vulnerable in one April 2026 advisory
NSA/CISApublished dedicated MCP security guidance, June 2026

What we check

Transport security

TLS version, HSTS, CORS, server banners — and the Origin-validation test the MCP spec makes mandatory against DNS-rebinding.

Current-revision conformance

The 2026-07-28 stateless core: mandatory server/discover, MCP-Protocol-Version and Mcp-Method header/body agreement (a gateway must not route on one value while the server executes another), version negotiation, retired GET stream and session ids, and x-mcp-header annotations that conforming clients mirror into real HTTP headers.

Protocol correctness

Discovery or handshake, capabilities, error behaviour on unknown methods and malformed input, session-id strength on older revisions.

Auth & authorization

RFC 9728 resource metadata, WWW-Authenticate on 401s, rejection of garbage tokens, anonymous access to non-read-only tools.

Tool hygiene

Static analysis of tool descriptions for prompt-injection and concealment patterns, invisible unicode, unannotated destructive tools.

Resources & prompts

Anonymously enumerable resources, credential- and system-path URIs exposed as context, and injection patterns hidden in prompt definitions.

Information disclosure

Stack traces on malformed input, exposed .env / debug / status endpoints, version and banner leaks, TLS certificate expiry.

Read-only by design

The scanner never calls your tools and never writes. Aggressive tests run only with your staging credentials, on request.

Or run it where your code lives

The same engine ships as a CLI. It runs entirely on your machine — so tokens never leave it — and it can scan local stdio servers, which is how most MCP servers actually run.

# install (PyPI release pending — this wheel is the same build)
pipx install https://codeflowops.com/dist/mcpscan-0.4.0-py3-none-any.whl

# scan a remote endpoint
mcpscan https://your-server.example.com/mcp

# scan a local stdio server — nothing touches the network
mcpscan --stdio -- npx -y @modelcontextprotocol/server-filesystem /tmp

# authenticated scan (token stays on your machine)
mcpscan https://your-server.example.com/mcp --token "$STAGING_TOKEN"

# deep scan: call read-only tools, scan responses for leaked secrets / PII
mcpscan https://your-server.example.com/mcp --token "$STAGING_TOKEN" --deep

# rug-pull detection: pin tool definitions now, diff on every later scan
mcpscan https://your-server.example.com/mcp --baseline

Why the deep checks live only in the CLI

This website never calls a tool and never needs your credentials — every check it runs is one anyone could run against a public URL. Anything that executes a tool or reads a real response runs only on your machine, where the credentials already live and nothing is uploaded. The deep scan calls only tools the server itself annotates readOnlyHint: true, with ordinary inputs, and never sends adversarial payloads. We think that is the right shape for a security tool, and it is enforced in code, not policy.

Gate it in CI

- uses: ClayDesk/mcpscan@v1
  with:
    url: https://your-server.example.com/mcp
    fail-on: fail        # none | warn | fail | critical

Exit codes make it a gate: 0 clean · 1 threshold breached · 2 scan error. The job summary gets a Markdown table of findings, and --json writes a machine-readable report for your own tooling.

Continuous verification is coming

A daily re-scan of your production endpoint, alerts when something regresses, a signed verification attestation your enterprise customers can check, and a public directory entry. Join the list — early members set the roadmap.

Frequently asked questions

Is the scan safe to run against production?

Yes. The scanner performs the standard MCP handshake, lists tools, and sends a few malformed-input and header probes. It never executes tools, never writes, and caps every request in size and time.

My server requires authentication — what will you see?

We grade the unauthenticated surface (which is what an attacker sees): TLS, origin validation, 401 behaviour, resource metadata, leak paths. Full-depth authenticated scans with staging credentials are available via the optional token field.

What are the grades based on?

Each finding is weighted and mapped to the control it derives from: the MCP specification (Streamable HTTP and Authorization sections), the NSA/CISA MCP security information sheet (June 2026) and OWASP guidance. Any critical finding caps the grade at F.

Are you affiliated with Anthropic or the MCP project?

No. CodeFlowOps is an independent scanner operated by ClayDesk LLC. We test against the published specification and public security guidance; we don't issue official MCP certifications.

I don't want to paste a bearer token into a website.

Then don't — run the CLI instead. It is the same scanner, executes entirely on your machine, and never uploads anything. See CLI & CI.

Most MCP servers run locally over stdio. Can you scan those?

Yes, with the CLI: mcpscan --stdio -- npx -y your-server. It launches the server, speaks JSON-RPC over its pipes, and runs the protocol and tool-hygiene checks plus stdio-specific ones (stray output on stdout, credentials in startup logging). The hosted web scanner can only reach servers published on the internet.

Why did my public server get a warning instead of a failure?

Severity depends on deployment. A server that ignores the Origin header is a spec-conformance gap on a public read-only service, but a genuine exposure on an authenticated or state-changing one — so the same observation is graded differently. The report names which profile it detected.

Can you check what my tools actually return?

Yes — locally. mcpscan … --deep calls the tools your server annotates readOnlyHint: true with ordinary inputs and scans the responses for leaked credentials (AWS, GitHub, Slack, Stripe, private keys, JWTs, connection strings), regulated identifiers, bulk personal data and injected instructions. Unannotated tools are never called, nothing adversarial is ever sent, and none of it is available on this website: it runs on your machine or not at all.

How do I know a tool hasn't changed since I approved it?

That is the rug pull, and hosts never tell you. mcpscan … --baseline pins a fingerprint of every tool definition locally on the first run and reports any later change to a description, read-only annotation or schema until you accept it with --pin. Put it in CI and a silently altered tool fails the build.

Which MCP revision do you test against?

The scanner tries the current 2026-07-28 stateless revision first (per-request protocol metadata, mandatory server/discover) and falls back to the initialize handshake used by 2025-03-26 through 2025-11-25, exactly as the specification's backward-compatibility rules describe. The report states which era your server speaks. Running an older revision is reported but never penalised in the grade — protocol currency is not itself a security defect.

Do you map to the OWASP MCP Top 10?

Yes, and honestly: each finding carries its category, and the report shows a coverage strip. Three categories — supply chain (MCP04), audit and telemetry (MCP08) and shadow servers (MCP09) — cannot be established by probing one URL, so they are greyed out rather than dressed up as covered.

Do you store my scan?

The report is stored so you can share its link. We don't store credentials — tokens you provide for authenticated scans are used in-flight and discarded.