# Share a remote MCP server with a static credential

Some upstream MCP servers authenticate with a single API key or token instead of a per-user sign-in. Putting that key on a remote MCP server lets everyone who connects call the upstream with it, so the server becomes a live credential.

This guide adds a remote MCP server by URL, attaches a static credential to it in **Manual** mode, and then narrows **Team Access** so only the people entitled to that credential can connect. The last step is not optional: until it is done, anyone the server's access rules reach can act upstream as the credential's owner.

## Access requirements

> Adding the server requires the `mcp:write` scope. Changing who can reach it on the **Team Access** tab requires `org:admin`. See [Roles and permissions](/docs/ai-control-plane/org-admin/roles-and-permissions).

## Add the remote MCP server by URL

Open **MCP** in the sidebar and choose **Add new**. On the **Add MCP server** page, choose **Hosted remotely**.

The **New remote MCP server** form takes an optional **Display name** and the **MCP server URL**. Choose **Verify connectivity** to probe the URL with an MCP `initialize` request. Verification checks that the server is reachable and speaks MCP, not that a credential works, so an upstream that answers with an authorization challenge still verifies.

After verification, the form shows an **Identity** choice. Pick **Manual**, then choose **Save**. The credential is added in the next step, from the server's settings.

> When the upstream answers with an authentication challenge, the form warns that Manual may leave the server unable to serve requests. That is expected here: the static credential added in the next step is what lets requests through.

[Remote MCP servers](/docs/ai-control-plane/mcp-gateway/remote-servers) covers the rest of what registering a server sets up.

## Add a static credential in Manual mode

Open the server's **Settings** tab and find the **Identity** section. Confirm **Manual** is selected. In Manual mode, Speakeasy manages no identity for the server and sends whatever upstream headers are configured.

Expand **Custom Headers** and choose **Add header**:

- Set **Header name** to the header the upstream expects the key in, such as `X-API-Key`.
- Set **Value source** to **Static value** and paste the key into **Value**.
- Check **Secret** to mark the value as a secret.

Choose **Save** at the bottom of the section. The header is now sent upstream on every request, for every caller.

> When the upstream expects the key in the `Authorization` header, choose **Service Account** instead of **Manual**. It stores the same kind of shared credential in **Service Account credential**, with a **Bearer**, **Basic**, or **Manual** format, and the section shows it as a Service Account either way.

The header is stored on the remote MCP source, not on the MCP server. When other MCP servers use the same source, the section names them and warns that the change applies to all of them, so restrict each of those servers in the next step too.

[Upstream credentials](/docs/ai-control-plane/mcp-gateway/access/upstream-credentials) compares a shared credential with credentials per end user.

## Limit Team Access to the people who can use the credential

> **Important**
> This server now carries a live credential. Until access is narrowed, everyone its access rules reach can call the upstream as the credential's owner. Restrict **Team Access** before sharing the server's URL.

A static credential carries the permissions of whoever issued it, not of the person calling the tool.
Open the server's **Team Access** tab. The **Manage access to this server** list shows every rule that reaches the server, including organization-wide rules such as **Everyone** or a role that covers every server.

### Grant the intended people first

Choose **Grant access**, then **Person**, and add each person allowed to use the credential. Granting by name matters: access given to a person on this server outranks a block on a role or on **Everyone**, so these people keep the server when the broad rules are removed next.

Roles can be granted the same way with **Grant access**, then **Role**. Only access given by name outranks a block, so when granting a role, avoid blocking **Everyone** and remove the broader roles one by one instead.

### Remove everyone else

For each broader row, such as **Everyone** or a role that should not have the server, choose the remove (trash) icon on the row, then **Remove** in the confirmation. When the rule covers every server, removing it writes a block for this server only, and every other server is untouched. The confirmation lists anyone who keeps the server because they were given it by name.

To keep someone able to see the server in the catalogue without calling it, set **Connect** to **No access** on their row instead of removing it.

> The Admin role cannot be blocked from a server. Organization administrators keep access, and they can already change the credential from **Settings**.

### Check the result

Use **Check a person's access** below the list to confirm that someone outside the intended group cannot connect. If a **Conflicting roles** section appears, it lists people who are granted the server by one rule and blocked by another.

[Team access](/docs/ai-control-plane/mcp-gateway/access/team-access) covers every option on the tab, including narrowing a grant to specific tools.

## Rotate or remove the credential

To rotate the key, edit the header's **Value** under **Custom Headers** and choose **Save**. Callers pick up the new value on their next connection. To stop authenticating upstream, delete the header row and save.

---

Index of every Speakeasy page for agents: [llms.txt](https://www.speakeasy.com/llms.txt). AI control plane and MCP gateway content in one file: [llms-full.txt](https://www.speakeasy.com/llms-full.txt). Any page is available as markdown by appending `.md` to its URL or by requesting it with `Accept: text/markdown`.
