Describe the bug

Resources returned by resources/list (RawResource / Resource) lack an extensible _meta field. This forces servers to embed provenance data (e.g., location=global/project/universal) into less suitable fields like description or URIs. Ultimately this creates inconsistency, as readResource allows _meta on ResourceContents, preventing clients that only list resources from accessing structured metadata.

To Reproduce

1. Implement an MCP server that wants to tag each resource with location.
2. Return resources via listResources.
3. Observe there is no field to attach structured metadata; only description or name can be overloaded.

Expected behavior

listResources should allow an optional structured metadata map (e.g., _meta / meta: Meta) on each resource, matching how ResourceContents supports _meta. Clients should receive structured fields like {"location":"global"} without string scraping.

Logs

Not a runtime error; this is a protocol/schema limitation observed during server implementation.

Additional context

• Adding optional _meta preserves backward compatibility (omit when empty).
• Aligns with other SDKs that allow resource metadata.
• Alternatives (description/URI query) are brittle, change resource identity, and require heuristic parsing.

Related issues

• Missing _meta Field Support in rmcp Tool Registration #505 mentions adding _meta to Tool registration, but does not cover the need for resource-level _meta in listResources.
• Request Metadata Context #61 describes allowing servers to attach arbitrary metadata to requests such that handlers are able to access client-related details (such as transport type or bearer token). It doesn't provide the ability to add _meta to listResources or resources. The scope with this issue is limited to request context rather than including resource metadata.