Repository navigation
ADK LlmAgent Does Not Persist MCPToolset Session Across Tool Calls, Causing Browser Context to Close After Each Action #2927
Description
Describe the bug
When using the ADK LlmAgent with the MCPToolset (Playwright MCP), the browser context/session is closed after every tool call, even when the same MCPToolset instance is reused and the agent is designed to support multi-step workflows. This results in the Playwright MCP server launching and closing a new browser for each action, breaking workflows that require session persistence (e.g., login followed by navigation).
To Reproduce
Steps to reproduce the behavior:
- start a new project for adk with default setup
- add the below snippet in agent.py
# ./adk_agent_samples/mcp_agent/agent.py
import os # Required for path operations
from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset
from google.adk.tools.mcp_tool.mcp_session_manager import StdioConnectionParams
from mcp import StdioServerParameters
root_agent = LlmAgent(
model="gemini-2.0-flash",
name="web_automation_assistant_agent",
instruction="""
You are an **Automation Agent** that uses the **Playwright MCP (Model Context Protocol)** to perform browser automation, UI testing, and workflow execution.
Your role is not to output Playwright code directly, but to **translate user requests into Playwright MCP tool calls** and orchestrate the automation process.
- Use natural language to confirm or explain actions.
- When executing, **call Playwright MCP tools directly**.
- For longer flows, summarize progress after each step.
""",
tools=[
MCPToolset(
connection_params=StdioConnectionParams(
server_params=StdioServerParameters(
command="npx",
args=[
"-y", # Argument for npx to auto-confirm install
"@playwright/mcp@latest",
],
),
),
# Optional: Filter which tools from the MCP server are exposed
# tool_filter=['list_directory', 'read_file']
)
],
)
- run "adk run <agent_file>"
- Run a multi-step workflow (e.g., navigate to a page, log in, then perform another action).
- Observe that the browser context is closed after each step, and session state is not preserved.
Expected Behavior
The LlmAgent should persist the MCPToolset (and its session) across multiple tool calls within the same agent instance.
The Playwright MCP server should keep the browser context/session alive for the duration of the agent's workflow, allowing multi-step automation in a single browser session.
Actual Behavior
Each tool call from the agent results in a new browser context/session.
The Playwright MCP server closes the browser after each tool call, losing all session state (cookies, navigation, etc.).
This occurs even when the same MCPToolset instance is passed to the agent and reused.
Desktop (please complete the following information):
- OS: MacOS
- Python version(python -V): Python 3.13.7
- ADK version(pip show google-adk): adk, version 1.12.0
Model Information:
gemini-2.5-flash
Additional Information
The same MCP server persists sessions for other clients (e.g., Claude Desktop), so this appears to be an ADK client issue.
Wrapping the MCPToolset in a persistent class does not resolve the issue.
Using both SSE and stdio connection modes produces the same result.
Activity
malto101 commentedon Sep 19, 2025
Hey,
just wanted to know if there was any update on this?
this is causing major problem on our side.
votek commentedon Sep 24, 2025
I'm having the same issue with my custom remote MCP server. The agent triggers DELETE /mcp requests after each MCP tool call, causing the remote MCP server to lose the state between subsequent tool calls for the same session.
BoyuanZhangDE commentedon Oct 19, 2025
I see the mcp session gets recreated when the session manager thinks the connection is lost:
adk-python/src/google/adk/tools/mcp_tool/mcp_session_manager.py
Lines 243 to 252 in a5b742b
Probably we can start improvement here - it depends on imported class
mcp.ClientSession's private attributes which have no guaranteed behavior.fastmcpalso uses this class frommcpon session management and probably we can adopt its way of session connectivity detection: https://github.com/jlowin/fastmcp/blob/39aebcf578b57290dfe13091439851ff082cb0d7/src/fastmcp/client/client.py#L319-L321@boyangsvl If no one has taken this issue, may I try to resolve this?
Jacksunwei commentedon Oct 24, 2025
Hi @BoyuanZhangDE , good catch on the private attribute issue. Your proposed fix is an improvement and I'd be happy to review a PR.
Before implementing, check if
mcp.ClientSessionhas a public method for connectivity checking—that'd be more stable than accessing internal state. Also, this might not address the root cause of why sessions appear disconnected between calls. Worth investigating that as well.If the mcp library doesn't expose a proper API for this, we should file an issue upstream.
Feel free to send a PR!
adk-bot commentedon Dec 3, 2025
This issue has been automatically marked as stale because it has not had recent activity for 7 days after a maintainer requested clarification. It will be closed if no further activity occurs within 7 days.
adk-bot commentedon Dec 12, 2025
This issue has been automatically marked as stale because it has not had recent activity for 7 days after a maintainer requested clarification. It will be closed if no further activity occurs within 7 days.
adk-bot commentedon Dec 19, 2025
This has been automatically closed because it has been marked as stale for over 7 days.