MCP
Connect Calleague to Model Context Protocol clients — let an assistant discover and call your tools mid-conversation, or expose Calleague capabilities to MCP-capable clients.
The Model Context Protocol (MCP) is a shared way for AI assistants to discover and call outside tools through one common interface. Instead of building a one-off connector for every system, a tool provider publishes its capabilities once, and any MCP-capable client can use them. This page is an app-level overview of how MCP fits into Calleague, how to connect, and what it exposes.
At a glance
| Topic | Summary |
|---|---|
| What it is | A shared, discoverable contract for calling tools. |
| Two roles | A provider publishes tools; a client discovers and calls them. |
| Calleague consuming | An assistant can call tools published over MCP, mid-conversation. |
| Calleague exposing | Calleague capabilities can be offered to MCP-capable clients. |
| Auth | Connections are scoped and credentialed like any privileged integration. |
How MCP fits
MCP separates two roles:
- Provider — publishes a set of tools an assistant can call.
- Client — discovers what a provider offers and calls those tools on the assistant's behalf.
Because the interface is standard, the same tools can be reused across different assistants, and one assistant can reach many providers at once. There's no bespoke glue per integration — discovery and calling follow the same protocol everywhere.
Calleague and MCP
Calleague works with MCP in two complementary directions:
| Direction | What it means | Use it to… |
|---|---|---|
| Consuming | A Calleague assistant uses tools published over MCP, the same way it uses any other tool mid-conversation. | Let an assistant look up an order, check stock, or open a ticket during a call. |
| Exposing | Calleague capabilities are made available to MCP-capable clients so they can be discovered and called. | Let an outside assistant reach Calleague actions through a shared contract. |
Either way, MCP is another path for an assistant to reach an outside capability — with the benefit of a shared, discoverable contract instead of a custom integration per tool.
Connecting
Decide the direction
Choose whether Calleague will consume an MCP provider (so an assistant can call its tools) or expose Calleague to an MCP client. The two are independent and can both be on at once.
You'll set up each direction separately, so pick one to start.
Configure the connection
From the integrations area of the app, add the MCP connection and the credential it should use. Scope the credential to only the tools the integration needs.
You'll see the connection listed once it's saved.
Confirm discovery
Once connected, the available tools are discoverable through the standard MCP interface. Check the tools you expect actually appear before you rely on them in a live conversation.
You'll see the provider's tool list — confirm the names you need are there.
Use it in a conversation
When consuming, attach the tools to the assistant that should be able to call them. The assistant decides when to call a tool from the conversation, the same as any other tool.
You'll see the assistant call a tool only when the conversation calls for it.
MCP discovery is dynamic: when a provider adds or changes a tool, a connected client can pick it up without you rebuilding a connector. Re-confirm the tool list after a provider changes its catalogue.
Example: a tool an assistant can call
A tool exposed over MCP describes its name, what it does, and the inputs it expects. An assistant uses that description to decide when and how to call it. Illustratively, a call might look like:
{
"tool": "lookup_order",
"description": "Look up an order's status by its ID",
"input": {
"orderId": "A-1042"
}
}The provider returns a structured result the assistant can read back to the caller:
{
"tool": "lookup_order",
"output": {
"orderId": "A-1042",
"status": "shipped",
"eta": "2026-01-03"
}
}Treat an MCP connection like any other privileged integration: scope its access narrowly, keep its credential in your own secret store, and confirm it's covered by your retention and consent settings before it touches customer data.
What MCP exposes
| Concept | Description |
|---|---|
| Tools | Named, described actions an assistant can call, each with a typed input. |
| Discovery | A client can list a provider's tools without hardcoding them in advance. |
| Calling | The assistant calls a tool by name with inputs; the provider returns a result. |
| Results | Structured output the assistant can read back into the conversation. |
Designing good tools
When you expose tools an assistant will call, the name and description are part of what the assistant reads — it decides whether to call a tool from those alone. A few principles keep calls accurate:
| Principle | Why it matters |
|---|---|
| Name tools by intent | lookup_order reads better to an assistant than dbQuery2. |
| Write a one-line, specific description | The assistant picks a tool from its description; vague text causes wrong or missed calls. |
| Keep inputs minimal and typed | Fewer, well-named inputs reduce the chance of a malformed call. |
| Return compact, structured results | The assistant reads results back to the caller; trim what it doesn't need. |
| Fail with a clear message | A descriptive error lets the assistant recover or explain, rather than stall. |
Treat tool descriptions like wording an assistant reads: short, unambiguous, and focused on when to use the tool. If an assistant calls the wrong tool, sharpen the description before anything else.
If something looks different
| Symptom | Likely cause | Fix |
|---|---|---|
| Tools don't appear | Connection not established or credential rejected | Re-check the connection and that the credential is valid |
| A tool is missing | Provider catalogue changed | Re-confirm discovery after the provider updates |
| Assistant never calls a tool | Tool not attached, or description unclear | Attach the tool and make its description specific |
| A tool call returns an error | Bad input or too-narrow scope | Validate inputs; widen the credential's scope to what's needed |
| Sensitive data reaches a tool unexpectedly | Scope too broad | Narrow the credential and confirm retention/consent settings |
MCP vs. REST vs. webhooks
| You want to… | Use |
|---|---|
| Let an assistant call outside tools during a conversation | MCP (consuming) |
| Offer Calleague actions to an outside assistant via a shared contract | MCP (exposing) |
| Trigger or look up calls and assistants from your own code | REST API |
| React the instant a call event happens | Webhooks |