MCP Servers

An MCP server is an addressable endpoint that MCP clients connect to. Each server has exactly one backend, and the backend decides where its tools come from.

Everything layered above the backend works the same way, whichever backend a server uses. Tools, authentication, upstream credentials, visibility, custom domains, publishing to collections, team access, and tool logs are properties of the MCP server, not of the thing behind it.

Access requirements

Viewing MCP servers requires the mcp:read or mcp:write scope. Creating a server and editing its settings, visibility, authentication, tool filtering, or team access requires the mcp:write scope. Publishing a server to a collection requires the org:admin scope. The default Admin role has full access. The default Member role has mcp:read, so Members can view MCP servers but cannot create, edit, or publish them.

The server list

The MCP page lists every server in the project, in two sections. Open it from Distribute > MCP in the dashboard.

Hosted MCP Servers lists every source exposed as an MCP server: OpenAPI-backed, functions, catalog servers, and custom remote MCP alike. A card view and a table view are both available, with columns for name, visibility, URL, and tools. Search and filters narrow the list, including a filter for servers included in plugins. New MCP Server creates a server.

Built-in MCP Servers lists platform-provided servers such as MCP Logs. Any MCP client can connect to these.

Opening a server shows its detail page. The sidebar carries the MCP URL with a copy button and a link to the hosted installation page, which lists per-client setup instructions. For client-specific walkthroughs, see the setup guides.

Choosing a backend

New MCP Server asks for a backend first:

• Remote — the server points at an MCP server that someone else runs. The Control Plane registers the URL and proxies whole MCP sessions to it.
• Tunneled — the server points at an MCP server that runs inside a private network. A tunnel agent dials out to the Control Plane, so the private server gets a hosted URL without any inbound connectivity.
• Built — the Control Plane generates the server itself from a first-party source: an OpenAPI document or a TypeScript Functions project.

The three are mutually exclusive, and the database enforces it. A server cannot proxy a remote URL and serve built tools at the same time, and the backend is fixed when the server is created.

Situation	Backend	Start here
A vendor already runs an MCP server and it needs governance, auth, and logging	Remote	Remote MCP servers
An MCP server already exists but runs behind a firewall or inside a VPC	Tunneled	Tunneled MCP servers
No MCP server exists yet, but an OpenAPI document or a TypeScript codebase does	Built	Building MCP servers

Tools on a server

The Tools tab curates exactly which tools a server exposes.

Where that tool list comes from depends on the backend, and the two answers are opposites. Built servers capture their tool list once per deployment. Remote and tunneled servers proxy tools/list live. The difference decides how changes propagate and which tool-shaping features apply to which backend, so How tools appear on a server covers it in full.

Tag-based tool filtering shapes what a client sees. It lets a client connect to a focused subset of the tools on a server by selecting tags at install time.

The Resources and Prompts tabs hold the other MCP capabilities a server serves.

Authentication

Authentication answers two questions that are configured independently and are easy to confuse:

• Who is calling this MCP server? User sessions answer this. The Control Plane acts as the authorization server and issues tokens to MCP clients.
• Which credential does the server use upstream? Upstream credentials answer this, either per end user through remote identity providers, or with one shared credential for every caller.

The Authentication tab configures both. See Authentication for how the two fit together.

A toolset-backed server can also authenticate against an authorization server outside the Control Plane. Secure with OAuth covers the OAuth credential styles those servers accept, and Build MCP with external OAuth covers pointing clients at a third-party authorization server.

Distribution

The Settings tab controls how a server reaches the people who use it:

• Visibility — disabled, private, or public. A private server requires an authenticated caller. A public server accepts anonymous callers, and public visibility is available only on a tunneled backend, and only after the tunnel source owner opts in.
• Custom Slug and Custom Domain — control the URL of the server
• Publishing — organization admins publish servers to collections, so others in the organization can discover and install them

Making a server public does not strip its credentials. A public server still serves its attached system environment variables and upstream headers on every call, which means anonymous callers spend the same API keys an authenticated caller would. See Upstream credentials.

The Settings tab also holds Server Instructions, the instructions returned to LLMs when they connect, an Export JSON action for the MCP configuration, and a danger zone for disabling or deleting the server.

Team access

The Team Access tab shows who can use the server: every member with their role and read, write, and connect access levels. Access derives from role grants scoped to the server, down to individual tools, where a member’s badge opens the exact tool list they can use. Roles are configured in the roles and permissions settings for the organization.

Monitoring

The Overview tab reports tool calls, failed calls, error rate, and average latency against the previous period. It also charts tool call trends, ranks top tools by calls and by failure rate, and lists top users.

Tool logs records the individual calls behind those numbers, across every server in the project.