SW-MCP-001: Server lists tools without authentication
Last updated 7 November 2026
| Fact | Value |
|---|---|
| Severity | High. Since scanner 1.9.0 the finding is graded by what the unauthenticated list exposed. It is low when the probe read the whole list and the list holds no tool, medium when every listed tool declares readOnlyHint true and does not declare destructiveHint true, and high in every other case. A list the probe could not read, a nextCursor that names a later page, more than 200 tools, an entry without a string name and a pasted list are all graded high. A read-only hint is written by the server, so it lowers the finding to medium and never further. |
| Checks | MCP server |
| Malicious indicator | No |
| OWASP Agentic Top 10 | None mapped |
| OWASP MCP Top 10 | MCP07 |
| NIST SP 800-53 | AC-3 (provisional mapping to SP 800-53 base controls) |
| First shipped in | Scanner 0.1.0 |
What it detects
The rule judges one recorded probe of a server. The probe sends the protocol's own requests with no Authorization header and no cookie. When the unauthenticated tools/list request is answered with status 200, the server is classified as having no authentication and the rule fires, once, on the endpoint. A probe that stopped at an http address is not judged here, because it never reached the server (see SW-MCP-009).
The evidence is the sentence tools/list answered 200 with N tools. A 401 or 403 answer is never matched, however weak the authentication behind it is: those cases are SW-MCP-002 and SW-MCP-003.
Why it matters
A server that lists its tools to anyone also tends to run them for anyone. The tool names, descriptions and input schemas show an outsider which actions exist and how to ask for them, and for a server with no access control the same address accepts the calls. The scanner maps this rule to OWASP MCP07, Insufficient Authentication & Authorization, and to NIST SP 800-53 control AC-3, Access Enforcement. The missing credential check is where a leaked or absent token would otherwise be caught.
The risk depends on what the tools do. A public documentation search that offers one read-only tool exposes little; a server that can write to a database or send messages exposes a lot. That is why the finding is graded.
Example
This recorded probe shows a server at a made-up address that answered the unauthenticated tools/list request with 200 and one tool. The list was not marked as read whole and the tool declares no hints, so the finding is high:
probe.json
{
"endpoint": "https://mcp.example.invalid/mcp",
"reachable": true,
"unauthenticated_status": 200,
"tools": [
{
"name": "search_notes",
"description": "Searches release notes.",
"annotations": {}
}
],
"tools_source": "probe"
}A server check judges what a probe recorded, not files. The recorded probe above is read the way the scanner's README describes under Evaluating an MCP server probe.
Adding the field tools_complete as true and readOnlyHint as true on the tool would lower the same finding to medium.
How to fix
Require authentication before the server answers tools/list. The migration checklist asks for OAuth with RFC 9728 protected resource metadata and lists the steps. A server that has to stay public should say so in its tool annotations: mark each tool that only reads with readOnlyHint, and keep the list short.
If it is a false positive
A server that is public on purpose, such as a documentation or reference search, is a real match of this rule and is not a mistake. Its finding is already graded down when the tools declare themselves read-only. Accept what remains with a note that names the server's purpose and who runs it.
If the finding is not a problem in your case, accept it with a note: in the dashboard a manager or owner can accept a finding and the note is kept with it; with the scanner on its own, add it to the baseline file with a reason and an expiry date.