MCP (Model Context Protocol)
The Model Context Protocol is an open spec that lets servers expose tools, resources, and prompts to any compatible client. Patter speaks MCP as a client: point your agent at one or more MCP server URLs and the SDK queries each server’stools/list at call start, wraps the discovered tools with synthetic handlers that dispatch back through tools/call, and merges them into agent.tools before the model sees the function-tool list.
The result: any MCP-exposed capability — Google Workspace, PayPal, GitHub, Postgres, internal services — becomes a tool your phone agent can call, with zero wrapper code.
When to use this
| Scenario | Use this |
|---|---|
| You already run an MCP server (or the vendor does) and want the phone agent to use it. | mcp_servers=[...] |
| You want to expose a single bespoke action to the agent and you control the implementation. | A regular tool(...) with a handler or webhook_url (see Tools). |
| You need both. | Mix freely — MCP tools and user-defined tools coexist; a name collision raises at startup. |
Installation
MCP support is an optional dependency. If you do not configuremcp_servers, you never pay the install cost.
mcp Python SDK. Configuring mcp_servers without the extra installed raises a clear error at call start.
Quickstart — URL string (shorthand)
The simplest form: pass a list of URL strings. Each is treated as{"url": <str>, "transport": "streamable-http"} with no auth headers.
Full options form — auth headers + telemetry name
When you need authentication or want a friendly name in logs, use the dict form. Headers are attached to every transport request — typically a bearer token.Configuration reference
| Field | Type | Required | Description |
|---|---|---|---|
url | str | Yes | The MCP server’s streamable-HTTP endpoint. |
headers | dict[str, str] | — | Headers attached to every transport request. Use for Authorization and similar. Defaults to {}. |
name | str | — | Logical name for log lines and telemetry. Defaults to mcp[<index>]. |
{"url": <string>}.
Hosted MCP example - Resemble Detect and Signal
Use this pattern when a caller provides a recording or media URL that should be checked for synthetic speech, or when caller-provided text should be scored for fraud and scam intent before the agent makes a trust decision. Resemble hosts an MCP server, so the agent can discover Detect, Signal, Watermark, and Intelligence tools without a custom wrapper.Real-world example — Postgres MCP server
Connect a phone agent to a Postgres MCP server so the caller can query an orders table by phone number.How it works
- Agent build time.
mcp_serversis stored on theAgentimmutably. No connections are opened. - Call start. The stream handler instantiates an
MCPManager, opens one streamable-HTTP connection per server, and callstools/liston each. Discovered tools are wrapped with a synthetic handler that, when invoked by the model, dispatchestools/callback over the same connection. - Conflict check.
MCPManager.assert_no_conflicts(...)(Py) /MCPManager.assertNoConflicts(...)(TS) compares MCP-discovered tool names against youragent.tools. A duplicate raises before the call connects. - During the call. MCP tools are indistinguishable from local handler tools —
ToolExecutorinvokes the synthetic handler, which round-trips through MCP and returns the result text to the model. - Call end. Every MCP connection is closed. Cleanup is best-effort and never blocks call teardown.
Tool-name collisions
If an MCP-discovered tool has the same name as a tool you defined inagent.tools, the SDK refuses to start the call:
Failure handling
A dead MCP server should never kill the call:- Connect failure (server unreachable, TLS error, bad auth): logged at
error, the server is skipped, the call proceeds with the remaining MCP servers and your local tools. tools/listfailure: logged, server is skipped, call proceeds.- Per-call invocation failure: the synthetic handler returns the same
{"error": "...", "fallback": true}envelope that local tools use, so the model can recover gracefully and apologise to the caller. - Close failure on call end: logged at
debug, swallowed. Teardown always completes.
Cost & latency
Each configured server adds one HTTP handshake plus onetools/list round-trip at call start — roughly 50–200 ms × N servers added to the time-to-first-token of the call.
If your call setup latency budget is tight, configure fewer servers, or split your fleet so latency-critical agents only see the MCP servers they actually need. Process-wide caching of tools/list results is on the roadmap.
Compared to writing a tool by hand
A tool that wraps an HTTP API by hand needs: a JSON schema for the parameters, a handler or webhook to call the API, error envelope shaping, and an entry inagent.tools. With MCP, the server already exposes a typed schema for every tool it offers, and Patter wires the dispatch automatically. You write zero per-tool code on the Patter side.
For one-off or in-process tools, a regular tool(...) is simpler. For sets of tools that someone else already maintains as an MCP server, MCP wins.
What’s next
Tools & Function Calling
Define your own tools with webhooks or in-process handlers.
PatterTool
The inverse pattern — expose a Patter agent as an MCP-compatible tool.

