Rule catalog · Metadata transparency

Server advertises the latest published version of its upstream package

serverInfo_advertises_current_published_versionmediumweight 4Post-handshake

Authored by Stanley Hong · AgentReserve (founder).

When `serverInfo.name` matches a known-published MCP server in the in-tree allow-list (initially the official `@modelcontextprotocol/*` namespace), the advertised `serverInfo.version` matches the registry's `latest` dist-tag. The lookup is cached for one hour per package, never reaches a registry outside the allow-list, and returns `not-applicable` when the server isn't covered. Tier-final / T2.6 — minimum-viable manifest provenance.

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

A self-reported `serverInfo.version` is just a string until something validates it. Operators who pin a known-published server to an old version may be running a build with publicly-fixed bugs (or, less generously, are misrepresenting the build to clients). For the canonical MCP server families we can validate the claim against the registry that publishes them; outside that allow-list the rule stays not-applicable to avoid penalising private deployments.

Pass condition

`serverInfo.name` matches an allow-list entry, the registry returned a `latest` version, and `serverInfo.version` is byte-identical to it.

Fail condition

`serverInfo.name` matches an allow-list entry, the registry returned a `latest` version, and `serverInfo.version` is missing or differs.

Evidence examples

When the rule fails, the report records evidence in roughly this shape:

  • {"matched": "@modelcontextprotocol/sdk", "advertised": "0.4.0", "latest": "0.6.0"}

Remediation

Roll forward to the latest published release of your upstream MCP server, and pin a stable `serverInfo.version` that matches what your deployment actually runs. If the older version is intentional, document it on a changelog page the report can link to.

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.