Support Grounding Metadata / Citation Propagation in in mcp_tool class

[davemorris-gcp]

** Please make sure you read the contribution guide and file the issues in the right place. **
Contribution guide.

Is your feature request related to a specific problem?

I don't know how to propagate grounding_metadata / sources from an MCP tool response into the LlmResponse class.

Describe the Solution You'd Like

It seems like the propagate_grounding_metadata feature of agent_tool would be a good way to achieve this in mcp_tool:

adk-python/src/google/adk/tools/agent_tool.py

Line 129 in 7e8965d

propagate_grounding_metadata: bool = False,

Impact on your work

When I register an ADK agent in Gemini Enterprise, that uses mcp_tool, the sources from the MCP server are stripped out when the LlmResponse is built and sent back to the GE UI.

Willingness to contribute

No

---

🟡 Recommended Information

Describe Alternatives You've Considered

Something like this: #1693 (comment)

Proposed API / Implementation

It seems like the propagate_grounding_metadata feature of agent_tool would be a good way to achieve this in mcp_tool:

adk-python/src/google/adk/tools/agent_tool.py

Line 129 in 7e8965d

propagate_grounding_metadata: bool = False,

Additional Context

N/A

[sanketpatil06]

Hi @davemorris-gcp , Thanks for the update. The request is currently being reviewed by our team, and we will let you know if anything further is needed. Thank you for your understanding.

[HarperZ9]

I took a quick look at the current code path, and this seems like it can reuse most of the existing AgentTool workaround rather than inventing a separate citation path.

Current shape, as I read it:

• AgentTool(..., propagate_grounding_metadata=True) stores the child agent metadata in tool_context.state['temp:_adk_grounding_metadata'].
• base_llm_flow._maybe_add_grounding_metadata() later copies that value onto LlmResponse.grounding_metadata.
• McpTool._run_async_impl() currently does response.model_dump(exclude_none=True, mode="json") and returns that dict, so source/grounding data can survive inside the tool result but does not become response-level grounding metadata for downstream UIs.

A minimal implementation option might be:

1. Add a propagate_grounding_metadata: bool = False option to McpTool / toolset construction, parallel to AgentTool.
2. After response = await ...call_tool(...), inspect the CallToolResult for an ADK-compatible grounding payload in a narrow, documented place, for example _meta['adk_grounding_metadata'] or a structured-content field.
3. If present and propagate_grounding_metadata is enabled, convert/validate it as types.GroundingMetadata and place it in tool_context.state['temp:_adk_grounding_metadata'].
4. Loosen the _maybe_add_grounding_metadata() gate so it is not hard-coded only to a canonical tool named google_search_agent; if the temp state exists, or if a canonical tool declares this capability, it can be attached to the LlmResponse.

The test I would want is a fake MCP CallToolResult with normal textual content plus source metadata, then assert both:

• the tool return value remains compatible with existing MCP result handling; and
• the final LlmResponse.grounding_metadata is populated, so Gemini Enterprise / UI consumers receive citations as response metadata instead of having to parse tool output text.

One small interoperability note from the Telos/Gather MCP provenance pattern: keep raw source payloads and response-level citation metadata separate. If an MCP server emits provenance that cannot be losslessly mapped to GroundingMetadata, preserving it as structured/custom metadata with source ids, spans, and digests is safer than dropping it or forcing it into citation text.

[claxman]

On this checkout _maybe_add_grounding_metadata returns early unless a tool is named google_search_agent: I ran _handle_after_model_callback with a dummy tool and temp:_adk_grounding_metadata={'foo': 'bar'} set, and the callback returned None so LlmResponse.grounding_metadata stayed unset. I will attach that temp value whenever it is present, and add propagate_grounding_metadata on McpTool so _meta.adk_grounding_metadata can populate the same key.

[claxman]

The flow still gates on a tool with propagate_grounding_metadata. That is the d689a04f check (getattr(tool, 'propagate_grounding_metadata', False)), not attach-whenever-the-temp-key-is-set. McpTool and McpToolset opt in with that flag.