load_mcp_resource_tool not working with bidi streaming in adk web

[Robbilie]

ive been experimenting with adk web and mcp servers (https://github.com/modelcontextprotocol/python-sdk/blob/main/examples/servers/everything-server/README.md)

using adk with a text based model (gemini-2.5-flash) which in turn uses the run_sse endpoint of adk web the tool works as intended (i assume :D), at least i can get the model to access the static text resource.

when i run adk web with bidi streaming the tool does not work properly. i see a function response with the resource name but there it gets stuck. the tool has to be called twice to load the file into context and for the sse based approach the process_llm_request method is called multiple times, for the bidi streaming approach it is not and thus the context is not enriched with the content.

https://github.com/google/adk-python/blob/main/src/google/adk/tools/load_mcp_resource_tool.py#L96

any ideas why that would happen? probably affects other tools aswell, not sure if this is a adk web / adk api server issue or a bidi one.

cc @wukath thanks for your work, maybe you got some insights?

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: This is excellent analysis, and you're likely correct that the issue is specific to the bidirectional streaming implementation. The problem seems to be that after the tool executes, its output is not being correctly passed back to the model to complete the reasoning loop, which differs from the behavior in SSE mode. A secondary point to verify is that you are using a model version explicitly compatible with the Live API.

---

Hi @Robbilie, thank you for the very detailed and helpful report!

Your observation that process_llm_request is called multiple times in the SSE-based approach but not in the bidi streaming approach is the key to understanding the problem. This strongly suggests a difference in how the tool execution loop is orchestrated between the two modes.

1. Different Streaming Architectures: As you suspected, the issue likely stems from the different underlying technologies. StreamingMode.SSE uses a standard HTTP streaming endpoint, while StreamingMode.BIDI relies on WebSockets and the Gemini Live API, which have a more complex, asynchronous event model. [5, 7, 9]

2. Incomplete Tool-Use Loop in run_live: In a typical tool-use scenario, the flow is:
   a. The model requests a tool call.
   b. The ADK runner executes the tool.
   c. The runner sends the tool's output back to the model as context.
   d. The model uses this new context to generate its final response.

   Your description implies that step (c) is failing in bidi mode. The tool runs, but its results are not being returned to the conversation, so the model never sees the content of the MCP resource and gets "stuck."

3. Model Compatibility: A potential contributing factor could be the model itself. Bidirectional streaming requires a model that is explicitly compatible with the Gemini Live API. [11] For instance, test logs have shown success with models named like gemini-2.5-flash-native-audio-preview-09-2025. [2] It would be worth double-checking if the gemini-2.5-flash you're using is designated for Live API usage, as using a non-compatible version can lead to unexpected behavior.

This behavior is certainly not intended, and your detailed breakdown provides a strong basis for investigating it as a potential bug in the run_live orchestration logic. Thank you for bringing this to our attention.

[1] publicly accessible HTTPS URL of the document
[2] publicly accessible HTTPS URL of the document
[3] publicly accessible HTTPS URL of the document
[4] publicly accessible HTTPS URL of the document
[5] publicly accessible HTTPS URL of the document

[Robbilie]

i believe the way tools work right now is not really compatible with how the live endpoint works.
function responses only work due to this little piece of code:
https://github.com/google/adk-python/blob/main/src/google/adk/flows/llm_flows/base_llm_flow.py#L206-L212
the way the load_mcp_resource_tool (and the load_artifacts_tool) work would require a mechanism that would hook incoming and outgoing events and emit messages to the model (not all of that is necessary for this specific usecase). maybe processors or plugins can help here but i think there needs to be some changes, since most of that stuff probably also doesnt properly work for live sessions.

[Robbilie]

at this point it might be more helpful to be able to load mcp resources as artifacts if ones goal is to make images etc. available to the user (which is my usecase)

[Robbilie]

i wrote a small tool resembling the functionality but instead of adding it to the LlmRequest adding the resources as artifacts. i might add text and smaller artifacts to the tool response as it seems to be the only way to make it available to the context. i will also try using sub agents as the transfer to agent logic seems to work for bidi according to the code so this might allow pre processing again.

[Robbilie]

since the tool calls were working for a non streaming agent i thought i could do sub agents. i setup a parent, streaming agent and a non streaming child agent and wrapped that as an agent tool. this did not yield any better results as the streaming approach in the first place, even though agent tools always use the non streaming approach. when i switch to a non streaming parent agent the model explains the issue:

It seems I misunderstood. I cannot directly access the content of the static_text_resource. My attempt to get the content resulted in the following response: "Thanks for providing the content of static_text_resource!". It appears the agent interpreted my request as if I was providing the content, not asking for it.

i think the whole "attach the content of a resource as a part of an event looking like user input" approach is rather confusing and rather error prone…

[Robbilie]

apparently with more instructions the agent can somewhat deal with text resource:

you are an agent to interface with mcp tools. if asked to retrieve a mcp resource, use the load_mcp_resource tool twice. this will cause the user to tell you the content of the resource. if the user tells you the content, simply echo the exact same message the user provided you with
for some reason the audio output of the streaming model becomes garbled…