the app
Host
The application a person works in — a chat assistant, a code editor, an agent runtime.
Model Context Protocol
The whole platform as an MCP server — signed in as you.
One link for every AI assistant in the company. Each person signs in, and their assistant works within their role.
Botminds speaks the Model Context Protocol both ways. Claude, ChatGPT, Cursor and VS Code connect to the hosted MCP server with each person’s own sign-in, and Botminds agents call outside MCP servers through allow-lists. Piper, agents and outside assistants share one catalogue of 700+ tools, behind the same checks.
Inbound · the platform as an MCP server
- Your AI assistantClaude, ChatGPT, Cursor, VS Code or any MCP client
- Botminds MCP serverone link · sign in as yourself · your role decides
- The platformagents, collections, workflows, pages, governance
One tool catalogueOne grant checkOne audit trail
Outbound · agents as MCP clients
- A Botminds agentgranted an outside server by name
- Allow-listthe tools you name from it
- Outside MCP serverticketing, code, search, your own
What is an MCP server?
An MCP server is a program that offers tools and data to AI assistants through the Model Context Protocol, an open standard. The assistant asks the server what it can do, then calls those tools and reads the results. The Botminds MCP server offers the whole platform this way, to every assistant in the company — and every call runs as the person who signed in, with that person’s permissions.
Scales out on KubernetesServices and workers add capacity as work arrives, and give it back when it is done.
Built for millionsMillions of documents, records and agent runs — the indexes and workers grow with them.
Any cloud, any regionAzure, AWS, Google Cloud or on-premises, in the region your data must stay in.
Always onRedundant services, rolling releases and continuous backups, for mission-critical work.
Secure and governedSingle sign-on, encryption, least privilege and a sealed audit trail.
The protocol in brief
Model Context Protocol: one plug for every assistant.
MCP turns one integration per assistant per system into one contract: a server describes its tools, any client lists and calls them, and the model decides when a tool would help. For a remote MCP server, the enterprise questions — who is calling, what may they see and do — are answered by the platform behind it.
one per server
Client
Holds the connection to one server: lists its tools, sends calls, returns results to the model.
the tools
Server
Describes tools with names, plain-words descriptions and typed arguments, and runs them.
local or remote
Transport
A local process for desktop tools, or HTTP for a remote server that many people reach from anywhere.
Inbound
The Botminds platform as a remote MCP server.
Each Botminds deployment can publish its MCP server at its own address. A person pastes the link into the assistant they already use, signs in through the browser, and allows the connection — no key to hand out, no configuration file to share.
- AssistantCalls the link with no tokenThe server answers “not signed in” and says where to sign in.discovery
- AssistantRegisters itselfAs a public client: it holds no secret, so it has none to leak.self-registration
- YouSign in as usualThe normal Botminds sign-in page, with your workspace’s rules.your identity
- YouAllow accessA card names the app, who you are signed in as, and where you return.consent
- PlatformIssues a token bound to this serverBound to this MCP server and the MCP scope; a code-exchange proof stops interception.audience-bound
- PlatformRuns every call as youEach tool call is checked against your role, like the product screens.your permissions
# a terminal assistant
claude mcp add --transport http \
botminds https://<host>/mcp
# sign in when it asks: your browser opens
# Cursor, VS Code and others
{ "botminds": {
"url": "https://<host>/mcp" } }- Works withClaude, ChatGPT, Cursor, VS Code and any client that follows the MCP authorization spec; local-only clients bridge to the link.
- One link for everyoneWho signs in decides what the assistant may do.
- Scripts and servicesHeadless integrations use API keys and the Runtime API.
MCP enterprise authentication
MCP enterprise authentication: every call, one signed-in person.
Identity is where a remote MCP server earns trust. The Botminds MCP server holds no identity of its own: every request carries a valid token for one person, and is handled as that person.
Per-person OAuth
Authorization code with a proof key, and self-registration for assistants. Assistants are public clients, so there is no client secret to steal.
- Discovery from the link
- Consent names the app
- Revoke at any time
Tokens bound to this server
Each token names the MCP server it was issued for and carries the MCP scope. Tokens issued for anything else, including a browser session, are refused.
- Signature checked on every call
- Expiry and audience checked
- Valid where it was issued
Each request on its own
The server holds no shared key and keeps no session between calls, so each caller’s identity stays with that caller.
- Per-person identity
- Stateless by design
- Fails closed
You stay in charge of the connection
- See itEvery connected AI client, with who connected it and when it was last used.
- Disconnect itThe app stops renewing its access, and its access ends when its token expires.
- Suspend the personEvery connection of that account ends at once.
Every step logged.
- RegisteredAn assistant registered itself.
- Allowed or deniedA person answered the consent card.
- Token issuedAccess granted to that app for that person.
- DisconnectedAccess withdrawn. Logs carry ids, never tokens.
What an assistant can do
Exactly what you can do — checked on every call.
Signing in proves who is calling. What they may do is the platform’s decision, made the same way for an assistant as for the person clicking through the product. The tool list is shaped to the role, so each person’s assistant offers what fits their work.
One tool callfrom Claude, ChatGPT, Cursor…
- TokenA real signed token, unexpired, for this server and the MCP scope. A browser session token is refused.no token → 401
- What is offeredThe tool list is shaped to your role, so each person sees the tools that fit their work.shaped to you
- What is allowedThe platform checks the call as you — the same rule as its own screens.not yours → refused
- Delete and replace ask firstTools that delete or replace something ask first. Inside Botminds agents a yes is checked against the conversation; your assistant’s own approval prompt shows each call before it runs.yes → it runs
- LoggedChanges go on the audit trail as yours. Connections and consents are logged by id, never the token itself.logged
Member
Reading, searching, and running what already exists.
Project builder
Also building agents, fields, workflows and pages.
Workspace admin
Also users, roles, keys, connectors and models.
Platform admin
Everything the platform offers.
One catalogue
One tool catalogue for Piper, agents and outside assistants.
Piper builds with it, the platform’s agents run with it, and outside assistants reach it through the hosted MCP server. A capability added for one is there for all three — and so are its checks: a permission rule or an audit line added to a tool holds for every caller at once. Tools that delete or replace something ask first; inside Botminds agents a yes is checked against the conversation, and your assistant’s own approval prompt shows each call before it runs.
- buildsPiperplans, waits for your yes, then builds
- runYour agentsgranted tools by name, or search the catalogue for what fits
- connectOutside assistantsClaude, ChatGPT, Cursor, VS Code — signed in as you
700+platform tools · one catalogue
- Agents
- Collections & fields
- Documents
- Knowledge
- Workflows
- Meshes
- Pages & cards
- Packs
- Users & roles
- Connectors
- Models
- Evaluations
- Versions
- Audit
- Observability
- Packages
One rule for every caller: the platform decides each call, as the person behind it.
Outbound
MCP servers for AI agents: calling out, allow-listed.
Botminds agents are MCP clients too. Point an agent at your ticketing system’s MCP server, a code host’s or one you built, and it uses those tools in its run — under the same grants, approvals and records as any other tool.
Agent run
- Registered onceAn admin adds the server: its address, how it connects, and its credential. A connection test lists its tools, so you can name the ones each agent needs.project or platform-wide
- Granted by nameEach agent is bound by name to the servers it uses.per agent
- NarrowedAn allow-list keeps the tools you name. Each carries the server’s name, so every tool stays distinct.allow-list
- Held for a personYou choose which tools wait for a person to approve, reject or edit the call, right in the conversation.approval
- Credential added server-sideThe runtime fetches it over a signed server-to-server call, pinned to the address it was saved for.stays server-side
Outside MCP server
Any transport
Remote over HTTP, a local process, or a socket — whatever the server speaks.
Its own sign-in
A bearer token or an API-key header, stored encrypted and shown in lists and exports only as “saved”.
Tested first
A connection test lists the server’s tools, so you name exactly the ones each agent needs.
MCP security
MCP security: the known risks, and what answers each.
MCP widens what a model can reach. These are the risks security teams raise most, and the control that answers each on Botminds.
prompt injection
Instructions hidden in content
An agent reaches the tools it was granted, and you choose which changes wait for a person — so a steered model stays inside what was already allowed.
token misuse
Borrowed or replayed tokens
Tokens are bound to this server, signed, short-lived and checked on every call.
confused deputy
A server with its own power
The server acts as the caller, and the platform checks the caller.
over-broad access
Too many tools
Tool lists shaped to the role; agent tools granted by name; outside servers narrowed by allow-lists.
secret exposure
Keys leaking
Outside servers’ credentials stay server-side; the runtime reads them server to server.
isolation
Crossing tenants
Each request runs as one person in one workspace they can open.
More on this. Granted tools, approvals and records: AI agent security. Certifications and data protection: the security page.
At scale
An enterprise MCP server at scale: every assistant, one catalogue.
One address serves every assistant and agent in the company. The hosted server is stateless, so any copy serves any call and copies are added as traffic rises; each copy checks the person’s signed token itself. Behind it, one catalogue of 700+ tools runs on platform services that scale out on Kubernetes, in any cloud and region.
Every assistant and agent
- Claude
- ChatGPT
- Cursor
- VS Code
- Your agents
- Piper
- + thousands of people
Hosted MCP server · stateless
copy 1copy 2copy 3copy 4+ more as traffic rises
Any copy serves any call. Each checks the person’s signed token itself — no shared session to look up.
The platform700+ toolsone catalogue, on services that scale out on Kubernetes
Side by side
MCP vs API: what an MCP server adds.
Most MCP tools call an API underneath. MCP changes who the caller is — a model choosing tools at run time — and so what the server must describe and enforce.
| REST API | A typical MCP server | Botminds MCP server | |
|---|---|---|---|
| Built for | Programs written against it | AI assistants choosing tools | Assistants, agents and Piper — one catalogue |
| Discovery | Read the docs | The client lists tools at run time | Lists tools, shaped to the caller’s role |
| Who is calling | An API key or a service account | Often a shared key in a config file | The signed-in person, through OAuth |
| Permissions | Whatever the key holds | Whatever the server holds | The person’s role, checked on every call |
| Changes | Run when called | Run when called | Tools that delete or replace something ask first; your assistant’s approval prompt shows each call |
| Revoking | Rotate the key | Edit the config | Disconnect the app, or suspend the person |
| Audit | Request logs | Varies | Changes on the audit trail; connections and consents logged |
| Scale | Your API tier | One process per user, often | A stateless hosted server that scales out |
Both have a place. Services, schedules and back-office jobs use the Runtime API with keys, rate controls and idempotency. People working through an assistant use the MCP server, so the platform knows exactly who is acting.
Questions people ask
MCP, answered.
More from the platform: the full architecture, and how security works at Botminds.
What is an MCP server, in simple terms?
An MCP server is a program that gives AI assistants tools through the Model Context Protocol. The assistant asks what the server can do, then calls those tools and reads the results. The Botminds MCP server offers the platform this way, as the person who signed in.
What is the Model Context Protocol?
The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data. A server describes its tools; any MCP client can list and call them. It replaces one-off integrations with one contract.
How does MCP enterprise authentication work on Botminds?
With OAuth. The assistant discovers where to sign in from the link, registers itself as a public client, and sends the person to the normal Botminds sign-in and a consent card. The token it receives is valid for this MCP server and checked on every call.
MCP vs API — which should I use?
Use an API with keys for programs and scheduled jobs. Use the MCP server when a person works through an AI assistant, so every call is made as that person. On Botminds both sit on the same platform rules. See the comparison above.
Is MCP secure?
The protocol is as safe as the server behind it. The risks are borrowed tokens, servers acting with their own power, over-broad tools and leaked keys. Botminds answers each: per-person tokens bound to the server, every call made as the caller, role-shaped tool lists, allow-lists and credentials that stay server-side.
Which AI assistants can connect to the Botminds MCP server?
Claude, ChatGPT, Cursor, VS Code and any client that follows the MCP authorization spec. Clients that run local servers bridge to the remote link.
What can a connected assistant do?
Exactly what you can. Every call runs as you and is checked against your role by the same rules the product uses, and tools that delete or replace something ask first — your assistant’s own approval prompt shows each call before it runs.
How do I disconnect an AI assistant?
From the AI clients list, or by asking Piper. The app stops renewing its access, and its access ends when its token expires. To end every connection of a person at once, suspend their account.
Can Botminds agents use outside MCP servers?
Yes. Register the server once, test it, bind it to an agent and set an allow-list of the tools it may use. Credentials stay server-side, and you choose which tools wait for a person’s approval in the conversation.
Can the MCP server serve a whole company?
Yes. One address serves every assistant and agent. The hosted server is stateless and scales out as traffic rises, each person signs in as themselves, and the platform behind it scales out on Kubernetes.
Bring your assistant. Keep your controls.
We’ll connect your team’s AI assistant to Botminds on your own data, with your roles, and show the record it leaves.