Saltar al contenido principal
Quieres que tus agentes usen un servidor Model Context Protocol (MCP) — tu propio servidor remoto, o el incluido — pero quieres que cada llamada a herramienta que expone se ejecute detrás de un único punto de estrangulamiento auditado. El primer paso es registrar el servidor en tu espacio de trabajo: un nombre, un endpoint, un modo de autenticación y sus credenciales. Una vez registrado, el gateway MCP anuncia sus herramientas bajo una conexión y evalúa cada tools/call a través de tu política de firewall antes de que llegue al servidor real. Esta página cubre esa única tarea — conectar y configurar un registro de servidor. Para el comportamiento en tiempo de ejecución del gateway y los veredictos por llamada, ver la referencia de MCP; para el panorama más amplio, empieza en el Resumen de seguridad de MCP.
El registro es una acción de consola (las rutas /api/workspace/firewall/* se autentican con tu token de sesión / acceso, no con una clave de relay sk-orca-…). Las escrituras requieren el rol Developer+; cualquier miembro puede listar servidores.

​
1. Cómo conectar un servidor MCP

Abre Firewall → MCP Servers en la consola y añade un servidor, o llama a la API del espacio de trabajo directamente. Un registro lleva cuatro cosas que importan:

name

Único por espacio de trabajo. Se convierte en el prefijo del espacio de nombres <server>.<tool>, así que un nombre duplicado en el mismo espacio de trabajo se rechaza con HTTP 409.

endpoint

La URL de tu servidor MCP remoto. Déjalo vacío para registrar el servidor incluido en proceso, así es visible y gobernable.

auth_mode

Cómo se autentica el gateway a tu servidor: none, bearer, oauth o basic.

credentials

El secreto específico del modo. Almacenado cifrado en reposo y enmascarado en lectura — nunca llega al modelo ni al cliente.
Un servidor empieza enabled y se elimina del gateway por completo en el momento en que lo deshabilitas — ese es el interruptor de apagado, y las credenciales de un servidor deshabilitado nunca se descifran.

​
2. Un ejemplo concreto

Registra un servidor MCP de GitHub remoto con un token bearer. Esta es una llamada REST equivalente a la consola; los nombres de campo son exactamente lo que escribe el formulario. 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
La forma de la credencial depende de auth_mode:
{"token":"…"} — enviado como un token bearer a tu servidor.
{"access_token":"…"} — un token de acceso estático que el gateway envía como una cabecera bearer. El intercambio automático de client-credentials aún no está soportado; sin un access_token almacenado, un sondeo en modo oauth falla en vez de conectarse sin autenticar.
{"username":"…","password":"…"}.
Una cadena vacía. No se adjuntan credenciales.
En lectura, tanto la credencial como el endpoint están enmascarados — la API devuelve marcadores centinela, no los valores en bruto. Cuando actualizas un servidor, haz eco de esos marcadores sin cambios para mantener los valores almacenados; envía un auth_json fresco solo cuando realmente estés rotando el secreto. Ver rotación de credenciales.

​
3. Sondea su salud

Antes de poder escribir reglas de firewall contra las herramientas de un servidor, necesitas saber que son alcanzables y cómo se llaman. Sondea el servidor — el gateway ejecuta un handshake MCP initialize + tools/list usando las credenciales descifradas, registra la alcanzabilidad y devuelve las herramientas anunciadas: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-or-access-token>"

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": {} }
  ]
}
El status aterriza en el registro del servidor e impulsa el indicador de salud:
statusSignificado
okAlcanzable; las herramientas son servidas por el gateway.
degradedAlcanzable, pero el handshake fue parcial.
downInalcanzable en el último sondeo; el servidor se omite.
Un servidor down se deja fuera cuando el gateway construye su conjunto de herramientas, así que una interrupción transitoria se degrada con elegancia en vez de romper el despacho. Un sondeo devuelve su resultado independientemente del desenlace — un sondeo fallido vuelve como 200 con status: down y una razón depurada, no un error de transporte.
El servidor incluido en proceso (endpoint vacío) despacha localmente y no es sondeable — sondearlo se rechaza con un error que explica que el registro no tiene endpoint. Solo sondeas servidores BYO que tienen una URL.
Cada cambio de registro invalida la caché de herramientas por espacio de trabajo del gateway inmediatamente, así que un servidor recién conectado, deshabilitado o resondeado surte efecto en la siguiente conexión en vez de tras una ventana de caché.

​
4. Después de conectado

Una vez que un servidor está registrado y sondeando ok, sus herramientas están gobernadas:
  • Cada llamada se evalúa. Cada tools/call se ejecuta a través de tu política de firewall en la superficie mcp antes de llegar a tu servidor. Acota reglas por tool_name_glob: github.* ahora que conoces los nombres de las herramientas.
  • Restringe la superficie. Por defecto deniega las herramientas que no permitiste explícitamente — ver lista de permitidos de herramientas MCP.
  • Gobierna dónde alcanza. Autora una regla de egress para que una herramienta no pueda obtener hosts arbitrarios.
  • Vigila los cambios. Un servidor en el que confiaste puede cambiar sus definiciones de herramienta después; la defensa contra rug-pull marca esa deriva.

​
5. Referencia de API

Todas las rutas de consola tienen alcance de espacio de trabajo y se autentican con tu token de sesión / acceso. Las lecturas de listas están abiertas a cualquier Member (secretos enmascarados); cada escritura requiere Developer+.
Método y rutaRolPropósito
GET /api/workspace/firewall/mcp_serversMemberLista servidores (secretos + endpoint enmascarados).
GET /api/workspace/firewall/mcp_servers/:idMemberUn solo servidor, enmascarado.
POST /api/workspace/firewall/mcp_serversDeveloper+Registrar un servidor (409 en nombre duplicado).
PUT /api/workspace/firewall/mcp_serversDeveloper+Actualizar un servidor (id en el cuerpo).
DELETE /api/workspace/firewall/mcp_servers/:idDeveloper+Eliminación suave; libera el nombre.
POST /api/workspace/firewall/mcp_servers/:id/probeDeveloper+Sondear alcanzabilidad + descubrir herramientas.
El proxy del SDK de un agente lee el registro en tiempo de ejecución sobre el token con alcance de gateway en GET /api/v1/firewall/mcp_servers (solo servidores habilitados). Para cómo autenticar ese lado, ver autenticar el gateway MCP.
¿Por qué conectar a través de OrcaRouter siquiera? Para que un solo lugar vea cada llamada a herramienta — una conexión, una política, un log auditado, y credenciales inyectadas en el despacho en vez de dispersas por las configuraciones de los agentes. Lee asegurar agentes de IA y la amenaza de envenenamiento de herramientas MCP para la motivación.

​
Relacionado

Resumen de seguridad de MCP

El modelo completo de gobernanza de MCP, de extremo a extremo.

Firewall: servidores MCP

El comportamiento en tiempo de ejecución del gateway y los veredictos por llamada.

Autenticar el gateway

Acuña y acota el token con el que se conecta tu agente.

Lista de verificación de confianza

Todo lo que verificar antes de confiar en un nuevo servidor.