CallToolResult deserialization rejects responses with structuredContent but no content field

[TrevorBurnham]

Summary

CallToolResult fails to deserialize when an MCP server returns only structuredContent without a content field, producing a "missing field content" error. While the MCP 2025-11-25 JSON Schema lists content as required, the spec prose uses SHOULD language ("a tool that returns structured content SHOULD also return the serialized JSON in a TextContent block"), which has led some MCP server implementations to omit content when returning structuredContent.

Regression

In v0.12.0, CallToolResult had a custom Deserialize implementation that accepted a missing content field (defaulting to []) and only errored if both content was empty and structuredContent was absent. This was replaced with a derived Deserialize in later versions, where content: Vec<Content> has no #[serde(default)], making it strictly required during deserialization.

Impact

This is a breaking change for any MCP client using rmcp that communicates with servers omitting content when returning structuredContent. The ambiguity between the spec's prose and its formal schema makes this a common real-world scenario.

Suggested fix

Add #[serde(default)] to the content field to restore lenient deserialization:

#[serde(default)]
pub content: Vec<Content>,

This follows Postel's law ("be liberal in what you accept") and restores the v0.12.0 behavior. Servers that omit content would still be non-compliant with the formal schema, but clients would handle them gracefully.