Recommended pattern for propagating User Context (State) via Agent2Agent Protocol (A2A) to downstream MCP tools?

[ganoderma-apaladum]

Context
I am building a distributed Hub-and-Spoke system using the ADK Python SDK.

• Architecture: A central "Hub" agent delegates tasks to stateless Remote Agents via the Agent2Agent Protocol (A2A).
• Downstream: The Remote Agents connect to MCP Servers (Model Context Protocol) to fetch data.
• Requirement: My MCP tools require user_email as a functional argument (e.g., get_employee_balance(email=...)) to retrieve the correct records.

My Current Implementation
I inject the user context at the session initialization layer (from my UI/Test scripts).

1. Entry Point (UI/Test Script): When I initialize the session or run the agent, I pass a state payload:

   # Inside def create_session() or def run_agent()
   payload = {
       "state": {
           "user_id": user_id,
           "user_email": user_email,
           "user_name": user_name
       }
   }

2. The Hub: Receives this state successfully.
3. The Gap: I need to propagate this state object from the Hub to the Remote Agent via the Agent2Agent Protocol.

Currently, I am manually injecting this state into the A2A message params via middleware so the Remote Agent can receive it and eventually pass the email to the MCP tool.

The Questions

1. A2A Native State: Does the Agent2Agent Protocol schema have a reserved field for this kind of state propagation? Is there a standard way to pass the "User Context" object alongside the conversation message without manually modifying the params dictionary?
2. Bridging to MCP: Once the Remote Agent receives this state via A2A, what is the recommended pattern to populate the downstream MCP tool arguments?
   • Should I rely on the LLM to extract the email from the context?
   • Or is it better to use middleware to programmatically inject the email into the MCP tool call (hiding it from the LLM)?
3. Future Proofing: While I am using user_email strings now, we plan to move to JWTs later. Does the ADK/A2A ecosystem have a preferred pattern for transporting auth tokens across these agent boundaries?

I want to ensure I am aligned with the "ADK-native" way of handling distributed state and identity.

[adk-bot]

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

TLDR:

1. A2A State Propagation: You are on the right track. The standard ADK pattern is to use the shared Session State (context.state) to propagate user context between agents. There is no separate, reserved field in the A2A protocol for this; the state itself is the intended mechanism.
2. Bridging to MCP Tools: The recommended pattern is programmatic injection, not LLM extraction. Your remote agent's tools should either access the ToolContext to read from the state directly or you should use a before_tool_callback to inject the user_email into the tool arguments before execution. This is more reliable and secure.
3. Authentication & JWTs: ADK has a built-in authentication framework designed for this. The recommended pattern is to use a "User Auth" flow (like OAuth2), where the remote agent can request authentication. The resulting token (e.g., a JWT) should be stored in the session state and accessed by tools via the ToolContext to make authenticated API calls.

---

Hello! Thank you for the detailed question. It touches on some core concepts of building distributed systems with ADK. Here’s a more detailed breakdown of the recommended patterns based on ADK documentation.

1. Propagating State via Agent2Agent (A2A)

Your current approach of using a state payload is very close to the idiomatic ADK solution. The Shared Session State is the primary and intended mechanism for sharing information across conversational turns and, crucially, between different agents in a multi-agent system. [1, 2]

When you delegate a task from a Hub to a Remote Agent, the session state is propagated. The Remote Agent can then access this state to inform its own operations or to pass context to its tools. Instead of manually modifying params, you should rely on the state being available in the context that the remote agent and its tools operate in.

2. Bridging State to MCP Tool Arguments

For reliability and security, it's best to avoid making the LLM responsible for passing sensitive or structured data like a user_email. The recommended ADK patterns involve programmatic injection:

• Pattern A: Direct Access in Tool
  You can define your tool to accept a ToolContext object, which ADK will automatically provide. From there, you can directly access the state.

  from adk.api.tools import ToolContext, tool
  
  @tool
  def get_employee_balance(tool_context: ToolContext):
      user_email = tool_context.state.get("user_email")
      if not user_email:
          # Handle missing email, maybe request it
          return "Error: User email not found in session."
      # ...proceed to fetch balance for user_email

• Pattern B: Middleware via before_tool_callback
  If you want to keep your tool logic clean and separate the state-injection concern, you can use a before_tool_callback. This function can intercept the LLM's generated tool call and modify the arguments before the tool is executed. [3]

  def inject_user_context(context, tool_call):
      if tool_call.name == "get_employee_balance":
          user_email = context.state.get("user_email")
          if "email" not in tool_call.args and user_email:
              tool_call.args["email"] = user_email
      return tool_call
  
  # In your agent config:
  agent = Agent(..., before_tool_callback=inject_user_context)

Both patterns are robust, but the callback approach is particularly powerful for applying context across multiple tools consistently.

3. Future-Proofing with Auth Tokens (JWTs)

ADK has a comprehensive authentication framework that is designed for distributed use cases just like yours. [4] Instead of manually passing tokens, you should leverage the built-in "User Auth" capabilities.

1. Initiate Auth from Remote Agent: A tool on your remote agent can declare that it requires authentication. If the necessary credential (e.g., an OAuth token) isn't in the ToolContext, ADK can surface an authentication request all the way back to the user-facing agent (your Hub or UI layer).
2. Cache Token in State: Once the user completes the authentication flow (e.g., OAuth2), the resulting token is automatically managed by ADK. It can be cached in the ToolContext and session state for reuse in subsequent tool calls. [4]
3. Use Token in Tools: The tool can then access the token from its ToolContext to make authenticated calls to downstream services (like your MCP servers).

This pattern is secure, aligns with industry standards like OAuth2, and is the recommended way to handle credentials like JWTs in the ADK ecosystem. A great resource to see this in action is the a2a_auth sample application. [5]

By adopting these patterns, you'll be well-aligned with the "ADK-native" way of handling distributed state and identity.

---

References:
[1] ADK Docs: Multi-agent Systems
[2] ADK Docs: Tutorial - Building a Team of Agents
[3] ADK Docs: Custom Tools
[4] ADK Docs: Tool Authentication
[5] ADK Sample: A2A Auth