@hesreallyhim Ah, actually this is a small patch before we potentially rock the boat and unify types: #180 (reply in thread)

@hesreallyhim Ah, actually this is a small patch before we potentially rock the boat and unify types: #180 (reply in thread)

ok, thanks for the context 👍

I'd prefer this was fixed to text/plain if it is going to be added.

@evalstate can you elaborate? What does "fixing" mean in this context? Assume all type: "text" additionally means mimeType: "text/plain", without a way to override it?

Yes, my view is that TextContent should have the guarantee that it is text/plain.

TextContent is by far the most widely used type, and we already have TextResourceContents for transmitting semantic information about textual content.

The potential breakage here is that Server developers think they want to send text/html or text/css or application/x-python, but in truth they are not natively tokenized by the models. Sending those as content blocks with their mime type via the LLM API will usually cause an error, and this is often not what the MCP Server developer intended.

There are rare exceptions (e.g. models like StarVector) but the general case is that having a modifiable mime type on TextContent this will cause unnecessary complexity and breakages.

At the moment TextContent is almost guaranteed to work in all situations, is simple for MCP Server and Host developers and TextResourceContents exists for more complex integrations. Adding a specifiable mime type would regress this.

LGTM. @atesgoral - mind resolving the schema conflicts in this PR?

@localden My GH notification settings suck. I missed your ping. Looking now.

Update: Thank you for updating it!

@evalstate @olaservo @jonathanhefner @cliffhall any concerns with this merging as-is?

any concerns with this merging as-is?

Back when this was proposed I was in favor of it. In particular, I was in favor of having just TextContent and BlobContent as a replacement for ImageContent, AudioContent, and EmbeddedResource (which also has its own TextResourceContents and BlobResourceContents). That seemed cleaner to me, from an API perspective.

But since then, I've flipped to favoring TextContent with no MIME type (same as current) and EmbeddedResource for anything else (if anything else). That combo currently feels more "model native" to me.