Adding MCP Tools to a LiveKit Voice Agent: Step-by-Step

Quick Answer

To add MCP tools to a LiveKit voice agent, run an MCP client inside the same LiveKit Agents SDK worker process that hosts your STT → LLM → TTS pipeline. At startup, the client connects to one or more MCP servers and discovers their available tools; those tool definitions are mapped to your LLM provider's function-calling schema so the model can invoke them mid-conversation. When the LLM emits a tool call, the MCP client executes it against the MCP server and returns a structured result, which is fed back into the conversation context so the agent can speak a natural response — the same tool-use loop as direct function calling, but using a standardized protocol instead of bespoke per-tool integration code.

What Is MCP?

The Model Context Protocol (MCP) is an open protocol for connecting LLM applications to external tools, APIs, and data sources through a standardized client-server interface. An MCP server exposes a set of tools (say, "look up a customer in the CRM" or "check calendar availability") along with their schemas; any MCP-compatible client can connect to that server, discover what tools it offers, and call them — without the client needing custom integration code written specifically for that CRM or calendar system. The practical benefit for a voice agent team is reuse: an MCP server built once for a text-based support chatbot can be pointed at by a LiveKit voice agent with no changes to the server itself, since the protocol — not the specific agent — defines how tools are discovered and called.

MCP vs. Direct Function Calling / Webhooks

For a single voice agent with two or three tools, direct function calling is often simpler to ship. MCP earns its setup cost once you're maintaining multiple agents (voice, chat, internal ops) that all need the same CRM/calendar/database tools.

Architecture

The MCP client lives inside the same LiveKit Agent worker process as the STT → LLM → TTS pipeline (see our LiveKit voice agent guide for the base pipeline architecture) — it is not a separate network hop for the caller, only for the tool call itself. When the LLM decides a tool is needed mid-turn, the agent code routes that call through the MCP client to the appropriate MCP server, waits for the structured result, and appends it to the conversation context before generating the spoken response — functionally identical to a direct API call, just routed through a standardized client instead of custom per-tool code.

Runnable Integration Code

Wiring an MCP client into a LiveKit Agents SDK worker, discovering tools at startup, and handling a tool call mid-conversation:

from livekit.agents import Agent, AgentSession, function_tool
from mcp_client import MCPClient  # any MCP-compatible client SDK

class SupportAgent(Agent):
    def __init__(self, mcp_client: MCPClient):
        super().__init__(instructions="You are a helpful phone support agent.")
        self.mcp = mcp_client

async def entrypoint(ctx):
    # 1. Connect to the MCP server and discover its tools at startup
    mcp = MCPClient(server_url="https://internal-crm-mcp.company.com")
    await mcp.connect()
    discovered_tools = await mcp.list_tools()
    # e.g. [{"name": "lookup_customer", "schema": {...}},
    #       {"name": "check_order_status", "schema": {...}}]

    # 2. Map each MCP tool to a LiveKit function_tool the LLM can call
    agent_tools = [
        function_tool(
            name=t["name"],
            description=t["schema"]["description"],
            parameters=t["schema"]["parameters"],
            # 3. Route the actual call through the MCP client
            handler=lambda args, tool_name=t["name"]: mcp.call_tool(tool_name, args),
        )
        for t in discovered_tools
    ]

    session = AgentSession(
        agent=SupportAgent(mcp),
        tools=agent_tools,   # LLM can now invoke any MCP-discovered tool mid-call
    )
    await session.start(ctx.room)

Multi-Tool Orchestration Example

Real support calls rarely need just one tool call — a caller asking "where's my order?" typically requires the LLM to chain several MCP tool calls within a single conversation turn: look up the customer, then their most recent order, then optionally create a follow-up ticket if something's wrong. The MCP client doesn't need special logic for this — the LLM decides the sequence, and each call is just another invocation through the same client:

# Conversation turn: "Where's my last order?"
# The LLM issues tool calls in sequence, informed by each prior result:

# 1. LLM calls lookup_customer(phone_number="+14155551234")
#    -> { "customer_id": "cus_9F21", "name": "Alex Rivera" }

# 2. LLM calls check_order_status(customer_id="cus_9F21", limit=1)
#    -> { "order_id": "ord_3382", "status": "delayed", "eta": "2026-07-18" }

# 3. If status == "delayed", LLM may call create_ticket(...)
#    -> { "ticket_id": "tkt_5510", "priority": "normal" }

# Each call goes through the SAME mcp.call_tool() path from the
# integration code above — the LLM decides the sequence and
# whether step 3 is needed at all, based on the result of step 2.

