Server identity claim matches transport identity
Authored by Stanley Hong · AgentReserve (founder).
`serverInfo.name` is lowercased and split on non-alphanumerics; tokens shorter than three characters and noise words (`mcp`, `server`, `service`, `api`, `the`, `official`) are dropped. The rule passes if any surviving token is a substring of the TLS certificate CN, any SAN, or the URL hostname (also lowercased). A name like "Slack MCP" served from `mcp.attacker.com` with no matching SAN is a passive identity-claim mismatch worth flagging. The check is deliberately generous — case-insensitive substring, any token — so single-word product names hosted on their own domain pass cleanly. False positives are possible on multi-tenant CDN hostnames (e.g. `*.cloudfront.net`) where the cert identity belongs to the platform, not the operator; treat a fail as 'investigate', not 'malicious'.
When this rule runs
Requires a successful MCP `initialize` / `tools/list`. Skipped on perimeter-only scans where the server refused or failed the MCP handshake.
Why it matters
An MCP server whose advertised identity disagrees with its wire identity is the canonical phishing-style impersonation pattern. The probe can't decide intent — but the mismatch is a passively-observable inconsistency that operators should investigate before trusting the surface.
Pass condition
After lowercasing, splitting `serverInfo.name` on non-alphanumerics, and dropping tokens shorter than three characters or in the noise list, at least one surviving token is a substring of the cert CN, any SAN, or the URL hostname.
Fail condition
Surviving tokens exist, but none of them are a substring of the cert CN, any SAN, or the URL hostname.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"tokens": ["slack"], "hostname": "mcp.attacker.com", "certCommonName": null}
Remediation
Make the `serverInfo.name` consistent with the certificate identity (CN/SAN) and the published hostname. Treat the name as an audit identifier, not marketing copy.
Methodology
This rule belongs to the Metadata transparency dimension. Whether the server identifies itself and documents its tools — and whether the advertised identity matches the wire identity (cert CN/SAN, hostname). Operators need a stable name, a version, and an internally consistent identity claim to perform any kind of audit.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.