ResourceContents.uri made non-nullable in 1.27.0, breaking servers that return uri=null

[divssheth]

Initial Checks

• I confirm that I'm using the latest version of MCP Python SDK
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Description

In mcp==1.27.0, ResourceContents.uri was changed from optional to required:
Before (working):

uri: Annotated[AnyUrl, UrlConstraints(host_required=False)] | None = None
After (breaking):
uri: Annotated[AnyUrl, UrlConstraints(host_required=False)]

Impact:

Any MCP server that returns type=resource content items with uri=null (e.g. Azure AI Search knowledge agent) now causes a pydantic_core.ValidationError on every call_tool response. This happens inside send_request → result_type.model_validate(...) before the result even reaches the caller, making every tool call fail silently.
Observed symptom in agent-framework: "Maximum consecutive function call errors reached (3). Stopping further function calls for this request."

Reproduction:

from mcp.types import ResourceContents
# This should be valid per the MCP spec — uri is not always present
ResourceContents(mimeType="text/plain")  # raises ValidationError in 1.27.0

Expected behaviour:

uri should remain optional (| None = None) to maintain compatibility with servers that omit it, as it was in prior releases.

Workaround:
Pin to the wheel of mcp==1.27.0 that still has uri as optional (the regression was introduced in a re-publish of the same version string), or patch types.py locally.

Example Code

Python & MCP Python SDK

Environment:
- mcp==1.27.0
- Python 3.14

[Genmin]

I looked at this before opening a patch, and I think the current Python model is matching the published protocol schema rather than regressing away from it.

The current schema reference marks both resource-content variants with a required uri: string:

• TextResourceContents: https://modelcontextprotocol.io/specification/draft/schema#textresourcecontents
• BlobResourceContents: https://modelcontextprotocol.io/specification/draft/schema#blobresourcecontents

So changing ResourceContents.uri back to optional/nullable in the base SDK type would make the SDK accept responses that the protocol schema rejects. For the Azure AI Search case, the safer compatibility shim is probably for the server/adapter to emit a stable synthetic URI for each returned resource content item, even if the backing source does not have a native URI.

If maintainers want a tolerant/non-strict parsing mode for interoperability with non-conforming servers, I can help with that shape, but I would not recommend making the core protocol type nullable without a corresponding schema change.

[maxisbey]

Thanks for the report, and @Genmin's analysis is correct — closing as not-a-bug.

ResourceContents.uri has been a required field in every release of this SDK since v1.0.0. It did not change in 1.27.0 — src/mcp/types.py is byte-identical between v1.26.0 and v1.27.0, and PyPI shows a single upload for 1.27.0 (PyPI doesn't permit re-publishing a version). The repro ResourceContents(mimeType="text/plain") raises ValidationError on every version of mcp ever published.

This matches the protocol schema, where uri has been required on ResourceContents / TextResourceContents / BlobResourceContents since the first spec revision (2024-11-05) through the current one. The TypeScript and Rust SDKs also reject a missing uri; the C# and Go SDKs happen to tolerate it only as a side effect of their serializers' defaults (coercing to "", which still isn't a valid URI).

A server returning EmbeddedResource content with uri: null is non-conformant. The fix belongs there — emitting a stable synthetic URI per result (e.g. urn:azure-search:<index>/<doc-id>) would make it valid against the spec and work with every SDK. If you'd like the protocol itself to allow an absent uri, that would need a schema change via the SEP process.

If a tolerant / non-strict client parsing mode would be useful for interop with non-conforming servers, happy to discuss that as a separate feature request.

_{AI Disclaimer}