The engineering implication: each tool call in the chain adds its own latency and its own failure surface, so the timeout and fallback handling described below needs to apply per-call, not just once for the whole turn — a caller waiting through three sequential 2-second timeouts before a fallback triggers is a materially worse experience than one that fails fast on the first slow call.

Tool Discovery at Startup vs. Per-Call

Discover tools once when the LiveKit Agent worker starts, not on every inbound call — an MCP server's tool catalog changes rarely, and re-discovering it per call adds a network round-trip to your call setup latency for no benefit. Cache the discovered tool schemas in the worker process and refresh them on a slow interval (e.g. every few minutes) or on an explicit signal from the MCP server, rather than on every session start.

Security Considerations for MCP Servers

Connecting an LLM to live tools that can read or modify real data introduces a genuine attack surface, and the risks are different from a traditional REST API integration precisely because an LLM — not fixed application logic — decides when and how tools get called:

• Least-privilege tool scoping — expose only the specific tools a given agent actually needs (a support voice agent shouldn't have access to an admin-level 'delete customer' tool just because the same MCP server happens to expose it).
• Treat tool-returned data as untrusted input — a compromised or malicious upstream data source returned through a tool call can attempt prompt injection against the LLM; sanitize and bound what gets fed back into the conversation context.
• Per-agent authentication, not one shared MCP credential — if a single API key or token authenticates every agent connecting to an MCP server, a compromise or bug in one agent has blast radius across all of them.
• Audit logging on every tool call — who (which agent, which call) invoked what tool with what arguments, since this is the same data you'd need to investigate a security incident or a compliance question after the fact.
• Rate limiting per agent — an MCP server should cap how frequently any single agent can invoke a given tool, both to contain runaway loops and to limit the damage from a compromised agent.

Connecting to Multiple MCP Servers

A single LiveKit Agent worker can hold MCP client connections to several servers at once — a CRM MCP server and a separate calendar MCP server, for instance — which is common once an agent needs capabilities that live in genuinely different backend systems. The one thing that needs explicit handling is tool-name collisions: if two MCP servers both expose a tool called lookup_customer with different schemas, registering both directly with the LLM's function-calling interface will silently break or produce ambiguous behavior. Namespace discovered tool names by their source server (e.g. crm.lookup_customer vs. calendar.lookup_customer) before registering them, and check for collisions at startup rather than discovering the conflict mid-call.

Error Handling in a Live Call

A text-chat MCP integration can afford to show a generic error message and let the user retry. A live phone call can't — dead air while an MCP tool call hangs or errors reads as a dropped call to the person on the line. Handle at least these cases explicitly:

• Timeout on the MCP tool call — set an aggressive timeout (2-3s) and have the agent say a natural filler or fallback line rather than going silent
• MCP server unreachable — fail gracefully to a scripted 'let me transfer you to someone who can help with that' rather than crashing the session
• Malformed or unexpected tool result — validate the structured result before feeding it into the LLM context; an unvalidated malformed result can produce a confusing or incorrect spoken response
• Partial results mid-stream — for tools that support streaming responses, decide whether the agent narrates partial progress ('checking now...') or waits silently, and test which feels more natural for your specific call flow

Debugging & Observability

When a caller reports "the agent gave me the wrong order status," the only way to diagnose it after the fact is having a full trace of what actually happened during the call — not just the conversation transcript:

• Log every tool call with its arguments, the raw MCP server response, and the latency — correlated to the specific call/session ID, not just a global application log.
• Correlate tool-call traces with the call recording and transcript, so a support engineer can replay exactly what the LLM saw at each step, not just what it said out loud.
• Track per-tool latency percentiles (p50/p95/p99) separately from your STT/LLM/TTS pipeline metrics — a slow MCP server looks identical to a slow LLM from the caller's perspective, but the fix is completely different.
• Alert on elevated tool-call error rates per MCP server, not just on overall call failure rate, so a degrading upstream CRM or calendar integration surfaces before it shows up as a wave of bad caller experiences.
• Build a replay harness that can re-run a captured tool-call sequence offline against a test MCP server — invaluable for reproducing an intermittent bug without needing to place a live call.

Production Checklist

• Tool discovery cached at worker startup, refreshed on a slow interval — not re-fetched per call
• Aggressive timeouts (2-3s) on every MCP tool call, with a natural spoken fallback on timeout
• Structured result validation before feeding tool output back into LLM context
• Authentication/authorization for the MCP server scoped per-agent, not a single shared credential across every agent that connects to it
• Monitoring on MCP call latency and error rate separately from your STT/LLM/TTS pipeline metrics
• A tested fallback path (transfer to human, scripted apology) for total MCP server unavailability

FAQ

Related Reading