--- title: "MCP servers" slug: admin/integrations-mcp url: https://projectri.com/docs/admin/integrations-mcp section: admin audience: admin app_route: "/[slug]/admin/integrations/mcp" permissions: [mcpserver.view, mcpserver.manage, mcpserver.call] plan: platform.mcp_outbound mobile: false updated: 2026-09-08 source: Projectri documentation --- # MCP servers Register outside MCP servers so this workspace's automations can call their tools, choose which tools are callable, and read what was sent. ![MCP servers](https://projectri.com/docs-shots/admin-integrations-mcp.png) ## What it is This is the **outbound** half of MCP: servers your workspace registers so its automations can call somebody else's tools. Each registration is discovered on save, its tools are listed with a switch each, and every call made on your behalf is recorded. The inbound half — an MCP client such as an editor calling *Projectri* — has no screen here. You set that up from **Connect IDE** on [Security](/docs/admin/security). ## How to get there **Work → Integrations → MCP servers**, or the **MCP servers** link from the integrations page. **All integrations** takes you back. - Reading servers, tools and the call log needs `mcpserver.view`. It is withheld from the blanket viewer grant, because the call log holds the arguments sent on this workspace's behalf. - Registering a server, storing a credential and enabling a tool need `mcpserver.manage`. Registering decides what our servers will connect to, which is why it is an administrator's key. - Invoking an enabled tool needs `mcpserver.call`, kept separate because calling a third-party tool acts on your other systems under your credential. The feature is gated on the `platform.mcp_outbound` entitlement (ENTERPRISE). Without it the page still loads and existing servers are read-only — the **Register server** button is disabled and a note says why. ## How to use it ### Register a server 1. **Register server**. 2. **Name** it — it has to be unique in this workspace. 3. **Endpoint URL** must start with `http://` or `https://` and must be reachable from the public internet. An address that resolves inside our network is refused, with the reason. 4. Choose the **transport**, then the **authentication**: no credential, a bearer token, or a custom header (which asks for the header name). 5. The credential is stored encrypted and never shown again. 6. **Register and discover** saves the row and performs the handshake in one call. They can disagree: the row is saved even when the handshake fails, and the message tells you which happened. ### Choose which tools are callable 1. Expand a server with **Manage** and stay on the **Tools** tab. 2. Each tool lists its description and its parameters, with required ones marked. Toggle the ones automations may call. 3. **Save** applies the changes; **Discard** returns to what was stored. 4. **Rediscover** re-reads the server's tool list — use it when the vendor adds or renames one. ### Read what was sent The **Log** tab records every call: the tool, the caller, how long it took, and the request and response. The status is one of **Succeeded**, **Failed**, **Blocked**, **Timed out** or **Replayed**. *Blocked* means our own egress guard refused to dial that address — the third party is not at fault, and going to debug their server is the wrong move. ### Pause or unregister a server 1. The **Settings** tab has an **Enabled** switch. Turning it off stops automations calling the server without unregistering it. 2. **Unregister server** asks you to type the name. It removes the server and its tools; **the call log is kept**, because what was sent on a customer's behalf outlives the registration that sent it. ## What it affects - **Automations.** An enabled tool becomes callable from a rule. Disabling the tool, disabling the server or unregistering it all stop those rules working. - **Your other systems.** A call acts under the credential you stored, against the vendor you named. That is why calling is its own permission. - **Nothing inside Projectri reads these tools by itself.** A registered server sits idle until something calls it. ## Limits and gotchas - **The circuit breaker cuts a server off after five consecutive failures.** The health line distinguishes *failing* — still retrying, with the number of failures left before the cut-off — from *cut off*, which resumes only at the stated time. They need opposite actions, so they are never collapsed into one message. - **You cannot set a server to Active or Failed.** Those are conclusions the discovery and call paths draw. The only statuses you may assert are **Pending** and **Disabled**. - **The credential is write-only throughout.** Leave the box blank when editing to keep the stored one. - A server registered but never discovered shows as *Registered, but its tools have never been discovered* — that is a normal state on the way to working, not a fault. - The endpoint has to be publicly reachable. An internal address is refused at registration, which is the same guard that stops the console being turned into a request forger. ## On mobile This screen is web only. ## Related - [Integrations](/docs/admin/integrations) — the connectors Projectri wrote. - [Automation](/docs/admin/automation) — the rules that call these tools. - [Security](/docs/admin/security) — Connect IDE, the inbound half of MCP. - [MCP and the API](/docs/features/mcp-and-api) — both directions explained. ## Related - [Integrations](https://projectri.com/docs/admin/integrations.md): Connect this workspace to the tools you already use, see which connections are healthy, and find the third-party applications somebody has authorised. - [Automation](https://projectri.com/docs/admin/automation.md): Rules that react to what happens in this workspace — a trigger, optional conditions, and an ordered flow of actions, waits and branches. - [Security](https://projectri.com/docs/admin/security.md): The sign-in rules this workspace enforces, who is signed in, what machine credentials and outside applications can reach it, and the sign-in history. - [The API, MCP and connected apps](https://projectri.com/docs/features/mcp-and-api.md): Three ways software reaches a Projectri workspace — the REST API, the MCP server for coding agents, and third-party apps a member authorises.