Thank you for your contribution.

My initial reaction is that I am not entirely sure if this is something that belongs in the core protocol, as it could go against one of our design principles. The current SEP proposes model segmentation that I am not aware of any clients doing today (or whether they have any appetite to do so).

If _meta already solves this, I do wonder why this needs an annotation. My worry here is that we're introducing "annotation bloat" - a bunch of protocol-encoded conventions that may or may not be used by clients.

@SamMorrowDrums @sambhav @olaservo @LucaButBoring would like your input here.

Additional resources to check out:

• SEP-1984: Comprehensive Tool Annotations for Enhanced Governance and UX #1984 (from @sambhav)
• Add blog post for Tool Annotations #2230 (for guidance on tool annotations we expect to publish soon)

Using _meta in the existing/demo/workaround solution implies a custom client, so I don't consider that a particularly compelling point against this in its own right unless the entire point is only to accommodate a custom client. Will think through this more later (traveling right now).

Just to add a bit more color as to why I think it goes against the "Capability over compensation" design principle. Based on this sep, we'd be making a long-term bet that model performance and cost will remain at a big delta where certain tools can be invoked with, say, cheaper and less intelligent models vs. more expensive and more intelligent ones. I don't know to what degree that will hold in the future (which, of course, is hard to predict).

This feels like something the client can potentially determine on their end, which is what VS Code does today - based on prompt and tool descriptions (since those are accessible), each client can make their own determination.

Thanks @localden.

On the "Capability over compensation" point: the design principle itself says "Optional context that weaker models lean on and stronger ones ignore costs nothing." That's literally what modelPreferences is. Optional, ignorable, zero cost to clients that don't care. And the bet here isn't that models stay dumb. It's that pricing tiers will always exist. Haiku is 5x cheaper than Opus right now ($1/$5 vs $5/$25 per MTok). You don't want to burn Opus tokens on list_organizations. That's not a capability gap, it's just economics.

On VS Code's auto model selection: I actually think that link supports this SEP. Their current implementation routes based on capacity and rate limits, not task complexity. The blog says they want to "dynamically switch between small and large models based on the task" but that's roadmap, not shipped. They don't have a per-tool signal to drive it. Tool descriptions tell you what a tool does, not how hard the output is to reason about. "Diagnose field health" sounds simple until the response is multi-dimensional statistical analysis with evidence chains and confidence weights.

Without something like this, every client that wants per-task routing has to build their own heuristic over tool descriptions, and they'll all classify differently. A 3-number hint from the server (who actually knows what its tools return) gives clients a consistent, machine-readable signal. Doesn't replace client judgment, just informs it.

Happy to iterate on scope. Would also welcome this being reviewed as part of the Tool Annotations IG that @SamMorrowDrums is standing up.

A review with the Tool Annotations IG is a sensible next step, IMO.