An assistant that can only answer from its prompt and documents is a very good FAQ. An assistant that can look up an order, create a ticket, or check a calendar is a colleague. The gap between the two is tools, and the question every team hits is how to connect them without writing a new integration for each one.
The Model Context Protocol (MCP) is the answer the industry converged on: a server describes its tools once, and any assistant that speaks MCP can use them. This article explains how MCP works in Assistant Core, when a plain HTTP tool is the better choice, and the safeguards that make connecting a third-party server safe enough to put in front of customers.
Four kinds of tools, one tool loop
Everything the assistant can do beyond answering goes through one handler, whatever the tool's origin:
| You want the assistant to | Use |
|---|---|
| Search your documents, remember users, search the web, generate images, schedule tasks | Built-in tools, on by default |
| Call one HTTP endpoint you own | A custom API tool |
| Use all the tools of a server with a public URL (Notion, a CRM, your own MCP server) | A remote MCP server |
| Use MCP servers on your own computer or private network | A local connector |
| Control hardware on an ESP32 device during a voice session | Device tools, declared by the firmware |
The assistant decides by itself when a request needs a tool; users never name them. For a single endpoint such as "get order status", a custom API tool is simpler than an MCP server. MCP earns its place when a system already exposes a server, or when you want ten tools from one connection instead of ten configurations.
What happens on a tool call
- The assistant picks a tool from those offered on the current channel.
- If the call changes something, it may wait for a person's approval.
- The tool runs, and the assistant writes its reply from the result.
Step 1 hides a decision many platforms skip: which channel the request came from. Each tool can be limited to the web app, the widget, the Developer API, voice, or messaging channels. A tool that creates orders can be available to signed-in staff in the web app and absent from the public website widget, with the same assistant and the same prompt. MCP servers can declare the surfaces their tools support in the tool metadata; you can narrow that list but not widen it.
Connecting a remote MCP server
In the admin panel, a server is a name, a public HTTPS URL, and optionally an authorization type: OAuth sign-in, a bearer token, an API key header, basic auth, or a custom header. Streamable HTTP is the recommended transport. Private and local addresses are refused; a server on your own network connects through a local connector instead.
For OAuth servers, the owner decides who signs in. With "you, for everyone", every user of the assistant acts through the owner's account, which suits a shared CRM. With "each user, with their own account", each signed-in user connects their own Gmail, Google Calendar, Notion, Atlassian, Linear, Canva, or Stripe the first time the assistant needs it, from a card in the chat. Those per-user tools are not offered on the widget, the API, or messaging channels, because there is no signed-in user there to act as.
Ready-made apps are one click; only their read-only tools start enabled.
Four safeguards for a server you do not control
Connecting a third-party server to something that talks to your customers needs more than an on/off switch. These are the rules the runtime enforces:
1. Tool definitions are pinned. The assistant uses each tool exactly as it was when its tools were last loaded. If the server later changes a tool's description or parameters, or adds a new one, that tool stays off and the server shows as degraded until you review the change and click Refresh tools. A server cannot slip new instructions into a description after you approved it.
2. Results are untrusted data. Output from MCP servers and connectors is passed to the model marked as untrusted, so instructions hidden in a result ("ignore your previous rules and…") are not followed as if they came from you.
3. Writes ask first. Tools that read run on their own. Tools that write or delete ask a person in the chat before running; scheduled tasks hold them for later. Users can save "don't ask again" rules, and the owner can set Allow, Ask, or Block for everyone. Where nobody can approve (widget, API, voice, messaging), tools that delete are not offered at all. Which category a tool falls in comes from the readOnlyHint and destructiveHint it declares, applied when its tools are refreshed.
4. Every call is traced. Each tool call is recorded with the LLM trace of the turn that made it, including its cost in credits, so operators can see what the assistant did and why.
Credentials are encrypted with a key management service and never shown again after saving.
Your assistant as an MCP server
MCP runs in the other direction too. Assistant Core exposes its own MCP server, so you can manage assistants, search a knowledge base, or install the widget from ChatGPT, Claude, or your coding tools, with consent granted in the admin panel. The same protocol that lets your assistant use a CRM lets your other AI tools use your assistant.
Where to start
Turn on the built-in tools you need, add one custom API tool for the question your documents cannot answer, and connect an MCP server when a system you already use offers one. Limit each tool to the channels where it belongs before you connect a public channel. The step-by-step guides are in the tools and MCP documentation, and the security page covers the boundaries around tools in more depth.