Get started

Gateway

One URL for all your MCP servers.

A hub is the address you paste into Claude, ChatGPT, Cursor or your own agent. It signs clients in with OAuth 2.1, applies a policy per client and forwards every call to the right server — without the traffic ever leaving the hub's region.

Create a hub
→https://mx.gw.runscale.dev/8a92fe32/backoffice/mcp

1

URL per hub, however many servers sit behind it

OAuth 2.1

PKCE, dynamic registration, RFC 8414 / 9728 discovery

0

network hops to validate a token: JWT checked in-region

~1 min

for a policy change to reach the hub, no new token needed

Three commands from servers to a connector

Or the same three clicks in the dashboard.

  1. 01

    Create the hub

    $ runscale hubs create backoffice --region mx

    Pinned to a region at creation. Only servers of that region can join — the residency promise survives the gateway.

  2. 02

    Add servers

    $ runscale hubs add backoffice crm

    Internal servers get a platform token automatically, sealed with your organisation's key. External MCP endpoints join with their own bearer.

  3. 03

    Connect a client

    $ runscale connect backoffice

    Prints the URL. Paste it as a remote MCP server; the client registers itself, sends you to the consent screen and gets its tokens.

$_your-terminal — runscale hubs
❯ runscale hubs create backoffice --region mx
hub backoffice created in aws-mx-central-1
endpoint: https://mx.gw.runscale.dev/8a92fe32/backoffice/mcp
 
❯ runscale hubs add backoffice crm
backoffice ← crm (crm)
❯ runscale hubs add backoffice docs
backoffice ← docs (docs)
 
❯ runscale connect backoffice
https://mx.gw.runscale.dev/8a92fe32/backoffice/mcp
 
add this URL as a remote MCP server / custom connector in your client.
it will register itself, send you to the Runscale consent screen, and get a token.

Access

Two ways in, one policy.

People connect through OAuth: their client registers itself, a member of your organisation approves it on the consent screen, and a signed token comes back. Scripts and CI use a static token. Both resolve to a client id, and the policy is applied per client.

  • OAuth 2.1 with PKCE, S256 only
  • Rotating refresh tokens with reuse detection
  • Static mcph_… tokens for automation
  • Consent lists exactly the tools the client will get
TOMLpolicy · client cli_IIdkt38w…
allow = ["crm__*", "docs__search"]deny  = ["crm__delete_*"]rate_limit_per_minute = 60daily_quota = 5000max_argument_bytes = 65536

Policy

Say what each client may call.

Globs over the published tool names, deny winning over allow, plus a rate limit and a daily quota. A hub starts by denying everything; tools/list only shows what a client can actually use, so the model never wastes context on the rest.

  • Allow / deny globs like crm__*
  • Calls per minute and per day
  • Argument size cap per call
  • Takes effect within seconds, no redeploy
{}trace · mx-central-1
{  "ts": "2026-09-06T21:41:07.113Z",  "hub": "backoffice",  "client_id": "cli_IIdkt38wlxgLX2YJz6qDWlXu",  "sub": "usr_…",  "tool": "crm__search",  "server": "crm",  "status": "ok",  "duration_ms": 184,  "argument_bytes": 61,  "result_bytes": 2310}

Residency

The hub lives where the servers live.

The authorization server is one; hubs are per region. Tokens carry the hub as audience and are verified locally against the published keys. Traces — who called which tool, how long, how big — are written in the hub's region. Payloads are off by default.

  • Region-pinned hubs, region-pinned servers
  • Configuration pushed to the region, never pulled from Mexico
  • Per-call traces, in-region
  • Upstream credential is a normal, revocable token

Built for the clients people actually use

The gateway implements the authorization flow the Model Context Protocol specification defines for remote servers: OAuth 2.1 with PKCE, protected-resource and authorization-server metadata, and dynamic client registration. That is what Claude.ai, ChatGPT, Claude Desktop and the desktop editors speak when you add a remote MCP server.

Claude.ai, ChatGPT, desktop apps
Paste the hub URL as a custom connector. OAuth does the rest; no keys to copy.
Cursor, SDKs, agents
Either OAuth or a static token in the Authorization header.
Scripts and CI
A static token with its own policy. Revocable from the dashboard.
External MCP servers
A hub can also aggregate servers you host elsewhere: bring the URL and its bearer.

Questions

Does it replace my servers' own tokens?

No. Servers keep their access tokens. The hub authenticates against a server with a token of its own — labelled 'platform: gateway', visible and revocable like any other — so there is no second way into a server.

Can a token for one hub be used on another?

No. Each access token carries the hub URL as its audience and is only valid there, even for hubs of the same organisation.

Who can approve a client?

A member of your organisation, signed in to the dashboard. External users by invitation and federation with your identity provider come next.

What does the hub see of my data?

By default only metadata per call: client, tool, server, duration and sizes. You can turn on payload tracing per hub; those traces stay in the hub's region, capped per record.

What does it cost?

Included in early access. When billing turns on, hub calls are metered like server invocations.

Which regions?

Mexico (Central) today. US East follows with the same engine.

Give your MCP servers one door.

Create a hub, add a server, paste the URL into your client.

Create a hub Read the spec in docs