Empezar

Gateway

Una URL para todos tus servidores MCP.

Un hub es la dirección que pegas en Claude, ChatGPT, Cursor o tu propio agente. Autentica a los clientes con OAuth 2.1, aplica una política por cliente y reenvía cada llamada al servidor correcto, sin que el tráfico salga nunca de la región del hub.

Crear un hub
→https://mx.gw.runscale.dev/8a92fe32/backoffice/mcp

1

URL por hub, sin importar cuántos servidores haya detrás

OAuth 2.1

PKCE, registro dinámico, descubrimiento RFC 8414 / 9728

0

saltos de red para validar un token: el JWT se verifica en la región

~1 min

para que un cambio de política llegue al hub, sin token nuevo

Tres comandos de tus servidores a un conector

O los mismos tres clics en el dashboard.

  1. 01

    Crea el hub

    $ runscale hubs create backoffice --region mx

    Fijado a una región al crearse. Solo pueden unirse servidores de esa región: la promesa de residencia sobrevive al gateway.

  2. 02

    Agrega servidores

    $ runscale hubs add backoffice crm

    Los servidores internos reciben un token de plataforma automáticamente, cifrado con la llave de tu organización. Los endpoints MCP externos entran con su propio bearer.

  3. 03

    Conecta un cliente

    $ runscale connect backoffice

    Imprime la URL. Pégala como servidor MCP remoto; el cliente se registra solo, te lleva a la pantalla de consentimiento y recibe sus tokens.

$_tu-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.

Acceso

Dos formas de entrar, una política.

Las personas entran por OAuth: su cliente se registra solo, un miembro de tu organización lo aprueba en la pantalla de consentimiento y recibe un token firmado. Scripts y CI usan un token estático. Ambos resuelven a un id de cliente, y la política se aplica por cliente.

  • OAuth 2.1 con PKCE, solo S256
  • Refresh tokens rotativos con detección de reuso
  • Tokens estáticos mcph_… para automatización
  • El consentimiento lista exactamente las tools que recibe el cliente
TOMLpolítica · cliente cli_IIdkt38w…
allow = ["crm__*", "docs__search"]deny  = ["crm__delete_*"]rate_limit_per_minute = 60daily_quota = 5000max_argument_bytes = 65536

Política

Di qué puede llamar cada cliente.

Globs sobre los nombres publicados de las tools, denegar gana sobre permitir, más un rate limit y una cuota diaria. Un hub arranca denegando todo; tools/list solo muestra lo que un cliente puede usar de verdad, así el modelo no gasta contexto en el resto.

  • Globs de permitir / denegar como crm__*
  • Llamadas por minuto y por día
  • Tope de tamaño de argumentos por llamada
  • Surte efecto en segundos, sin redeploy
{}traza · 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}

Residencia

El hub vive donde viven los servidores.

El servidor de autorización es uno; los hubs son por región. Los tokens llevan el hub como audiencia y se verifican localmente contra las llaves publicadas. Las trazas, quién llamó qué tool, cuánto tardó, cuánto pesó, se escriben en la región del hub. Los payloads van apagados por defecto.

  • Hubs fijados a región, servidores fijados a región
  • Configuración empujada a la región, nunca consultada desde México
  • Trazas por llamada, en la región
  • La credencial hacia el servidor es un token normal y revocable

Hecho para los clientes que la gente usa de verdad

El gateway implementa el flujo de autorización que la especificación del Model Context Protocol define para servidores remotos: OAuth 2.1 con PKCE, metadata de recurso protegido y de servidor de autorización, y registro dinámico de clientes. Es lo que hablan Claude.ai, ChatGPT, Claude Desktop y los editores de escritorio cuando agregas un servidor MCP remoto.

Claude.ai, ChatGPT, apps de escritorio
Pega la URL del hub como conector personalizado. OAuth hace el resto; no hay llaves que copiar.
Cursor, SDKs, agentes
OAuth o un token estático en la cabecera Authorization.
Scripts y CI
Un token estático con su propia política. Revocable desde el dashboard.
Servidores MCP externos
Un hub también puede agregar servidores que alojas en otro lado: trae la URL y su bearer.

Preguntas

¿Sustituye los tokens de mis servidores?

No. Los servidores conservan sus tokens de acceso. El hub se autentica contra un servidor con un token propio, etiquetado 'platform: gateway', visible y revocable como cualquier otro, así que no hay una segunda puerta a un servidor.

¿Un token de un hub sirve en otro?

No. Cada token de acceso lleva la URL del hub como audiencia y solo vale ahí, incluso entre hubs de la misma organización.

¿Quién puede aprobar un cliente?

Un miembro de tu organización con sesión en el dashboard. Los usuarios externos por invitación y la federación con tu proveedor de identidad vienen después.

¿Qué ve el hub de mis datos?

Por defecto solo metadatos por llamada: cliente, tool, servidor, duración y tamaños. Puedes encender la traza de payloads por hub; esas trazas se quedan en la región del hub, con tope por registro.

¿Cuánto cuesta?

Incluido en el acceso anticipado. Cuando se active el cobro, las llamadas al hub se miden como invocaciones de servidor.

¿Qué regiones?

México (Central) hoy. EE. UU. Este sigue, con el mismo motor.

Dale una sola puerta a tus servidores MCP.

Crea un hub, agrega un servidor, pega la URL en tu cliente.

Crear un hub Lee el spec en docs