Add _meta on all list result types.

[mbleigh]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

The _meta attribute is very useful because it provides the ability for clients and servers each to pass side-channel information to each other in a protocol-conforming way. However, the single _meta at the request level makes it difficult to model certain types of metadata especially in list RPC types.

Let's say that an application that integrates MCP wants to allow MCP servers to signal how certain tools should be integrated in its UI, e.g. by assigning a "priority". Ideally the server might be able to handle this in the ListToolsResult. Today that would be awkward:

{
  result: {
    tools: [
      {name: "my_tool", description: "...", inputSchema: {...}, annotations: {...}},
      {name: "another_tool", description: "...", inputSchema: {...}, annotations: {...}},
    ],
    _meta: {
      // I guess we have to do something like this?
      toolPriorities: [{name: "my_tool", priority: 10}, {name: "other_tool", priority: 20}],
    }
  },
}

Now the client and server both have to understand how to provide this extra sidechannel data and how to "zip it together" with the normal result data.

What would be better is if all listable interface types (Tool, Resource, ResourceTemplate, Root, and each of the *Content types) also allowed a _meta: {[key: string]: unknown} field. This would allow these to be annotated with metadata in a non-disruptive and intuitive manner:

{
  result: {
    tools: [
      {name: "my_tool", description: "...", inputSchema: {...}, annotations: {...}, _meta: {priority: 10}},
      {name: "another_tool", description: "...", inputSchema: {...}, annotations: {...}, _meta: {priority: 20}},
    ],
  },
}

It's a relatively simple change but would pay huge dividends in terms of making MCP more open for experimentation and extensibility while keeping the core protocol quite simple.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[dsp-ant]

Implemented