MCP Gateway / Managing an MCP server
Managing an MCP server
Set an MCP server's visibility, address, and network access, distribute it through plugins, and manage team access, guardrails, sessions, and monitoring from the server page.
Once a server exists, everything about how it is reached and governed lives on its server page. Open a server from MCP Gateway > MCP in the project sidebar. This page follows the server page from the status control through each tab: Overview, Settings, Team Access, Guardrails, and Clients and Sessions.
Tool tabs differ by server type. A hosted server has a Tools tab, covered in Curating tools. A remote or tunneled server has an Inspect tab, covered in Recording tool metadata.
Access requirements
Section titled “Access requirements”Viewing a server requires the mcp:read scope. Changing its visibility, settings, or plugin membership requires mcp:write. Changing rules on the Team Access tab requires org:admin. See Roles and Permissions.
Visibility
Section titled “Visibility”Visibility decides whether a server serves traffic at all and to whom. Set it from the status control on the server page:
- Disabled: the server is offline and nobody can connect.
- Private: the server serves authenticated callers.
- Public on a hosted server: anyone with the URL can read the tools, but using them still requires authentication. Managed OAuth in front of a hosted server requires it to be public. See Secure with OAuth.
- Public on a tunneled server: anyone can connect anonymously, and every tool is exposed to the public internet. The option unlocks only after the tunnel source owner turns on public access in its Settings. See Public visibility.
Remote servers cannot be made public.
Making a server public does not strip its credentials. A public server still sends its attached system environment variables and upstream headers on every call, so anonymous callers spend the same API keys an authenticated caller would. See Upstream credentials.
Overview tab
Section titled “Overview tab”Monitoring
Section titled “Monitoring”The Overview tab reports tool calls, failed calls, error rate, and average latency against the previous period, with top tools and top users. A tunneled server also shows its live connections, and a hosted server has a separate Performance tab.
Each tool call is attributed to the MCP client that made it, using the name and version the client reports when it connects. That separates Claude Code acting for a person from Cursor acting for the same person, both here and in Tool Logs, which records the individual calls across every server in the project. Calls without a client handshake are grouped as unattributed.
Distribution
Section titled “Distribution”Every server has a copyable MCP URL and an installation page with setup instructions for each client, linked from the MCP Installation section of the server page. Share the installation page directly, or distribute the server through plugins.
A server reaches teammates’ AI clients and other projects by joining a plugin. Publish or update plugin membership from the Overview tab. Enabling a disabled server adds it to the default plugin automatically. Roll out MCP servers to a team with plugins walks through a role-based rollout end to end.
Settings tab
Section titled “Settings tab”Authentication
Section titled “Authentication”Authentication settings sit in different sections depending on the server type: the Authentication section on a hosted or tunneled server, and the Identity and Sessions sections on a remote server. Changes take effect on new connections. See Where authentication is configured.
A hosted server attaches an environment from the Environment Variables section to supply upstream secrets.
Addresses
Section titled “Addresses”A server can use a custom slug or a custom address on a domain an organization admin has verified under Custom Domains. One address per domain can serve as the domain root.
Network access
Section titled “Network access”A remote or tunneled server can serve through public routes, the organization private network, or both. Switching to private only stops the public URLs, and the dashboard lists them before the change is confirmed. Private endpoints have their own installation page for organization admins. Network access is separate from visibility and authentication. See Tailscale for setup.
Other settings
Section titled “Other settings”The Settings tab also holds:
- The instructions returned to agents when they connect. On a hosted server, draft them by hand or with Generate with AI.
- The icon and display name shown on the installation page, on a remote or tunneled server.
- An export of the MCP configuration as JSON, on a hosted server.
- The delete action.
A tunneled server has further sections for its tunnel. See Other settings.
Team Access tab
Section titled “Team Access tab”The Team Access tab controls who can connect to the server, see it in the catalog, and manage it. Rules name everyone, a role, a person, an agent, or, once an identity provider is connected, a directory group or attribute. They share one model with the organization-wide role editor. See Team access for how grants, blocks, and tool narrowing combine.
Guardrails tab
Section titled “Guardrails tab”The Guardrails tab lists the risk policies that inspect the server’s tool requests and tool responses, with the server’s recent risk events. Guardrails are MCP-scoped policies: the gateway evaluates them on every call, whichever client makes it, and can block a call before it reaches the server or withhold a result before it reaches the client. See Guardrails for adding one from a server.
Clients and Sessions tab
Section titled “Clients and Sessions tab”The Clients and Sessions tab shows who is connected, which clients they use, and the upstream providers the platform reaches on their behalf. It also revokes individual sessions or whole client registrations. See Clients and sessions.