Using Frontend MCP tools with Orchestrator-style ADK agents

[suraj0312]

When building an orchestrator-style ADK agent (an agent that delegates work to other ADK agents), there is currently no clear or supported way to use Frontend tools (exposed via useFrontendTool in CopilotKit) within that orchestration flow.

This makes it difficult to combine:

• Orchestrator agents (routing / delegation)
• ADK agents
• Frontend-only tools

in a single, clean architecture.

---

Background

From the documentation and examples, there are two common patterns:

1. ADK agents with tools

   • Tools are attached on the backend (e.g., MCPToolset)
   • Works well with orchestrators

2. Frontend tools

   • Tools registered via useFrontendTool
   • Used by CopilotKit at runtime
   • Backend ADK agents connected to Orchestrator ADK agent are not aware of these tools

Both patterns work individually, but they don’t compose well together.

---

Current Behavior

• An individual ADK agent can use Frontend tools when they are registered via useFrontendTool.
• However, when using an orchestrator-style ADK agent that delegates to other ADK agents:
  • The orchestrator can call child agents
  • But those child agents cannot access Frontend tools
  • Because Frontend tools only exist in the CopilotKit runtime, not in the ADK agent graph

As a result:

Orchestrator → ADK agent → Frontend tools

is not possible.

---

Expected / Desired Behavior

It would be helpful to have a supported way to achieve one of the following:

Option A – Delegation-Friendly Frontend Tools

Provide a mechanism where:

• An orchestrator delegates to another ADK agent
• That agent can still invoke Frontend tools
• Even though the tools are registered in the frontend runtime

Option B – Clear Guidance / Recommended Pattern

If this is intentionally unsupported, clear documentation explaining:

• Why frontend tools cannot be used with agents in orchestrators
• What the recommended alternative architecture is

---

Why This Matters

Frontend MCP tools are useful or required when:

• MCP servers are browser-only
• Authentication or context must live in the browser
• Tools are tightly coupled to UI/runtime state

At the same time, orchestrator agents are a core pattern for:

• Routing requests
• Multi-agent reasoning
• Structured task delegation

Right now, developers must choose one or the other.

---

Minimal Conceptual Example

• Orchestrator ADK agent
  • Delegates tasks to other ADK agents
• Those ADK agents rely on MCP tools
• MCP tools are frontend-only (registered via useFrontendTool)

Result:

• Direct usage works
• Orchestrated usage does not

---

Example Scenario

Consider the following setup:

• An orchestrator-style ADK agent
  • Responsible only for routing and delegation
• Multiple ADK agents
  • Each agent has its own instructions and behavior
• A single MCP server
  • Exposed as a Frontend MCP
  • Tools are registered using useFrontendTool in CopilotKit
  • Tools are only available at runtime in the frontend

Conceptually:

User
  ↓
Orchestrator ADK Agent
  ↓
ADK Agent A / ADK Agent B
  ↓
Frontend MCP Tools (via CopilotKit)

What works

• When an individual ADK agent is used directly:
  • Frontend MCP tools are registered via useFrontendTool
  • The model can successfully call MCP tools

What does not work

• When the orchestrator ADK agent is used:
  • The orchestrator delegates to another ADK agent
  • That ADK agent cannot access Frontend MCP tools
  • Because the tools only exist in the CopilotKit runtime and are not visible to the orchestrator flow

As a result:
The same ADK agent behaves differently depending on whether it is called directly or via an orchestrator.

---

Closing

This is not necessarily a bug, but a missing integration point that becomes apparent when building real-world, multi-agent applications that mix ADK orchestration with frontend MCP tooling.

Any guidance or recommended patterns would be greatly appreciated.

Thanks!