Check the CIS compliance of an MCP server
Cyberwatch evaluates the compliance of MCP (Model Context Protocol) servers with the CIS MCP Server Benchmark v1.0.0, published by the CIS in September 2026.
The 55 recommendations of the benchmark are available as compliance rules. Sixteen of them are checked automatically from the daily audit of the server. The others relate to the client, the hosting or the organization, and must be checked manually.
Create the MCP target
Compliance is evaluated on an asset of type MCP server. To create it, add a network target of type “MCP server”, by entering the exact URL of its endpoint.
The asset receives the “MCP Server” operating system, to which the rules of the benchmark apply.
Associate the repositories
A new MCP target automatically receives the CIS_Benchmark_level_1 repository, which gathers the 39 level 1 recommendations.
To also evaluate the 16 level 2 recommendations, add the CIS_Benchmark_level_2 repository, or CIS_Benchmark, which gathers both levels. These repositories are present by default in Cyberwatch.
How the evaluation works
The rules evaluate the facts collected by the last audit of the MCP server, without sending any new request to the server. The evaluation is run again after each audit whose result changes, and at least every 30 days.
Each automatic rule gathers several checks. Its output, visible in the “Compliance” tab of the asset, details them one per line, with their verdict and their finding:
- a check is compliant, non-compliant, or not evaluated when the audit does not allow a conclusion
- the status of the rule is Failed as soon as one of its checks is non-compliant
- it is Success if at least one check is compliant and none is non-compliant
- otherwise, it is Skipped
The output of the rule also lists what remains to be checked manually, for example in the logs of the server.
Recommendations checked automatically
| Rule | Level | Checks |
|---|---|---|
| CIS-MCP-1.1 | 1 | The server does not serve any protocol revision earlier than 2025-06-18, and rejects a request whose version is unknown, missing, or different between the MCP-Protocol-Version header and the body |
| CIS-MCP-1.4 | 1 | The server declares its name and its version (serverInfo) |
| CIS-MCP-2.2 | 1 | The server rejects clear-text HTTP or redirects it to HTTPS, negotiates TLS 1.2 or 1.3, rejects TLS 1.0 and 1.1, and presents a valid certificate |
| CIS-MCP-2.3 | 2 | An anonymous request is rejected (HTTP 401 or 403) |
| CIS-MCP-2.4 | 1 | A request without an Mcp-Method header is rejected (HTTP 400, JSON-RPC error -32020) |
| CIS-MCP-2.5 | 1 | A request whose Origin header designates a third-party site is rejected (HTTP 403) |
| CIS-MCP-3.1.2 | 1 | An anonymous request is rejected with HTTP 401, and the JWT token of the target is valid for at most one hour; a token valid for longer must be reviewed |
| CIS-MCP-3.2.2 | 1 | The audience of the JWT token of the target designates this server; a foreign audience must be reviewed |
| CIS-MCP-3.3.1 | 1 | The audience of the JWT token of the target designates this server; a foreign audience is non-compliant |
| CIS-MCP-3.3.2 | 2 | The OAuth metadata is served over HTTPS, designates the endpoint as a resource, announces at least one authorization server, and the issuer of each one matches its address |
| CIS-MCP-5.1.1 | 1 | The input and output schemas of each tool are valid JSON schemas |
| CIS-MCP-5.1.2 | 1 | Each resource template declares its MIME type |
| CIS-MCP-5.1.3 | 1 | Each prompt argument is named, and its required attribute, if any, is a boolean |
| CIS-MCP-5.2.3 | 1 | The server rejects GET and DELETE requests (HTTP 405) and does not send any Mcp-Session-Id header |
| CIS-MCP-7.1.2 | 1 | A request whose JSON-RPC identifier is null is rejected (HTTP 400, JSON-RPC error -32600) |
| CIS-MCP-10.1 | 1 | The response to tools/list has Cache-Control: no-store or private |
Rules 5.1.1, 5.1.2 and 5.1.3 produce one line per tool, template or prompt, and rule 3.3.2 one line per authorization server. Rule 3.3.2 does not apply to a server that does not publish OAuth metadata and does not require authentication.
The Mcp-Method headers and stateless sessions only exist from revision 2026-07-28 of the protocol: on an older server, the corresponding checks are not evaluated, and rules 2.4 and 5.2.3 have the Skipped status.
JWT token of the target
Rules 3.1.2, 3.2.2 and 3.3.1 read the token configured in the HTTP Bearer authentication of the target, if it is a JWT. Cyberwatch locally decodes its audience (aud) and its validity period (iat, exp), without verifying its signature or sending it anywhere other than to the audited server.
Without a JWT token, for example with an opaque token, these checks are not evaluated.
Recommendations to check manually
The 39 other recommendations cannot be checked by a remote audit of the endpoint. They relate in particular to:
- the MCP client and host (section 4 of the benchmark)
- local stdio servers
- the data processed by the server (section 6)
- its supply chain (section 8) and its isolation (section 9)
- its logs
- approved lists specific to your organization, for example the allowed capabilities or tools
- checks that would require calling a tool, reading a resource or getting a prompt
These rules have the Skipped status, with the mention “Manual verification required” followed by the reason. The page of each rule includes the audit procedure of the CIS.
Once a recommendation has been checked, it is possible to ignore the rule and to comment this choice.