Limits and best practices
An MCP tool runs on your server, so your server decides what the tool can actually do. The controls around it are which tools are on, the credential Ada connects with, and how the Agent chooses between tools. This page covers how to use those controls well and the limits to design around.
Start with read-only tools
The safest tools only read: look up an order, check status, fetch a record. They can’t change anything, so turning one on carries little risk.
Write tools create, update, or cancel something, so enable them deliberately, once you’re confident the Agent uses them in the right situations. Enable a few tools, test how the Agent uses them, then add more. Because a tool is only as limited as your server makes it, scope the credential you connect with to the least it needs. A connected account with broad write access can do a lot if a tool is called at the wrong moment. For an extra layer, keep a write tool behind a Playbook so it runs only inside a controlled flow.
Write descriptions the Agent can use
The Agent picks a tool from its name and description, both declared by your server. That wording is the main lever you have over when a tool runs:
- Be specific about what the tool does and when to use it. “Look up an order by its order number” beats “order tool”.
- Disambiguate similar tools. If two tools are close, make their descriptions say plainly how they differ, so the Agent doesn’t guess.
- Name tools distinctly across servers. When you connect more than one server, keep tool names clear enough that the Agent can tell them apart.
Because the description lives on your server, improving how the Agent selects a tool usually means editing the tool on your side.
Limits to design around
A few limits shape how tools behave in a conversation:
- About 30 seconds per call. If a tool doesn’t return in time, the Agent stops waiting and continues the conversation without that result. Keep tools fast.
- About 30,000 bytes per response. If a tool returns more than that, the Agent drops the whole result rather than reading part of it, then continues the conversation without it. Have tools return the fields a conversation needs, not a full record.
- Descriptions cap at 4,096 characters. A longer tool description is cut off during discovery, so the Agent can miss the end. Keep each description within the limit.
- Keep the enabled set focused. Turning on many overlapping tools makes it harder for the Agent to choose the right one. Enable what conversations actually need.
- Inputs come from your server. You don’t configure a tool’s inputs in the dashboard. The Agent fills them from the schema your server declares.
- The connection has to be live. If a server is disconnected or its credential expired, its tools don’t run, so watch the connection status on the Tools page and reconnect the server if its sign-in has lapsed.
- Personal-data tools run on four channels. Tools set to customer sign-in work on Ada web chat, Twilio SMS, Twilio WhatsApp, and Ada Instagram. Every other channel is skipped, including voice, email, and channels connected through Sunshine. See Authentication and channels.
Keep your server secure
Connecting a server is a shared responsibility. The dashboard controls which tools are enabled and the credential Ada connects with. You control what the tools and the credential can reach:
- Scope credentials to the least they need. A read-only integration should connect with read-only access.
- Expose only the tools you want an Agent to use. If a tool shouldn’t be available to conversations, don’t expose it on the server, or leave it off.
- Review what’s enabled. Periodically check which tools are on and whether each still needs to be.
Related features
- MCP tools overview: What MCP tools are and how they work.
- Connect a server: Add a server and turn on tools.
- Authentication and channels: Connected account vs. customer sign-in.