shaun smith

> > TextContent type is notably missing a mime type property, so as near as I can tell there's no mechanism to actually communicate a mime type like application/json to...

This proposal has no dependency on #371 and predates it by 4 weeks.

> > This proposal has no dependency on #371 and predates it by 4 weeks. > > Ah gotcha - then I guess the direct feedback is this PR should...

> To put the request for documentation in context, here's the guidance offered by the [HTTP spec on content types](https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1) - it's multiple pages and includes recommendations on defaults, recommendations...

> Actually, this all brings up an interesting question - right now, mime types are primarily on resources (plus image content and audio content) - would a server ever change...

I've updated the comment in #371 to include an example `CallToolResult` and guidance text to make that clearer. Note this PR has been re-drafted and discussion moved to #356. >...

I understand. I might think about this the other way though - if the Client can match content consumption/generation (e.g. `image/*`) then it can inform the user about the risk...

There's loads of scenarios, and I think another idea going around about exposing direct model information to the MCP Server. I guess we need to figure out the right level...

I can't see the harm in Clients using the _meta field for that, the point is to advertise to the MCP Server what can be handled (not a guarantee that...

Tagging @kentcdodds and referring to https://github.com/modelcontextprotocol/modelcontextprotocol/pull/679