Tools and MCP

An agent that only answers leaves the work with you. This page covers how the platform lets one act: what happens inside a turn when a tool is called, what stops that from destroying the conversation, and how your own systems get connected.

The tool loop

A turn is not a single model call. The model may answer, or it may ask to call a tool; if it calls one, the result is appended to the conversation and the model runs again with that result in hand. It may then call another. The loop continues until the model produces an answer, or until an iteration limit is reached.

The limit matters: without it, a model that keeps calling tools — a genuinely common failure — would run indefinitely, spending tokens and leaving the customer waiting on a reply that never comes.

Two budgets, not one

Tool results are the most common way a conversation's context gets destroyed. A single CRM query can return more text than the model's entire context window.

Capping each individual result is the obvious defence, and it is not sufficient. Results accumulate across iterations — the conversation only grows — so the worst case is the iteration limit multiplied by several tools per iteration multiplied by the per-result cap. Each result passes its own limit and the total still overflows.

So there are two budgets: a per-result cap, and an aggregate budget for the whole turn. Once the aggregate is exhausted, further results are replaced with a short placeholder rather than appended.

What is in that placeholder matters as much as the truncation itself. A silently truncated result is worse than none, because the model has no way to know it is reasoning from half a record. Both the truncation notice and the exhaustion placeholder state explicitly that the content is incomplete and instruct the model to answer from what it has and not to invent the missing part — the difference between an agent that says "I could only see the first few orders" and one that confidently makes up the rest.

Truncation is also logged with the tool name and sizes, because a tool that regularly overflows the budget is a tool that should be returning fewer fields — a configuration problem worth seeing.

Models that don't emit proper tool calls

Not every model reliably produces structured tool calls; some emit the call as text in the reply. Rather than treat that as a failed turn, the loop also parses tool calls out of the message content, and strips malformed fragments before the reply reaches the customer — so a model having an off moment degrades into a slightly slower turn instead of leaking JSON into a conversation.

Connecting your own systems

Tools come from two places.

Built-in tools ship with the platform — scheduling a follow-up, creating a reminder, capturing contact details, invoking a skill, web search.

Your systems connect over MCP. A tenant registers MCP servers, and their tools become available to that tenant's agents. Three transports are supported: stdio for a local subprocess, and streamable_http and sse for remote servers. A remote HTTP server is the usual choice for a hosted CRM or internal API — nothing to install alongside the platform, and the connection is per tenant.

Because tool definitions are registered per tenant, one tenant's agents can never see another's tools or endpoints.

What this means in practice

• An agent can look something up mid-sentence and answer with the real value.
• It can book, file and record into the systems you already run, rather than telling the customer to do it.
• When a tool returns more than the turn can hold, the agent says its view was partial instead of filling the gap with plausible fiction.

The business argument for acting rather than answering is on Agents that act.