SW-MCP-008: Uses deprecated Roots, Sampling or Logging
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 rule collects capability names from several places. The server's own capability maps are the probe's capabilities and the capabilities of the server/discover and initialize results; all three names are read there. The client side, clientCapabilities and requiredClientCapabilities, is read for roots and sampling only. Any name found is reported, in the order roots, sampling, logging.
If no capability is found, the rule reads each tool description once more and fires when one contains sampling/createMessage. It gives one finding per probe, with the names as evidence, for example logging, or tool NAME mentions sampling/createMessage.
Why it matters
Roots, sampling and logging are features of the earlier protocol that the 2026-07-28 specification replaces. Sampling lets a server ask the client to run a model call on its behalf, and a server that depends on it cannot work with a client that has dropped it. 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. Each of the three is a behaviour that your agents depend on and that can disappear in a client update.
Example
This recorded probe shows a server that declares the logging capability in its server/discover answer:
probe.json
{
"endpoint": "https://mcp.example.invalid/mcp",
"reachable": true,
"discover": {
"supportedVersions": [
"2026-07-28"
],
"capabilities": {
"tools": {},
"logging": {}
}
},
"capabilities": {
"tools": {},
"logging": {}
}
}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
Replace each feature as the migration checklist describes. Sampling is replaced by an input_required result. Logging becomes a log level carried in the metadata of each request. Then remove the capability from the server's declaration, so the probe no longer sees it.
If it is a false positive
The description check is a text search, so a tool that only explains in its description that it does not use sampling/createMessage is matched as well. Reword such a description, or accept the finding with a note that says the server never calls 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.