Does livekit provide support over agent to agent protocol? Would be cool if my livekit agent could call another agent deployed elsewhere and use it as if it was a tool

Thanks for reaching out, Roman. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

At the moment I'm struggling with having too many mcp servers connected to my livekit agent. Doing the handshake with all the mcps takes way too many tokens. It doesn't scale at all. I tried different approached. I built a tool to dynamically do handshakes with mcps. The tool receives an argument and that's the mcp the tool should connect to. The thing is: when the loop starts the agent sees a snapshot of all the available tools. If during the loop the available tools are updated thanks to a new mcp handshake the agent won't see the changes in the available tools. So it won't be able to do tool chaining with the new tools. That makes the agent behaviour quite rusty. I was thinking that outsourcing funcionalities to other agents deployed elsewhere would be a good idea. Not sure yet...

Thanks — this is a clear description of the pain point, and I hear your frustration with token cost and stale tool lists during runtime. I can help you explore scalable patterns and a few concrete options based on what you described. First, a couple quick clarifying questions so I can give practical guidance: 1. How are you currently supplying the agent with its tool list? (e.g., included in the initial system prompt, fetched from an API at start-up, or injected via some runtime call?) 2. Does your agent platform allow invoking a separate runtime hook or function during the loop to fetch updated tool metadata (not the full handshake) without re‑sending large credential blobs? 3. Are the MCP handshakes required to fully populate the agent tool definitions, or could you separate “discovery/metadata” from full authentication so the agent only pulls metadata initially? Based on your description, here are patterns you can try that address token usage and dynamic tool availability: • Separate discovery from handshake (recommended) ◦ Keep a lightweight registry of available MCPs (ID, capabilities, endpoint, minimal metadata). The agent fetches only this registry during the loop so it sees newly available tools without redoing heavy handshakes. ◦ Perform the expensive handshake only when the agent actually calls that MCP (lazy handshake). This moves the token cost from an upfront N× handshake to on-demand per-call. • Use a small proxy/orchestrator agent or service ◦ Deploy a lightweight orchestrator that maintains persistent MCP connections and exposes a small tool interface to your main agent. The main agent treats the orchestrator as a single tool; the orchestrator handles which MCP to use behind the scenes. ◦ Advantages: reduces token cost for the main agent, centralizes connection management, and enables fast switching between MCPs without changing the main agent’s tool list. • Runtime tool list refresh (partial update) ◦ If your agent sees a snapshot of tools at loop start, inject a tiny “refresh_tools” function_tool that, when invoked, retrieves updated tool metadata from your registry/orchestrator. This keeps tool definitions small and allows chaining that includes newly discovered tools. ◦ Make sure the tool metadata returned to the agent is compact (capabilities and call signatures), not full handshake tokens. • Use

function_tool

chaining instead of baking remote MCPs into the toolset ◦ Model MCP actions as function calls the agent can make via a single, stable

function_tool

that delegates to specific MCPs based on arguments. This keeps the agent’s visible toolset small and stable while giving it the ability to route to many MCPs at runtime. • Stateless agent + shared

UserData

for state transfer ◦ Keep the agent stateless and store connection state / session references in

UserData

or in the orchestrator service. That avoids re-sending large state every loop and helps scale horizontally. Tradeoffs to consider • Lazy handshake: reduces upfront tokens but introduces latency on first call to an MCP. • Orchestrator/proxy: adds an extra hop and operational component but centralizes complexity and significantly reduces token usage for the agent. • Full decentralization (each agent handles their own handshakes): simpler architecture, but high token cost and scaling issues you’re already experiencing. If outsourcing to other agents • Outsourcing can work well if you combine it with a lightweight discovery/orchestrator pattern. Instead of each agent performing heavy handshakes, have a stable interface (or tool) that represents the remote agent’s capabilities; the real handshake/connection can be performed by the remote agent or an orchestrator when invoked. • Keep tool descriptions minimal and use

function_tool

for structured calls between agents. Next steps I can help with • Draft a specific architecture: orchestrator + main agent + lazy handshake flow. • Give a compact example of a

function_tool

signature and the minimal metadata shape your agent should see so updates are cheap. • Show how to implement a “refresh_tools” tool that returns new capabilities without heavy tokens. Which of those would help most right now — a concrete orchestrator pattern, a

function_tool

example, or a sample metadata schema and refresh flow? , with interactive elements