Identity and MCP governance / Share a remote MCP server with a static credential
Share a remote MCP server with a static credential
Add a remote MCP server by URL, give it a static upstream credential in Manual mode, and limit Team Access to the people allowed to use that 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
Section titled “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.
Add the remote MCP server by URL
Section titled “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 covers the rest of what registering a server sets up.
Add a static credential in Manual mode
Section titled “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 compares a shared credential with credentials per end user.
Limit Team Access to the people who can use the credential
Section titled “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
Section titled “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
Section titled “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
Section titled “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 covers every option on the tab, including narrowing a grant to specific tools.
Rotate or remove the credential
Section titled “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.