> ## Documentation Index > Fetch the complete documentation index at: https://docs.xpander.ai/llms.txt > Use this file to discover all available pages before exploring further. # MCP gateway > xpander's MCP surface in both directions: clients reaching agents and Omni over MCP, and skills served over MCP registered once for the organization, including endpoints behind an MCP gateway you already run. The `api` service is xpander's REST and MCP entry point for external clients. It fronts the Agent Controller. REST calls carry an API key. The MCP endpoint takes OAuth 2.1 only, on every deployment. Skills served over MCP go the other way: an admin registers the endpoint once, and agents reach it through xpander with the same approvals, credentials and record as any other skill. ## Inbound: clients reach xpander over MCP | Endpoint | Auth | What it exposes | | ----------------------------------------------------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `https://api.xpander.ai/mcp/` (self-hosted: `https://api./mcp/`) | OAuth 2.1 | The xpander API itself, control plane and data plane, exposed over MCP: agents, tasks and threads, skills and their operations, custom functions, workspace files, schedules, usage. It is not an agent; each operation is one API call. Setup per client on [Model Context Protocol](/api-reference/mcp) | | `https://omni.xpander.ai/mcp` (self-hosted: `/omni-mcp/`) | OAuth 2.1 in the browser | Omni, the built-in agent, as one endpoint for everything you can do through Xpander Chat and Omni: find and task the organization's agents, assemble skills and agents from what your admins approved, start cloud sessions, ask what a run did. Setup on [Connect your MCP client](/guides/deploy/omni-mcp) | The sign-in is the same on every deployment. A call without a token gets `401` with `WWW-Authenticate: Bearer resource_metadata=.../.well-known/oauth-protected-resource`. The client registers itself at `/oauth/register`, sends the person to `/oauth/authorize` with PKCE, exchanges the code at `/oauth/token`, and calls `/mcp/` with `Authorization: Bearer `. An `x-api-key` header gets the same `401`. On a self-hosted install the Omni endpoint is the install's own public MCP URL, `global.mcp.publicUrl` in the chart (rendered to `OMNI_MCP_URL`). Until that value is set, `/omni-mcp/` answers `404`, Settings > Channels lists **MCP** as **Not configured on this install**, and the License page's Capabilities card shows the same **MCP endpoint** capability as **Disabled**. There is no separate **MCP** switch on an agent's Channels pane; only **Omni** and **API** appear there, so the organization's channel switch is what governs whether the channel is offered. See [Channels](/use/agents/channels). The agents endpoint needs one value of its own. `/oauth/authorize` redirects the browser to `${APP_URL}/oauth_login`, read from the `api` service's environment, so `APP_URL` must be the UI origin. With `APP_URL` on the API host the browser lands on `{"detail":"Not Found"}`. The chart keys are on [Model Context Protocol](/api-reference/mcp#self-hosted-installs). ## Outbound: skills served over MCP **Settings > MCP registry** holds two lists. **Organization servers** are shared with every agent in the organization; admins and each entry's creator can edit them. **Your personal servers** are visible only to you, including endpoints registered on their own when you signed in to one from chat. The registry keeps one canonical identity per endpoint, deduplicates by name, shows a health indicator per row and a badge for endpoints that support dynamic client registration. A local stdio entry (a `uvx ...` command) is accepted on Air-Gapped too. Once registered, an endpoint appears under **Add skill** on any agent like a catalog skill, and its actions can be marked to wait for approval. MCP registry page with an Organization servers table holding one local stdio entry and an empty Your personal servers list **Add server** in the registry, or **Custom skill > MCP Connector** on an agent, opens the dialog titled **Connect an MCP server**. Its fields: * **Name** * **Server type**: **Remote** or **Local** * **Server URL** * **Transport**: **HTTP** or **SSE** * **Authentication**: **None**, **API key**, **OAuth2** or **Headers**; a header row's key defaults to `Authorization` * **Add to organization registry**: a switch that files the entry under **Organization servers** * **Add skill**: the button that creates the skill Step by step on [Add a skill](/connectors/add-a-skill). With OAuth, each person can authorize their own account, so the agent acts with that person's permissions where the system allows; a token can be shared across the agents a person uses. Setup and the flow are on [whose credential a shared agent uses](/use/agents/permissions#whose-credential-a-shared-agent-uses). Remote endpoints are reached over HTTP or SSE; local stdio servers run inside the agent's workspace and are tested at save time. On the API, `GET /{org}/mcp_registry/list` returns the registry. Add server dialog in the MCP registry ## An MCP gateway you already run Register the gateway's endpoints in the MCP registry. Every skill behind them is then reached through xpander, so the gateway's own policy and xpander's approvals, credentials and record both apply to the calls xpander agents make. Calls the gateway receives from other clients stay outside xpander's controls. The gateway must be reachable from the cluster's pods, not only from the browser. ## Verify ```bash theme={"dark"} kubectl -n xpander port-forward service/xpander-mcp 8081:8081 & curl http://localhost:8081/health ``` Runs that arrive through MCP are tagged with their origin in Task Manager, for example "MCP - Claude".