Unreleased: not public yet. Maintainers have not reviewed this result.
Results / mcp-server-fetch
mcp-server-fetch
A
Protocol4/4 points
A
Network1/1 points · provisional
Coverage: covered (1 of 1 tools reached with a valid call).
Protocol checks
| Check | Verdict | What happened |
|---|---|---|
| protocol Valid MCP handshake and tool schemas | pass | handshake ok, 1 well-formed tool(s) |
| tool-poisoningcritical No tool-poisoning indicators in tool metadata | pass | scanned 1 tool definition(s), 1 prompt(s), including parameter text: nothing suspicious |
| robust-input Survives malformed tool input | pass | 4 invalid call(s) rejected cleanly |
| secret-echocritical No environment secret echoed in responses | pass | canary secrets absent from tools/list and 4 captured response(s) |
Network checks
| Check | Verdict | What happened |
|---|---|---|
| net-loopback-ssrfcritical Refuses loopback targets (SSRF) | pass | all 9 loopback probes were explicitly refused (the response said so) and the listener saw no request or connection |
| net-scheme-allowlistcritical Only http(s) schemes accepted | inconclusive | no scheme had an observable effect, but 3 of 7 probes were not explicitly refused, so a refusal cannot be told from a tool that cannot fetch at all (a reply that only reports a failed fetch (proxy, socket, DNS) is not read as a refusal; set net.control_url to a URL the tool can reach) |
| net-caps Response size and time are capped | n/a | the server refused loopback targets (net-loopback-ssrf passed), so there is no harness-owned URL it will fetch; response size and time caps were not measured |
| net-redirect Redirects are re-validated | n/a | the server refused or never reached the loopback listener, so redirect handling could not be observed (a server that blocks loopback cannot be sent a redirect it would follow) |
Effects checks
| Check | Verdict | What happened |
|---|---|---|
| annotation-honestycritical Read-only tools change nothing | inconclusive | every control call failed, so the read-only annotation could not be checked |
| openworld-honesty Closed-world tools stay on the machine | n/a | no tool declares openWorldHint: false that could be given a harness-owned control argument |
| undeclared-writes (advisory) Unannotated tools leave the sandbox unchanged | n/a | no unannotated read-style tool could be given a harness-owned control argument |
What was not covered
- Database: Not applicable. Server config has no {dsn}/{host}/... Placeholder, so the harness cannot start the server once per role
- HTTP: Not applicable. The server is started over stdio; the http pack needs server.url
- Files: Not applicable. No tool is classified as taking a file path with medium confidence or higher
- Git: Not applicable. No tool is classified as taking a git repository path with medium confidence or higher
- SQLite: Not applicable. No tool takes a SQL string
- Effects: Inconclusive. Every control call failed, so the read-only annotation could not be checked
- Tool "(observer)" was not covered by the effects pack: writes outside the sandbox (the real home, a store named by an absolute path in server.env or args) are not observed
- Tools that a server lists only for clients that declare roots, sampling or elicitation capabilities are not seen: the harness declares none
- SSRF: link-local and private-range addresses are never contacted; redirects from a public host to loopback and DNS rebinding are not tested (the harness contacts only its own loopback listener)
- The sandbox is a convention the harness follows, not a security boundary. A malicious server runs with your user's privileges, sees the real file system and network, and can ignore cwd, HOME and PATH. Run untrusted servers in a throwaway VM or container.
- Prompt injection carried in tool output (only tool metadata is scanned)
- Authentication and transport security
- Audit logging (not measured by these packs; only the db pack has an advisory audit check)
- The effects pack's calls do not count toward coverage: every check of the pack was inconclusive or n/a, or the server rejected every call before running it
Run it yourself
Started with the standard settings like this; put it in sealmark.yaml as the server:
uvx mcp-server-fetch==2026.10.10
Each of 613 verdicts was checked independently, and Sealmark was wrong on some: how reliable Sealmark is.
Think a verdict is wrong, or want a server removed? Email disclosure@sealmark.dev with the server version. We recheck, correct the page if we were wrong, and add your reply. See the disclosure policy.