Conversation
sambhav
changed the title
d24f348 to
2aefeb1
Compare
b85e643 to
123efe7
Compare
123efe7 to
636756c
Compare
felixweinberger
left a comment
felixweinberger
left a comment
There was a problem hiding this comment.
Thanks for putting this together!
Aligned on direction, I think there are a few things to potentially cut or clarify. I think we go a bit too deep into implementation details as opposed to behaviors the SDK should provide.
|
Thanks @felixweinberger, pushed 8cdf9b5 addressing all 12 threads. Main changes: the abstract is now a four-point TL;DR; the spec section has a full BCP 14 keyword sweep; scope is 2026-07-28+; dependency-check timing is left to the SDK; the checked registration path is extension-only, so existing replacement APIs (and MCP Apps) are unaffected; and the conformance and SDK testing detail is cut. Tasks and Action metadata are noted as operating outside these hooks as drafted, with how they could fit; any interface changes there are separate WG discussions. Re-requesting review. |
- Consolidate repeated rules into Conventions, General requirements, and Extension rules - Registering a method fixes its name and types; behaviour changes go through middleware or existing replacement APIs - Replace rollback atomicity with a no-partial-install rule - Require middleware ordering control, leave the mechanism to SDKs - Leave dependency check timing to SDKs, SHOULD check at startup - Make packaging guidance a SHOULD; trim terminology and appendix notes Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_015SKdZofPNU5AUcBGeV31is
Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_015SKdZofPNU5AUcBGeV31is
Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_015SKdZofPNU5AUcBGeV31is
felixweinberger
left a comment
felixweinberger
left a comment
There was a problem hiding this comment.
This LGTM now modulo one inline comment, would be great to get eyes from other SDK maintainers if this is something they'd be OK with supporting as a requirement.
Tagging Tier 1 maintainers of SDKs here as they'll be most affected for comment:
@guglielmo-san & @yarolegovich for Go
@halter73 for C#
@DaleSeo for Rust
@maxisbey + @Kludex for Python
@koic for Ruby
- Scope method-name and type rules to the extension registration path - State requirements as outcomes; leave mechanisms to each SDK - Drop the dependency matching rules; SDKs choose how dependencies are expressed - Clarify sending-direction middleware, stream handling, and cleanup - Allow any ordering mechanism; add optional named insertion points - Add -32603 guidance for dependency checks during request handling - Tie the Tier 1 requirement to the next spec release after Final - Move Ruby to Tier 1 in Appendix A - Add non-normative Appendix C with example stacking designs Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Hwbri51KtC2ugmjkNwKD7D
|
|
||
| An extension package bundles its capability declarations, dependencies, custom methods, and middleware. Applications enable it through the SDK's normal configuration mechanism. | ||
|
|
||
| ```typescript |
There was a problem hiding this comment.
maybe for each of the example stating that it's example/pseudo code? I know it's mentioned above but easy to miss when looking at plausible code.
|
|
||
| An extension can depend on the local configuration: core capabilities and their sub-features, or other registered extensions. The SDK decides how dependencies are expressed, for example as a predicate over the configuration, a declarative map, or types. The rules for what counts as a match belong to the SDK and the extension, not to this SEP. Dependencies are local: they add no wire fields and do not advertise support to peers. | ||
|
|
||
| - The SDK **MUST** evaluate dependencies against the final configuration, so registration order does not matter. |
There was a problem hiding this comment.
I'm not entirely sure about the dependencies here. "final configuration" isn't defined, and is up for interpretation.
In some servers capabilities could change at runtime, or vary per request, so there isn't always a point where configuration is final.
Could have something like "A dependency MUST NOT fail only because it was registered after the extension that needs it".
Although I'm still a bit unsure what the desired behaviour for dependency checking would be. Are there any examples of extensions that have dependencies on other extensions? Or suggestions on what that might look like?
This branch has not been deployed
9 participants
Read the rendered SEP
Summary
Bundling extension implementations into SDKs ties their maintenance and releases together. This SEP defines three public extension points so extension owners can publish independent packages and applications can compose them on one SDK:
Each SDK chooses APIs that fit its language. Static middleware composition can satisfy ordering; runtime inspection is optional. Extensions may expose named insertion points without exposing every internal middleware step. Packaging and API stability follow each SDK's existing public API and versioning policies.
Requirements target protocol version
2026-07-28and later. Tier 1 enforcement and conformance scenarios take effect with the first specification release after the SEP reaches Final; no separate deadline is introduced.The SEP adds no wire fields or methods. It states the extension rules under which these hooks are sufficient and leaves extensions needing more responsible for their SDK compatibility. Conformance follows SEP-2484; a complete reference implementation is still needed. Appendices assess existing SDK APIs and extension needs and illustrate optional middleware composition designs.
Validation
npm run prepdid not complete: this environment blocks the tsx CLI's IPC socket, and automatic approval review rejected a GitHub download used by the link-check dependency. Local checks usednode --import tsxthrough a temporary dependency launcher; no tooling changes are included.AI assistance
Codex assisted with drafting and editing the SEP, reviewing linked sources and comments, validating the changes, and drafting review replies, following my design decisions.