GeezerVison

Is this for the top level route only? or for any route?

Any route.

Does this apply just to .well-known or outside of it?

Any route as applicable

What's a handler here? The distinction between JSON-RPC middleware and a transport middleware is exactly in the type information about the middleware. I would have expected that a JSON-RPC Middleware will return some Request or Response JSON-RPC handler, where as a transport or middleware just has a general type T that represents a transport and has some associated interface that is dependent on the SDK that middleware can manipulate.

The Handler in the example is illustrative; its shape depends on the language and SDK. By typed middleware I meant method-specific middleware, like tool calls, alongside arbitrary json rpc middleware. Both can be useful, and method-specific middleware stays a MAY.

I am not sure I understand the need for transport hooks. I feel a transport hook is strictly a subset of a middleware.

HTTP routing can be implemented through middleware, so “they are not middleware” is too categorical. Launch arguments and environment variables are configuration before a process starts. I'd describe routing and launch configuration as separate capabilities, without saying that routing cannot be implemented through middleware.

Agreed, routes can be implemented through middleware. Changed the wording to describe route contribution and launch configuration as separate capabilities.

I think saying that frameworks must provide a way for routing and launch configuration is enough (to @halter73's point)

On stdio, a client cannot reliably associate deprecated logging notifications with a particular operation. Should these messages still be interceptable without request correlation, or can they be excluded from the required client-side middleware coverage?

The host-framework section permits contributions through documented host composition. Does an extension still need to declare every contribution in one SDK registration, or can its package configure SDK services/filters and host middleware/routes separately? I'd like normal host configuration and options validation to satisfy this, with setup failures preventing activation, rather than require a combined plugin registration framework.

Separate host composition makes sense; clarified that a package can configure those contributions separately. I'd still keep dependency declaration and verification as capabilities the SDK provides.

HTTP routing can be implemented through middleware, so “they are not middleware” is too categorical. Launch arguments and environment variables are configuration before a process starts. I'd describe routing and launch configuration as separate capabilities, without saying that routing cannot be implemented through middleware.

Can we add a concrete example where dependency validation must happen during execution rather than during configuration? The examples here seem satisfiable with startup validation. In C#, we'd prefer required DI services and options validation where those suffice, rather than introduce a parallel dependency system.

One example is a mode selected from the peer's capabilities that needs another local extension. That dependency would be checked once the mode is selected, before it runs. These cases are fairly niche though; fixed dependencies can still be checked at startup.

What is the concrete use case for requiring runtime support introspection? An extension still needs an SDK-specific implementation and compatible SDK package versions to use these APIs. Could we use the standardized identifiers for documentation and conformance reporting while making the public introspection API optional?

Made this optional. It was added in response to core maintainer feedback, but I'm fairly flexible here. @dsp-ant, did I capture your suggestion correctly? It would help to understand the use case for making it required.

dynamic languages like Python might use that form of introspection to branch code to guarantee BC. E.g

match mcp.extension.version:
    case 2:
       mcp.extension.register(MyV2Extension())
    case 1:
       mcp.extension.register(MyV1Extension())

For me it just guarantees introspection.