MCP Connectors
Give a Chatley AI voice agent access to tools on your own MCP server, so it can look things up and take action while a caller is on the line.
An MCP Connector points one of your AI voice agents at your MCP server, so it can call your tools during a live call — look up an order, check availability, create a ticket — and use the answer in the conversation.
This is the opposite direction from the MCP Server. There, your AI agent operates Chatley. Here, a Chatley AI voice agent uses your tools.
Why this is useful
If you already run an MCP server, or use an automation platform that exposes one, your AI voice agent can reach everything behind it without Chatley building a dedicated integration for each system.
For the systems that matter most to you, Chatley's own integrations are still the better choice: they are faster on a live call, they receive events rather than only answering questions, and we can debug them for you. Use MCP Connectors for the long tail.
Setting one up
- Register the server. Its HTTPS URL, plus any headers or query parameters it needs — an API key, a tenant identifier, a version flag. Authentication can be none or a bearer token.
- Discover its tools. Chatley connects and lists what the server offers.
- Attach it to an AI voice agent and select the tools that agent may use.
- Configure each tool's hold audio and timeout.
Requirements
| Transport | Streamable HTTP preferred, SSE supported |
| URL | HTTPS only — plain HTTP is rejected |
| Local servers | Not supported. A stdio server on your own machine is not reachable by a hosted platform |
| Credentials | Stored encrypted, per account. Entered once and never displayed again |
Choose tools deliberately
Attach only the tools that agent's job actually needs.
This is not tidiness. A long tool list measurably degrades the quality of an AI voice agent's responses and slows it down, and both are audible to a caller. An agent that books appointments does not need your invoicing tools.
Tools do not update themselves
Chatley does not re-read your server automatically. If you add, rename, or remove a tool, run discovery again from the connector's page.
This is deliberate: a tool list that changed under a live agent without anyone deciding to change it is a bad surprise. Each connector shows when it was last discovered, so a stale list is visible rather than silent. Your existing tool selections are preserved across a rediscovery.
While the caller is waiting
A tool call happens with a human on the phone. Silence sounds like a dropped call, and callers hang up — so every tool has two settings that matter.
Hold audio plays while the tool runs and loops until it returns: nothing, typing, ambient sound, or a light musical bed. Pick per tool. A fast lookup can run silently; anything that takes a noticeable moment should not.
Timeout bounds the wait. On timeout the AI voice agent carries on with the conversation rather than stalling — it will say it could not retrieve the information, not go quiet.
When your server has a problem
Chatley is built so that a problem on your side does not become a failed call.
| What happens | What the caller experiences |
|---|---|
| Your server is unreachable when the call starts | Its tools are skipped. The call proceeds normally |
| A tool times out | The agent continues the conversation without that answer |
| A tool returns an error | The agent continues. The failure is recorded on the call |
| Your credentials are wrong | Surfaced when you run discovery, so you find out then — not at 2am on a live call |
Tool failures appear on the call record, so a pattern is visible in your call history rather than only in your own logs.
Several servers at once
You can register more than one. Tool names are namespaced per server, so two
servers can both offer a tool called search without colliding — your agent sees
them as distinct.