Assessment / From an input to its evidence
Scan your MCP server.
See what the test reached.
Submit a URL, paste the npx or uvx line from a README, paste your MCP client configuration, or point at a GitHub repository or npm package.
Run an assessment against up to 184 deterministic detection rules. The form states what your input can reach; the resulting report shows which checks actually ran. Opening this page starts nothing.
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.
02
Check the boundary.
Read the outcome.
Live URLs expose a read-only declared surface. A fetched package can also expose runtime observations where a worker first proves filesystem confinement and blocked network egress. The report separates what ran, what answered and what remained untested.
An unavailable input, a refused execution and a failed tool response stay visible as assessment limits.
Follow the evidenceThe result belongs to its evidence
Keep the finding. Keep its limits.
Inspect the finished run before opening its report. Exported assessments carry their findings, coverage and method; a signed report requires signing credentials on the deployment.