Propagate McpMeta to Result types in resource read, tool call, and prompt get operations

[Copilot]

[McpMeta] attribute metadata was returned in resources/list, tools/list, and prompts/list responses but missing from resources/read, tools/call, and prompts/get results.

Changes

• AIFunctionMcpServerResource.ReadAsync: Propagate ProtocolResourceTemplate.Meta to ReadResourceResult.Meta
• AIFunctionMcpServerTool.InvokeAsync: Propagate ProtocolTool.Meta to CallToolResult.Meta
• AIFunctionMcpServerPrompt.GetAsync: Propagate ProtocolPrompt.Meta to GetPromptResult.Meta

Uses ??= to preserve user-provided metadata when returning result objects directly:

// User-provided meta on returned result is preserved
readResourceResult.Meta ??= ProtocolResourceTemplate.Meta;

Tests

Added 9 tests covering:

• Meta propagation for all three primitive types
• User-provided meta preservation (not overwritten)
• No meta when none defined on method

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• modelcontextprotocol.io
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (dns block)
• spec.modelcontextprotocol.io
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Resources/read does not return content, specified by [McpMeta] attribute, resources/list does</issue_title>
<issue_description>Describe the bug
Resources/read does not return content, specified by [McpMeta] attribute, resources/list does

To Reproduce
Steps to reproduce the behavior:

1. Attach attribute [McpMeta("ui", JsonValue = """{ "csp": { "resourceDomains": ["https://cdn.jsdelivr.net"] } }""")] to method, marked with [McpServerResource]
2. Using MCP Inspector: resources/list returns _meta attribute value above
3. Using MCP Inspector: resources/read does not

Expected behavior
resources/read returns content of [McpMeta] attribute along with uri, mimeType and text

Additional context
Bug in src\ModelContextProtocol.Core\Server\AIFunctionMcpServerResource.cs method ReadAsync results do not initialize Meta property of returned results
</issue_description>

<agent_instructions>For all of the operations that [McpMeta] can be applied to, ensure that when we're constructing the Result-derived instances, we appropriately populate those Result's Meta with the content of McpMeta, just as we do for when listing the primitives. Update existing tests and/or add new tests to existing files to validate that such metadata is propagated everywhere it should be. Also, check to see what the TypeScript and Python SDKs do in a similar situation, if they have an equivalent mechanism for tagging primitives with metadata... if they have such a mechanism, validate that it's applying both to listing and to invoking/getting/reading... if it's not, we'll want to revisit changing anything here.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Resources/read does not return content, specified by [McpMeta] attribute, resources/list does #1228

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[stephentoub]

@copilot what did you discover about other SDKs?

[Copilot]

@copilot what did you discover about other SDKs?

I investigated the TypeScript and Python SDKs:

TypeScript SDK: Has an equivalent _meta field on tools/resources/prompts. When listing primitives, _meta is included in the response (e.g., tool._meta). However, when calling tools or reading resources, the result is returned directly from the handler without propagating _meta to the result type.

Python SDK: Similarly has a meta field on primitives. For listing, it's included (e.g., _meta=info.meta). For resources, the SDK does propagate meta to ReadResourceResult (line 357 in server.py: meta=resource.meta). However, for tools, call_tool returns the handler result directly without propagating meta.

Summary: Neither SDK consistently propagates metadata to all result types. The Python SDK does it for resources but not tools. The TypeScript SDK doesn't do it for any result type. Given this inconsistency in the other SDKs and the user's specific request for this functionality, the implementation in this PR is a reasonable enhancement that enables the use case described in the issue.

[stephentoub]

@copilot, can you look at the other official SDKs as well and see what they do in this area? Ruby, Rust, Swift, Kotlin, PHP, Go, etc.?

[Copilot]

@copilot, can you look at the other official SDKs as well and see what they do in this area? Ruby, Rust, Swift, Kotlin, PHP, Go, etc.?

I investigated all official MCP SDKs. Here's a summary table:

