An agent that can only talk is a search box with better manners. The interesting behaviour starts when the model can do something — open a ticket, look up an order, post a status. Botmanor's route to that is the Model Context Protocol: you register the tool servers your organisation already runs, and agents that carry the MCP capability get those tools offered to the model on every turn.
The runtime is a genuine MCP client, not a metadata shim. It opens a real session against your server, lists its tools, and invokes them by name with the arguments the model produced. Inside a chat turn it assembles a tool list from the agent's connected servers, calls the model, executes any tool the model asks for, feeds the results back as tool messages, and calls the model again — the standard function-calling cycle, repeated until the model answers or the loop's iteration budget runs out. That budget matters: an agent that keeps requesting tools forever gets a clear "couldn't finish" instead of an unbounded token bill or a hung request.
Transport support is scoped on purpose, and the reasoning is worth reading before you compare feature checklists. Botmanor supports network transports — Streamable HTTP and the legacy SSE transport. It refuses stdio connections outright, because an MCP connection's configuration is tenant-authored data in a shared multi-tenant backend, and a stdio server's command field is a literal shell command; honouring it would be a remote-code-execution primitive. The same reasoning applies to the URLs you supply: every outbound target is checked against the platform's endpoint guard, which requires HTTPS and rejects private, loopback, link-local and metadata addresses along with internal-only hostnames. These are security boundaries, and they fail closed with a readable message rather than silently no-op'ing.
Delegation rides the same machinery. An agent with the agent-to-agent capability sees its outbound peers as additional pseudo-tools, so "ask the billing specialist" is, to the model, just another tool call — which keeps one loop, one audit trail and one set of bounds instead of two parallel runtimes.
The honest status: the tool loop is live on the OpenAI-wire provider path — OpenAI itself, Azure OpenAI, and custom OpenAI-compatible endpoints you point at your own model server. Agents on Anthropic, Google, Cohere, Mistral, Groq, Together, HuggingFace or Bedrock still get normal single-turn responses today, because those providers' native tool-calling wire formats differ enough to need their own adapter pass. Per-agent tool allow-lists — choosing which of a server's tools a given agent may call, rather than all-or-nothing — are on the roadmap alongside them.
Today the MCP tool loop runs in the execution layer for OpenAI-wire providers, but attaching an MCP connection to an agent is API-only in the current UI. Because a real user cannot complete the full story by clicking through the web app alone, this page is presented as a narrative pattern rather than a clickable "Do it yourself" section.
Ready to make this your story?
