Answering "do we have a test suite that tests conformance with 2026-07-28?" —
until now, no. What existed tested that lmcp enforces 2025-06-18, the revision
we are migrating away from.
Cut from the specification pages themselves, fetched 2026-08-09, not from the
changelog and not from any second-hand delta:
/specification/2026-07-28/ (index)
/specification/2026-07-28/basic (messages, _meta, error codes)
/specification/2026-07-28/basic/versioning (version negotiation)
/specification/2026-07-28/server/discover (DiscoverResult shape)
/specification/2026-07-28/basic/transports/streamable-http (headers, statuses)
That mattered: the delta-derived draft had two field names wrong. It is
`supportedVersions`, not `protocolVersions`, and `serverInfo` lives inside
`_meta`, not at the top level. The spec also carries requirements the changelog
never mentioned — a request missing a required `_meta` field must be refused
with -32602 AND HTTP 400, and the version rejection carries `data.requested`
alongside `data.supported`.
Every check quotes the normative sentence it comes from, so a failure names its
source rather than my reading of it. Both the JSON-RPC code and the HTTP status
are asserted, because the spec normalises both: a body-only check would pass a
server answering 200 where 400 is required.
Measured against today's lmcp: 26 of 27 open. The one pass is -32601 for an
unknown method, and even that returns HTTP 200 instead of 404.
Notable among the open points: initialize, ping and logging/setLevel still
answer though they are removed; -32002 is still emitted where the spec says MUST
NOT; no result carries the now-mandatory resultType; no header is validated; GET
on the endpoint returns 200 instead of 405.
A high number here is the measurement, not a defect of the suite: it is the
distance to the target.
marfrit
6530d9d318