mcp_schema: key the baseline on (server, client, protocolVersion, auth) not server alone

[blitzcrieg1]

Why

r/mcp feedback (2026-08). tools/list is a function of the negotiated session, not only the server build. The initialize exchange carries protocolVersion and the client's declared capabilities, and a server may legitimately list a different catalog for a different client or protocol version.

Two agents on one machine, same config file, different client versions, can get different tool sets for entirely benign reasons. Today that flips the digest back and forth and the noise originates here, not at the server.

What exists now

parse_initialize_result (added in #108) captures serverInfo.version and capabilities.tools.listChanged. It does not capture protocolVersion, and nothing looks at the initialize request, so clientInfo is never seen.

SchemaStore.servers is keyed by server name alone:

servers: dict[str, SchemaRecord] = field(default_factory=dict)

Proposal

1. Extend parse_initialize_result to capture protocolVersion. Add a parse of the initialize request for clientInfo.name and clientInfo.version.
2. Widen the store key to (server, client, protocolVersion, auth principal). Auth principal is #105 and should land as one key rather than two passes over the same file.
3. Publish client identity as a hashed id, the way server_id() already does for server names. Client name and version are low-sensitivity but the module's rule is that names stay on the machine.

Constraints

• Additive format bump. The store file, SchemaRecord, the heartbeat mcp_schema_digest and the Splunk prev_schema compare all read the current shape.
• Splitting the baseline multiplies the number of baselines per server, which makes the first-observation problem worse rather than better. A new client version starts with no baseline and must not read as a removal.

Acceptance

Two agents with different client versions against one unchanged server produce no rug-pull-shaped finding.

Source

Peer review on https://www.reddit.com/r/mcp/comments/1vvinyo/

[Santoshkumarpuppala]

The constraint you name at the bottom is the whole problem, and I would put it more strongly: widening the key multiplies the trust-on-first-use surface, and TOFU is where pinning schemes fail.

There is a sharper version of it hiding in the key composition. clientInfo.name and clientInfo.version are self-asserted by the client and never verified — nothing in initialize authenticates them. So a key containing clientInfo is a key an attacker can move. Bump the declared client version by one and you land in a tuple with no prior, which by your own first-observation rule is not a removal and not a change — it is a fresh baseline, silently trusted. That is the rename hole from the tool-name case, generalised to the session key: anything self-asserted that participates in the key becomes a free re-baseline primitive.

The auth principal from #105 does not have that property, because it is authenticated. protocolVersion is negotiated rather than asserted, so it sits somewhere in between and is at least bounded by what the server will agree to. My suggestion would be to split the tuple by that distinction rather than treating the four components alike: authenticated components in the key, self-asserted components recorded as metadata on the record. You keep the diagnostic value of knowing which client saw what, without letting a client mint baselines.

On the first-observation problem itself, the fix that worked for me is to stop treating an unseen key as having no prior. On a miss, fall back to the nearest existing baseline for the same server and emit the diff as its own state — "new session shape, differs from the closest known baseline in these N tools" — rather than either silence or a rug-pull finding. It is a third outcome, it is cheap, and it means the multiplication costs you noise rather than coverage. A pin that silently trusts every new key is the failure mode I shipped: mine is keyed per tool name and trust-on-first-use, so a renamed tool has no prior, registers as new rather than changed, and the integrity check never runs (https://github.com/norviq-dev/norviq).

One thing worth measuring before paying for any of this: sample the same server across two client versions and see how often the catalog actually differs. If benign divergence is rare, keying on server with the tuple recorded as metadata gets you the diagnosis without the multiplied keyspace, and your acceptance criterion is then satisfied by suppressing a known-benign diff rather than by splitting the store.

[blitzcrieg1]

This breaks the design in this issue and I am glad it arrived before the code did.

clientInfo.name and clientInfo.version are self-asserted by the client and never verified. So a key containing clientInfo is a key an attacker can move.

Correct, and the proposal above walks straight into it. Keying on (server, client, protocolVersion, auth principal) makes two of those four fields attacker-controlled. Bump the declared client version by one and you land in a tuple with no prior, which under the first-observation rule is a fresh baseline rather than a change. One field, no alert.

Worse, this repository had already written the reasoning down and then failed to apply it. parse_initialize_result carries a comment saying serverInfo.version is attacker-controlled, so it discriminates benign churn and is not a security boundary. That was right. This issue then put a sibling field, from the same unauthenticated handshake, into the key itself. A discriminator you read alongside a verdict and a key that decides which baseline you compare against are not the same kind of thing, and I treated them as though they were.

Where that leaves the design

The premise of the issue survives: an expired token really does make an unchanged server look like a rug pull, and that needs fixing. What does not survive is fixing it by widening the key with self-asserted values.

Constraints this now has to satisfy:

1. Nothing an unauthenticated peer asserts may select the baseline. That rules out clientInfo outright, and probably protocolVersion too, since it is negotiated rather than authenticated.
2. A key miss must not be silently trusted. Any widening multiplies first-observation surface, and mcp_schema: a re-baseline must be distinguishable from a first sighting #146 covers why a silent re-baseline is worse than a loud false positive.
3. Auth principal is different in kind from the other three: it is something the operator's own environment knows, not something the server or a peer tells us. It may be the only one of the four that belongs in a key at all.

An alternative worth weighing: keep the key narrow at server identity, and treat auth state as an annotation that suppresses or downgrades a verdict rather than as part of the key. Fewer baselines, no attacker-movable selector, and the expired-token case becomes "digest moved while auth state also changed", which is a conjunction rather than a partition. That is the same shape as the config-versus-schema conjunction the whole detector is built on.

I have not decided. If anyone wants to argue for keying on auth principal properly, that is the open question.

Thank you. This is the second design of mine you have corrected before it shipped.

[Santoshkumarpuppala]

The thing you found in your own repo is the more interesting half, and it generalises past this issue.

parse_initialize_result carries a comment saying serverInfo.version is attacker-controlled, so it discriminates benign churn and is not a security boundary.

That comment was right, and the failure was not noticing that a key is a security boundary in a way a discriminator is not. A discriminator sits next to a verdict and can be wrong without changing what the verdict compares against. A key decides which prior exists, and a wrong key does not produce a wrong answer — it produces no comparison at all, which reads as silence rather than as an error. That asymmetry is why self-asserted values can be safe in one position and unsafe in the other, and it is not obvious from either field's type.

On the constraint you have now written down — nothing an unauthenticated peer asserts may select the baseline — one addition, because it is the case I got wrong. The auth principal from #105 is authenticated and therefore safe to key on, but it is not stable: a token rotation, a credential re-issue, or a service-account change moves it without anything about the server changing. So it satisfies the constraint and still multiplies baselines, just less often and less controllably than clientInfo would.

Which points at the same third outcome as before: on a key miss, fall back to the nearest existing baseline for that server and report the diff as its own state, rather than treating an unseen key as having no prior. Then a rotated credential is a labelled event instead of a silent re-baseline, and the constraint holds without the keyspace deciding your coverage.