Scan your MCP server
Run a security scan against up to 184 deterministic detection rules - the form below states what your input can reach, and the report shows which rules actually ran. Submit a URL, paste the npx or uvx line from a README, paste your MCP client config, or point at a GitHub repo or npm package.
A remote MCP server endpoint (HTTP / SSE). Add a credential below if it is auth-walled.
Sent as request headers on the MCP handshake. Optional - leave blank to scan anonymously.
- Used for this scan, never stored. The credential is held in memory for the length of one scan. The saved record keeps the URL and the results - never the headers you enter here.
- A token does not widen what we call. The scanner still only calls
initializeandtools/list. What may be invoked is bounded by whose server is on the other end, not by what credential we are holding - there is no path here that invokes one of your tools. - A refused credential is reported as its own result. If the server rejects it you get credential-rejected - the credential reached the server and was refused - which is a different finding from this server requires authentication, which means we arrived with nothing. If the report says the scan connected anonymously, what you entered never reached the scanner.
Read-only enumeration - initialize and the list methods only; a live URL is never sandboxed.
Checking what this input can reach…
- Static analysisnot from a live URL
- Read-only enumerationinitialize and the list methods only
- Sandbox runnever - a live URL is never sandboxed
- Cross-server analysisneeds a config with at least two entries
- Drift baselineneeds an earlier scan of the same target
Full registry scan - all 184 active rules in scope
Every one of the 184 active rules is browsable and individually selectable above - nothing a full registry scan runs is hidden from this catalogue.
Combine servers into a composition
Combine two or more public registry servers and ask which cross-server patterns their capabilities could compose. Only servers listed in the registry can be combined - a remote endpoint, a local file, or anything carrying credentials is left out, and nothing you paste beyond the package a server runs is ever sent.
What gets checked
Live URL
Connects over MCP, enumerates tools, resources and prompts, and runs the rule families a declared surface can answer - description, schema, protocol-surface and adversarial-AI; the form above states the ceiling. Supply a header and an auth-walled commercial server is reachable too - the scan still only calls initialize and the read-only list methods, never a tool.
Launch command & config
A stdio entry - npx -y @scope/server - names a published package. We read the name off the command, download that exact release, verify its registry integrity and analyze it. When this deployment has a sandbox runner, that release is also launched there by default and its tools are invoked - our own copy, in a sandbox that must first prove it blocks network egress and confines the filesystem; without one nothing is executed, and the report says which. This is most of the MCP ecosystem.
GitHub / npm source
Fetches the source and dependency manifest, so the code-analysis, dependency and supply-chain rule families can run; a published npm or PyPI package is also launched in the sandbox by default where a runner exists, reaching the tool-surface rules too - a ceiling, not a promise: the report shows which of the 184 rules actually ran. A monorepo subpath (/tree/main/src/thing) is scanned in scope, not from the repository root.
Honest coverage
Every report says what it did not check. A rule that never got its inputs is reported as never checked - a coverage gap, not a pass - and kept distinct from a rule that had its inputs and found the project genuinely clean.