Server identifies itself
Authored by Stanley Hong · AgentReserve (founder).
The `initialize` response includes a `serverInfo.name` so operators can recognize the implementation and cross-reference it with upstream advisories.
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
Operators need an implementation name (and ideally a version) to recognize the server, cross-reference it with upstream advisories, and pin known-good builds.
Pass condition
The `initialize` response carries a `serverInfo.name` field.
Fail condition
The `initialize` response omits `serverInfo` or returns an empty name.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"serverInfo": null}
Remediation
Return `serverInfo: { name, version }` from `initialize` with a stable implementation identifier and the deployed version.
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.