Re-vendor 2026-07-28 schema at spec ead35b59 (SubscriptionsListenResult)#3006
Conversation
Picks up modelcontextprotocol/modelcontextprotocol#2953, the only schema/draft change since the previous vendor pin (2852f30e). The diff is purely additive: SubscriptionsListenResult and SubscriptionsListenResultMeta are added to $defs, and SubscriptionsListenResult joins the ServerResult union. - schema/2026-07-28.json + PINNED.json bumped; v2026_07_28/__init__.py regenerated. SubscriptionsListenResultMeta added to OPEN_CLASSES so it preserves arbitrary _meta keys, matching NotificationMetaObject. - mcp_types: SubscriptionsListenResult added to the monolith and ServerResult union (before InputRequiredResult, which must stay last); subscriptions/listen rows in methods.py now point to it instead of EmptyResult. - lowlevel server: on_subscriptions_listen return type follows the new result. - tests/types: fixtures and EMPTY_SERVER_RESPONSE_METHODS updated; SubscriptionsListenResultMeta skipped in parity (modelled as Meta dict in the monolith, same as the other *MetaObject types).
There was a problem hiding this comment.
I didn't find any bugs — the regenerated wire models, method maps, and test updates all follow the established re-vendor pattern from #2912 — but since this changes protocol type definitions (ServerResult union, subscriptions/listen result mapping, the on_subscriptions_listen handler signature) and bumps the vendored spec pin, it's worth a maintainer's confirmation that the vendored schema matches upstream ead35b59.
Extended reasoning...
Overview
This PR re-vendors the 2026-07-28 draft schema at spec commit ead35b59, adding SubscriptionsListenResult / SubscriptionsListenResultMeta to the vendored JSON schema, the generated v2026_07_28 wire models, and the monolith types. It also rewires subscriptions/listen result mappings in methods.py (surface and monolith maps) from EmptyResult to the new type, updates the lowlevel on_subscriptions_listen callback annotation, adds SubscriptionsListenResultMeta to OPEN_CLASSES in the codegen script, and updates the methods/parity tests accordingly. Ten files changed, but most of the diff is generated or follows the prior re-vendor pattern.
Security risks
None apparent. The change is additive type plumbing: no auth, crypto, transport, or input-handling logic is touched, and there is no runtime caller of the new result type yet. The only slightly sensitive knob is marking SubscriptionsListenResultMeta as an open (extra="allow") class, which matches how the other *MetaObject classes are treated and is consistent with the spec's MetaObject semantics.
Level of scrutiny
Moderate. The hand-written pieces (union ordering with InputRequiredResult kept last, methods-map rows, OPEN_CLASSES entry, test fixtures) are internally consistent and verified by gen_surface_types.py --check plus the methods/parity test suites. However, this is a protocol-type definition change for the SDK and includes a vendored-schema pin bump whose fidelity to the upstream spec commit can't be verified from the diff alone — that spec-alignment judgment is best left to a maintainer. The on_subscriptions_listen return-type change is technically a signature change on a public constructor parameter, though the author notes there is no runtime caller yet.
Other factors
The bug-hunting pass found no issues, test coverage of the new type is thorough (result fixtures, required-field rejection, parity skip-list), and the PR description is detailed about the conformance-suite gap. There are no prior reviews or outstanding comments on this PR.
Re-vendors
schema/draft/schema.jsonat spec commitead35b59to pick up modelcontextprotocol/modelcontextprotocol#2953, the onlyschema/draft/change since the previous vendor pin (2852f30e, set by #2912). Specmainis 20 commits past2ffc3fa2(#2953's merge) with no furtherschema/draft/changes, so this brings the vendored schema fully up to date.The schema diff is purely additive:
SubscriptionsListenResultandSubscriptionsListenResultMetaare added to$defs, andSubscriptionsListenResultjoins theServerResultunion.Motivation and Context
Part of #2901. The
subscriptions/listenruntime work needs the result type to exist before it can land; today the lowlevelon_subscriptions_listenslot is typed to returnEmptyResult, which is no longer the spec-correct shape post-#2953.How Has This Been Tested?
gen_surface_types.py --check, pyright, ruff, and./scripts/test(full suite, 100% coverage, strict-no-cover clean).Breaking Changes
None for users —
SubscriptionsListenResultis a new type and nothing previously consumedsubscriptions/listenresults. The lowlevelon_subscriptions_listencallback's return type changes fromEmptyResulttoSubscriptionsListenResult, but per the design that handler is registered by the entry-side router rather than user code, and there is no runtime caller yet.Types of changes
Checklist
Additional context
SubscriptionsListenResultMetais added toOPEN_CLASSESso the generated wire model preserves arbitrary_metakeys, matchingNotificationMetaObject(both areMetaObjectextensions; neither carriesadditionalPropertiesin the upstream JSON Schema, so the codegen default would have closed them)._metastays the lenientdict[str, Any]inherited fromResult(soSubscriptionsListenResultMetaisSKIP-listed intests/types/test_parity.pyalongside the other*MetaObjecttypes), and the class sits in theServerResultunion immediately beforeInputRequiredResult, which must remain last.b18aa918(this repo's pin and conformancemainHEAD) is itself pinned to specf817239f— pre-fix: normalize OAuth redirect URI URL subtypes #2953 — and has no scenario asserting thesubscriptions/listenresult body. Its existingsubscriptions/listenchecks inserver/stateless.tsonly inspect notification frames on the stream. I'll raise a conformance issue to bump the spec-types pin and add a result-shape check; this PR does not change conformance behaviour either way (the new type is not yet emitted by any runtime path).