Academy · Developer
MCP integration
In one line. The Model Context Protocol connects Botminds to the wider agent ecosystem in both directions: your agents can consume external MCP servers, and the platform hosts its own MCP tool surface so AI assistants can operate Botminds. You’ll be able to. Pick the right direction for your integration, and know what governs each. Where this lives.
Studio ▸ Agents ▸ MCP Serversfor a project’s own servers;Administration ▸ Extensions ▸ MCP Serversfor the ones an administrator makes available to every project.
Two directions, one protocol
MCP is the open standard for giving AI tools capabilities. On this platform it runs both ways:
| Direction | What it means | Governed by |
|---|---|---|
| Inbound capabilities — your agents consume external MCP servers | An agent gains tools from any MCP server you register: an internal system, a SaaS product, a partner API | Register the server at Studio ▸ Agents ▸ MCP Servers, then attach it to the agent from the agent’s tools; filter the tool list per server (A7) |
| Outbound operation — external AI tools drive Botminds | The platform hosts an MCP server exposing curated platform operations — list collections, inspect runs, query documents — so an external AI assistant can work with your workspace | Tool profiles + platform authentication; every call carries workspace scope |
Consuming MCP servers (the common case)
Covered in depth in A7 · MCP servers: register the server, filter which of its tools are exposed, attach it to an agent.
There are two places a server can be registered, and the difference decides which one you are allowed to touch. Studio ▸ Agents ▸ MCP Servers holds the servers belonging to one project — yours to add and change if you run that project. Administration ▸ Extensions ▸ MCP Servers holds the servers an administrator publishes to every project; you attach those to an agent but don’t edit them.
Two disciplines carry from there:
- Scope tightly. An empty tool filter exposes everything the server offers; curate the list to the job.
- Prefer read-only servers for agents that face users, and treat destructive tools with the same caution you’d give a production credential.
The hosted Botminds MCP
The platform hosts its own MCP server, whose tools are the platform’s own operations, organized into profiles — curated tool subsets shaped for a purpose rather than one giant surface. Calls are scoped to a workspace, and the tools apply the same access rules as the screens — a caller works within the access the account behind it already has.
This is the surface Piper, the platform’s assistant, runs on — when it answers “how many documents landed today,” it is calling these same tools. Pointing an external assistant at it gives that assistant the same governed reach.
The set of tools on offer differs between installs — the profile list you see in the product is the authoritative one.
Choosing your integration style
| You want | Use |
|---|---|
| Deterministic system-to-system calls, contracts, SLAs | Runtime API — REST, keys, stable paths |
| An AI assistant that operates the platform conversationally | The hosted MCP surface |
| Your Botminds agents reaching into other systems | Inbound MCP (A7) or custom tools |
The rule of thumb: machines integrate over REST; minds integrate over MCP.
Where to go next
- Registering and scoping servers: A7 · MCP servers.
- The REST alternative: V1 · Runtime API.
- What governs any caller: G1 · Access & roles.
Prefer learning inside the product? The same academy lives in the platform's Learn menu — every screen links to the chapter that explains it.
See the platform live