Overview
Register tool servers in the organization and install them in workspaces.
MCP is an open protocol for exposing tools to AI models. An MCP server publishes a set of tools, and the Agent decides when to call them.
Turning on an MCP takes two steps, on different screens: the organization registers the server in the catalog, and each workspace installs what it will use. This page covers both.
The organization registry
Organization › MCPs is the catalog of servers approved by the company. No workspace installs an MCP that hasn't gone through here.
The screen opens for Superadmin and Admin, but registering new servers is the Superadmin's privilege. It has three tabs:
- Installed: the servers already registered in the organization.
- Docker Hub: public catalog of MCPs distributed as images.
- GitHub: public catalog of MCPs distributed as repositories.
The two public catalogs let you discover and register without leaving the platform. The step by step is in Register a server.
Make it available to a workspace
Registering doesn't hand the server to anyone. Availability is set under Organization › Workspaces, in each workspace's MCPs section.
This is the step people tend to forget: a server in the registry with no workspace able to install it almost always means that association wasn't made.
Install in the workspace
Workspace › MCPs is where the server is actually turned on. Installing and configuring requires the Owner, Curator or Editor role.
The screen has two tabs:
- Installed: the servers already turned on in this workspace, with each one's configuration.
- Available: what the organization made available and hasn't been installed here yet.
When installing, you give the server a name and the configuration this workspace needs. The same registry server can be installed several times in the same workspace, as long as each installation has a different name. That is how you point to two environments of the same system.
Configuration and behavior belong to the installation, not to the registry entry. Changing one installation doesn't affect the others or the item registered in the organization.
Hand it to an agent
Installing in the workspace still isn't enough. Each Agent has to check the MCP in the MCPs section of its own form.
That is also where the maximum iterations lives, which limits how many times that Agent can call tools in a single answer. This prevents a loop when a tool returns something unexpected.
Remove
Removing an installation stops its use in that workspace. Agents that had it checked stop calling those tools and answer without them, with no error visible to the person chatting.
Removing the server from the organization registry doesn't undo what workspaces have already installed, because the configuration belongs to the installation. To stop its use for good, you need to remove it in both places.
When a tool isn't called
- The MCP isn't checked in the Agent: installing in the workspace isn't handing it to the Agent.
- The iteration limit was reached: the Agent wrapped up the answer before completing the calls.
- The server is down: the failure shows up in the traces, under Observability.