SDK	Has Meta on Primitives	Meta in List Results	Meta Propagated to Call/Read/Get Results
TypeScript	Yes (_meta)	Yes	No - handler result returned directly
Python	Yes (meta)	Yes	Partial - resources only (meta=resource.meta), not tools/prompts
Java	Yes (meta())	Yes	No - CallToolResult built from handler, no meta propagation
Kotlin	Yes (meta)	Yes	No - CallToolResult returned directly from handler
Go	Yes (in types)	Yes	No - CallToolResult returned directly from handler
Rust	Yes (Meta)	Yes	No - result returned from handler without meta injection
Swift	No _meta field on Tool	N/A	No - CallTool.Result has no _meta field
Ruby	Yes (meta:)	Yes	No - tool.call().to_h returns handler result directly
PHP	Yes ($meta)	Yes	No - CallToolResult accepts meta in constructor but not auto-propagated

Summary: None of the official SDKs consistently propagate primitive metadata to invocation results. The Python SDK is the closest, propagating meta for resources but not for tools or prompts. All other SDKs return handler results directly without any automatic metadata propagation.

[stephentoub]

Marking NO MERGE until we decide whether we want this behavior or not, given #1230 (comment) (I've not manually validated this report)

@localden, any opinion?

[mikekistler]

@copilot Please look again at the TypeScript SDK and answer this question: Can a server set values in the _meta of a CallToolResult that the client can then access?

Please also look at the Python SDK and answer the same question.

[stephentoub]

@mikekistler it's possible to do that from the c# sdk today. To make sure it's clear, the question here is specifically whether McpMeta attributes should contribute to results.

[Copilot]

@copilot Please look again at the TypeScript SDK and answer this question: Can a server set values in the _meta of a CallToolResult that the client can then access?

Please also look at the Python S...

Yes, in both SDKs a server can set _meta in a CallToolResult that the client can then access.

TypeScript SDK:

• CallToolResult extends Result and Result has _meta?: { [key: string]: unknown }
• ToolCallback type signature returns CallToolResult directly, so tools can return { content: [...], _meta: { ... } }
• The client receives the full CallToolResult object via client.callTool() and can access result._meta

Python SDK:

• CallToolResult(Result) inherits meta: Meta | None = Field(alias="_meta", default=None) from Result
• In the low-level server, if a tool handler returns a CallToolResult directly, it's returned as-is (line 560 in lowlevel/server.py: if isinstance(results, types.CallToolResult): return results)
• The client receives the full CallToolResult from session.call_tool() and can access result.meta

So both SDKs support server-set metadata on result types - the question in this PR is whether the SDK should automatically propagate metadata from the primitive definition ([McpMeta] attribute) to the result, not whether metadata can be manually set.

[mikekistler]

@stephentoub I agree with your statement

the question here is specifically whether McpMeta attributes should contribute to results.

So I'm a little confused by the comparisions to other SDKs. "Attributes" are a C# concept. Do we think that other languages have concepts similar to attributes and we want to be consistent with those?

I would think that it is more important for the behavior of attributes in the C# SDK to be consistent with the way attributes typically work in C# and with how the specific attributes are documented.

The McpMetaAttribute documentation says

Specifies metadata for an MCP server primitive (tool, prompt, or resource).

So it seems reasonable (to me) to expect that McpMeta would have effect on resource read, tool call, and prompt get results.

[mikekistler]

Also, my purpose in asking Copilot about the TypeScript and Python SDKs was to decipher this statement:

Summary: Neither SDK consistently propagates metadata to all result types.

I don't know what Copilot thinks it means to "propogate metadata" but I think all of TypeScript, Python, and C# will allow _meta to be set in response to any request and the client can successfully access these _meta fields.

[stephentoub]

Do we think that other languages have concepts similar to attributes and we want to be consistent with those?

Attributes are just a mechanism for declaratively specifying information. Decorators in typescript and python are similar.

The question isn't about exactly attributes, but about each sdk's more declarative mechanisms, rather than the imperative mechanism of just writing a handler and being in full control.

For example, in python, I could author a resource like:

@mcp.resource(
    uri="data://app-status", 
    name="ApplicationStatus", 
    description="Provides the current status of the application.", 
    mime_type="application/json",
    tags={"monitoring", "status"},
    meta={"version": "2.1", "team": "infrastructure"}
)
def get_application_status() -> str:
   .... 

And my question is should that metadata I exposed declarativwly on the resource propagate to the results returned when reading the resource.

I would think that it is more important for the behavior of attributes in the C# SDK to be consistent with the way attributes typically work in C# and with how the specific attributes are documented.

I don't believe any answer here is more or less consistent with attributes in general.