> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nasiko.com/llms.txt
> Use this file to discover all available pages before exploring further.
# MCP gateway
> Register MCP servers, upload your own, and control which tools each agent may call.
The **MCP gateway** screen gives agents access to real tools — Gmail, Slack, GitHub, an internal API, or a server you wrote. Everything in the [CLI and API guides](/mcp-hub/overview) is available here as a form.
The page has three sections: **Connectors**, **My uploads** (once you have one), and **Agent access**.
Two header buttons:
* **Register connector** — point at an MCP server already running somewhere
* **Upload MCP server** — hand over source and let the platform build, harden, and run it
## Connectors
Lists everything available to you, including what teammates shared. A shared connector shows *shared by* and the owner's name.
| Column | What it shows |
| ------------- | ------------------------------------------------------- |
| **Connector** | Display name, with internal name underneath |
| **URL** | The server's address |
| **Transport** | Usually `streamable_http` |
| **Auth** | No auth, API key, Basic, OAuth 2.1, or URL param |
| **Tools** | How many tools it exposes |
| **Status** | Active, Inactive, or — for uploads — Building or Failed |
Click a row or the gear icon to open its detail panel. The trash icon appears only on connectors you own and asks to confirm, since deleting one removes its tools from every agent using it.
The sidebar splits the list three ways — **All**, **Created by you**, and **Shared with me** — and the **All** / **Connected** tabs filter each of those down to what you've connected a credential to. Each card shows the server's name, its tool count, and a connected badge.
## Registering an external server
**Name** is the internal identifier (`github`). **Display name** is what people see (`GitHub`) and is optional.
Paste the URL (e.g. `https://mcp.example.com/mcp`) and click **Probe**. The platform contacts the server, works out what authentication it expects, and selects the matching auth type with a hint explaining what it found.
Probing is optional. A failed probe usually means the URL is wrong or unreachable.
| Auth type | Fields |
| -------------------- | ------------------------------------------------------------------------------------- |
| **No auth** | none |
| **API key (bearer)** | Credential header — defaults to `Authorization` |
| **Basic auth** | Username and password |
| **OAuth 2.1** | Client ID and secret — leave blank if the server supports dynamic client registration |
| **URL parameter** | The parameter name, e.g. `api_key` |
Add an optional description and click **Register**. The connector appears immediately.
Custom MCP servers must be reachable at a public address. URLs resolving to private, loopback, link-local, or cloud-metadata addresses are rejected — checked at registration and on every connection.
### Connecting your credential
Registering doesn't sign you in. The connector's detail panel has a **Credential** section:
* Enter your API key or token and click **Save** (or **Replace**). If the platform stores it but can't verify it against the server, it tells you.
* **Remove** clears a stored credential.
The field never shows a saved value — credentials are write-only here.
OAuth 2.1 connectors get an **OAuth 2.1** section instead. **Authorize** opens your provider's consent screen in a popup; the panel then shows **Authorized** and the token expiry. **Revoke** disconnects.
Everyone using a shared connector connects with **their own** credential or OAuth grant. Sharing never hands over the owner's login.
## Uploading your own MCP server
**Upload MCP server** has two tabs:
* **Upload zip** — name, optional version tag (defaults to `v1`), and a `.zip` of your source
* **From GitHub** — name, version tag, and a repository URL
Your source needs a `Dockerfile` at its root, and your server should read `$PORT` and serve MCP over Streamable HTTP at `/mcp`. Full contract: [Deploy your own MCP server](/mcp-hub/internal-mcp-deployment).
**Queue build** returns the new connector's ID. The build runs in the background — close the modal and track it under **My uploads**.
### My uploads
Each row shows the connector's name, status (**Deploying**, **Active**, **Failed**), any error message, and the resolved endpoint. The terminal icon opens **Build logs** — the first place to look when a build fails.
Uploaded servers run third-party code, so they get extra hardening and network isolation. See [Deploy your own MCP server](/mcp-hub/internal-mcp-deployment).
## Toolkits
A catalog of pre-built integrations — Airtable, Asana, Bitbucket, ClickUp, Confluence, Discord, Dropbox, GitHub, GitLab, Gmail, Google Calendar, Google Drive, and more — each with its tool count and description. **All**, **Connected**, and **Available to connect** filter the grid; the **+** on a card connects it, and a tick marks the ones already connected.
## Agent access
Controls which connectors an agent may use, and which of their tools.
Pick an agent in the search box. You then get a table of every connector available to it:
* **Enabled** turns a connector on or off for that agent. Changes save on toggle — a failed save snaps the switch back and says why.
* **Tools** expands an inline editor listing every tool with its description and an **Allow** / **Deny** dropdown. Set what you want restricted, then **Save rules**.
Nothing needs configuring to *grant* access. A connector you can reach is usable by your agents by default. These controls only restrict.
A connector that hasn't reported tools yet is usually still starting up.
This screen sets Allow and Deny only. The API also supports an **ask** stance and glob patterns covering whole tool families — see [per-agent tool permissions](/onboarding/acl/user-agent-mcp).
## Related
Connectors, delegation tokens, and the request flow.
The same flow from the CLI and API.
What your source must provide.
The full permission model.