MCP servers
This page complements MCP Servers in XTM One.
That guide explains what MCP servers are for. This page gives you a quick tour of the MCP server screens.
The list page
In the left navigation, this area is MCP Servers. The list page is built for quick scanning: search by name, command, or URL, and filter by visibility or tags. Each card answers two questions at a glance — is the server likely usable right now (enabled or disabled, transport type), and what kind of setup sits behind it (subprocess vs. HTTP, whether OAuth or environment variables are involved) if something goes wrong later. If you have permission, Add Server exposes a new external toolset.
The detail page
Opening a server shows a header with its name, transport, enabled state, and OAuth status when relevant. Test Connection is the main action — try it first after any setup or credential change, because it tells you whether the problem is the server connection itself or something later in the agent workflow. The page is organized into Overview, Configuration, and Activity tabs.
Overview
Overview shows whether the server is meaningfully ready: how many tools it discovered, how often they are called, its connection details, and which agents depend on it.
Configuration
Configuration is the most operationally important screen. It covers the server's identity and connection (transport, command or URL, environment variables or headers) and its visibility and sharing. You can switch transport directly here between subprocess (stdio), Streamable HTTP, and SSE.
The same screen holds the discovered tools card, where you discover or refresh the server's tools, read each tool's description, and test an individual tool. This matters because most MCP questions are not about the server object itself — they are about whether the expected tool is actually visible and callable. When the server uses OAuth, an OAuth connection card shows whether it is configured but not yet authenticated, with an authorize or re-authorize action. On a company-managed server that action is admin-only, because the resulting connection is a single shared one — every user of the platform calls the server through the token the admin authorized, just as they all share its API key when it authenticates with headers.
Activity
Activity is the traceable history — whether the server changed recently, whether calls were made, and whether an issue started after an edit.
Shared, company, and read-only states
Ownership rules shape these pages: private servers are editable by their owner, shared servers are reused across group members, and company-managed servers are visible more widely but read-only for non-admins. Testing may be available even when editing is not.
Good habits
- Use
Test Connectionbefore troubleshooting the agent itself. - Refresh discovered tools after changing transport or credentials.
- Read the discovered tool list, not just the server name.
- Notice the difference between a configured server and an OAuth-connected one.