SW-MCP-007: Requires the initialize handshake; no server/discover
Last updated 7 November 2026
| Fact | Value |
|---|---|
| Severity | Medium |
| Checks | MCP server |
| Malicious indicator | No |
| OWASP Agentic Top 10 | ASI04 |
| OWASP MCP Top 10 | None mapped |
| NIST SP 800-53 | SR-3 (provisional mapping to SP 800-53 base controls) |
| First shipped in | Scanner 0.1.0 |
What it detects
The probe asks for server/discover first and falls back to initialize. The rule fires when it recorded an initialize result and no server/discover result. The two requests are tested only for presence: the contents of the answer, the version and the capabilities do not matter to this rule.
The evidence is initialize answered, server/discover did not, on the endpoint. The scanner records the same condition as the deprecated feature initialize_only. A server that answers server/discover, or one for which the probe recorded neither answer, is not matched.
Why it matters
The handshake makes a client open a connection and agree on a version before it learns anything about the server. The discovery request replaces it with one stateless question that any client, scanner or gateway can ask. A server without it is harder to inspect and harder to put behind shared infrastructure, and the 2026-07-28 specification no longer expects the handshake. The scanner maps this rule to OWASP ASI04, Agentic Supply Chain Vulnerabilities, and to NIST SP 800-53 control SR-3, Supply Chain Controls and Processes.
Example
This recorded probe holds an initialize result and no discover result, with the negotiated version 2026-07-28:
probe.json
{
"endpoint": "https://mcp.example.invalid/mcp",
"reachable": true,
"initialize": {
"protocolVersion": "2026-07-28",
"capabilities": {
"tools": {}
}
},
"negotiated_version": "2026-07-28"
}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.
How to fix
Add a server/discover handler that returns the supported versions, the capabilities and the server information, the same data the handshake returned. It is the second item of the migration checklist. You may keep the handshake for older clients while they still need it, because the rule stops matching once the discovery request is answered.
If it is a false positive
A server that supports the discovery request on a path the prober does not use would be reported wrongly, because the probe only asks at the endpoint it was given. Check that the endpoint in your configuration is the one that serves both requests.
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.