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

we currently only have middleware on http transport level, this needs protocol level i understand

I wonder if we need to change that template to ensure this is sponsored by a WG.

Should we separate these into categories like:

1. Extensibility requirement
2. Stability requirements
3. Lifecycle requirements

We have a section around middleware ordering but not about ordering for extensions. I assume they are quite similar as extension ordering informs middleware ordering. We should be explicit about that.

We should have for each of these top level categories such as Middleware, Custom Methods, ... a subsection Requirements that clearly defines the associated semantics for that required functionality.

I don't think this sentence makes much sense. There is no default for middleware.

I don't think we advice extensions what to do, whatever works for them honestly.

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.

Can't this be done via a transport middleware? I am not sure we need to be explicit about this

Yes, but generic middleware support doesn't necessarily give an extension access to the host router's matching and conflict handling. I'd keep the explicit requirement that extension packages can contribute routes through normal host composition, without requiring an MCP-specific route API.

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.

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.

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.

Yes, but generic middleware support doesn't necessarily give an extension access to the host router's matching and conflict handling. I'd keep the explicit requirement that extension packages can contribute routes through normal host composition, without requiring an MCP-specific route API.

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.