Skip to content

fix(mcp): reject config-supplied stdio MCP servers by default - #6547

Open
yusmer96-maker wants to merge 2 commits into
google:mainfrom
yusmer96-maker:fix/mcp-stdio-from-config
Open

fix(mcp): reject config-supplied stdio MCP servers by default#6547
yusmer96-maker wants to merge 2 commits into
google:mainfrom
yusmer96-maker:fix/mcp-stdio-from-config

Conversation

@yusmer96-maker

Copy link
Copy Markdown
Contributor

Link to Issue or Description of Change

2. Or, if no issue exists, describe the change:

Problem:

McpToolset.from_config() accepts stdio_server_params /
stdio_connection_params directly from an agent config. Those carry a command
and args that the MCP stdio transport launches as a local process, so loading
an agent config can start an arbitrary process on the first agent turn — before
the model is contacted.

Agent configs are not necessarily authored by the person running the agent: they
are shared as bundles, templates, samples and registry entries. That makes
config loading equivalent to code execution for anyone who runs an agent they
did not write.

ADK already treats this input as untrusted elsewhere: the args key is blocked
for Agent Builder uploads (fast_api.py) and for disk loads when the web UI is
enabled (config_agent_utils._set_enforce_yaml_key_denylist). It was simply not
enforced on the default adk run / adk api_server paths.

Solution:

from_config() now rejects stdio connection params unless the embedding
application explicitly opts in via _set_allow_config_stdio_servers(True).
Applications that legitimately launch local MCP servers from config keep working
by opting in; everything else fails closed.

Unaffected: remote transports (sse_connection_params,
streamable_http_connection_params), constructing McpToolset directly in
code, and applications that opt in.

Testing Plan

Unit Tests:

  • I have added or updated unit tests for my change.
  • All unit tests pass locally.

pytest tests/unittests/tools/mcp_tool/test_mcp_toolset.py -k from_config

  • test_from_config_with_credential_key (updated to opt in)
  • test_from_config_rejects_stdio_server_params
  • test_from_config_rejects_stdio_connection_params
  • test_from_config_allows_stdio_when_opted_in
  • test_from_config_allows_remote_connection_params

Manual End-to-End (E2E) Tests:

Two agent bundles, each a single root_agent.yaml, run with adk run.

1 — stdio MCP server declared in an agent config (now rejected):

tools:
  - name: McpToolset
    args:
      stdio_server_params:
        command: npx
        args: ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
      tool_filter: []

adk run now fails at config load with the new ValueError. Before this
change the same config launched the configured command on the first turn.

2 — remote MCP server in an agent config (unchanged):

tools:
  - name: McpToolset
    args:
      sse_connection_params:
        url: https://example.com/sse
      tool_filter: []

The toolset builds normally and the run proceeds to the model step, confirming
remote transports are not affected.

Additional context

Reported through the Google VRP (issue 541474207); this PR is the corresponding
fix. Related hardening on the same surface in the Go SDK: google/adk-go#923.

McpToolset.from_config() passed stdio_server_params.command and args straight
from the agent config to the MCP stdio transport, which launches them as a local
process. Agent configs are untrusted input, so this made a YAML config a
process-execution primitive.

Reject stdio connection params in from_config() unless the embedding application
opts in via _set_allow_config_stdio_servers(True). Remote transports (SSE,
streamable HTTP) are unaffected.
Add tests for from_config() rejecting stdio_server_params and
stdio_connection_params by default, allowing them under the
_set_allow_config_stdio_servers(True) opt-in, and leaving remote
transports (SSE) unaffected. Update the existing credential_key test
to opt in for its stdio config.
@adk-bot adk-bot added the mcp [Component] This issues is related to MCP support label Aug 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

mcp [Component] This issues is related to MCP support

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants