Agent Deployment + Connecting to Local MCPs

[enxilium]

Hi, I'm a little confused about the agent deployment process, when deploying to Agent Engine or Cloud Run (or similar).

1. Is the agent able to access the filesystem MCP properly still? (i.e. access the user's local files)
2. If the agent tries to connect to a STDIO or HTTP MCP server that requires auth, does it redirect the OAuth flow to the user client properly?

If so, what's the underlying technology supporting this?

[adk-bot]

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

TLDR: A deployed agent on Cloud Run runs in a container and can't directly access your local files. However, it can connect to a local MCP server on your machine to access the filesystem. The ADK framework does support OAuth and OIDC, and will redirect the auth flow to the user when a tool requires it.

---

Hello! Here is some information regarding your questions about agent deployment.

Accessing the Local Filesystem

When you deploy an agent to a remote environment like Cloud Run, it operates within a containerized environment. This means the agent has its own isolated filesystem and cannot directly access the local files on the user's machine.

However, the Agent Development Kit (ADK) provides a solution for this through the Model Context Protocol (MCP). You can run an MCP server on the user's local machine, and the remotely deployed agent can connect to this local MCP server. This connection allows the agent to access the user's local files indirectly.

For remote connections to an MCP server, you would typically use SseConnectionParams. This is different from local development where you might use StdioConnectionParams for a direct connection to a local MCP server. You can configure your agent to switch between these connection parameters based on the environment it's running in. [1]

Authentication and OAuth Flow

The ADK framework is designed to handle authentication for tools that require it, including OAuth 2.0 and OpenID Connect (OIDC). When a tool needs authentication, the ADK framework will pause its execution and signal the agent client application to initiate the authentication flow.

Here is a general overview of the process:

1. Configuration: You configure your tool with an AuthScheme (like OpenIdConnectWithConfig) and provide the necessary credentials, such as a client ID and secret, in an AuthCredential object. [2, 3]
2. Redirection: The ADK framework generates an authorization URL. The agent client application then redirects the user to this URL to log in and grant the necessary permissions. [4]
3. Token Exchange: After the user authenticates, the framework handles the process of exchanging the authorization code for an access token.
4. Authenticated Calls: The obtained token is then automatically used for all subsequent calls made by the tool.

This process ensures that the authentication flow is properly handled, even when the agent is deployed remotely.

I hope this helps clarify the deployment process!

---

[1] https://google.github.io/adk-docs/tools/mcp-tools/
[2] https://google.github.io/adk-docs/tools/authentication/
[3] https://github.com/google/adk-docs/blob/main/examples/python/snippets/tools/auth/tools_and_agent.py
[4] https://github.com/google/adk-docs/blob/main/examples/python/snippets/tools/auth/agent_cli.py

[seanzhou1023]

I think the bot's answer is confusing. Agent engine is also deployed to cloud run, that means your codes runs in a container, I think you should be able to access the container's filesystem (at least /tmp) , you can try to use the stdio MCP server to access the filesystem as you mentioned. as for oauth flow, adk did surface some special event to the client if you are using ADK web as your agent client, you get it for free. (ADK web will be available if you run 'adk deploy cloud_run --with_ui', but won't be available for agent engine). To handle the special event yourself in your own client, please reference : https://google.github.io/adk-docs/tools/authentication/#2-handling-the-interactive-oauthoidc-flow-client-side