¿Qué es un servidor ERP MCP?

Un servidor que convierte un sistema en herramientas

El Protocolo de Contexto del Modelo tiene tres roles. Un anfitrión es una aplicación de IA como Claude o ChatGPT. Dentro del anfitrión, se crea un cliente por servidor y habla solo con ese servidor. Un servidor es un servicio que ofrece contexto y capacidades al anfitrión a través de un pequeño número de primitivas. Los principios de diseño de la especificación dicen que los servidores deben ser fáciles de construir, componibles y no deben poder ver toda la conversación ni otros servidores; el anfitrión mantiene la conversación y hace cumplir el consentimiento, el servidor solo ve las llamadas dirigidas a él.

Por lo tanto, un servidor ERP MCP no es el ERP. Es la superficie de acción del ERP, expresada como herramientas con entradas tipadas, servidas en una URL. La decisión de diseño interesante es qué es una herramienta. Un servidor meteorológico tiene una; un sistema de negocio tiene cientos, y las útiles son acciones que una persona podría realizar (crear una factura, registrar un pago, mover un trato, reservar stock) en lugar de filas en tablas. El servidor de espacio de trabajo de Sois, por ejemplo, publica herramientas con nombres como crear factura, registrarPago, searchContacts y examinarContacto agrupados por módulo, y la lista exacta que recibe un llamador depende de quién sea.

Herramientas, recursos y avisos

La especificación define tres primitivas de servidor, y difieren en quién controla su uso. Las herramientas son controladas por el modelo: el modelo decide cuándo llamar a una. Los recursos son impulsados por la aplicación: el anfitrión decide qué contexto adjuntar, a menudo con el usuario eligiendo de una lista. Los prompts son plantillas controladas por el usuario. Un ERP necesita la primera, puede beneficiarse de la segunda y rara vez necesita la tercera.

Dos características de los resultados de las herramientas son importantes para un sistema empresarial. Una herramienta puede declarar un esquemaDeSalida y devolver contenidoEstructurado que se ajuste a él, junto con el texto que un modelo lee, para que una integración pueda utilizar el resultado sin analizar prosa. Y una herramienta que falla por una razón empresarial (una factura en el estado incorrecto, una fecha en el pasado, un permiso faltante) devuelve un resultado normal con isError: true y una explicación, en lugar de un error de protocolo, para que el modelo pueda corregir su entrada y volver a intentarlo. Los errores de protocolo están reservados para solicitudes mal formadas y herramientas desconocidas.

El transporte y la especificación actual

Dos transportes son estándar. Stdio es para un servidor que el cliente lanza como un proceso local, que es cómo funcionan las herramientas de escritorio como el acceso a archivos. HTTP transmitible es para servidores remotos y es lo que utiliza un ERP: el servidor expone un punto final que acepta un HTTP POST por mensaje JSON-RPC y responde con un objeto JSON o un flujo de Eventos Enviados por el Servidor limitado a esa solicitud, de modo que una llamada larga puede enviar progreso antes de su resultado final. El transporte anterior de HTTP con SSE está obsoleto.

La revisión actual, 2026-07-28, cambió el transporte de una manera que importa para cualquiera que despliegue un servidor detrás de un equilibrador de carga. Eliminó las sesiones a nivel de protocolo: ya no hay un apretón de manos de inicialización ni un encabezado de identificador de sesión, cada solicitud lleva su versión de protocolo y capacidades del cliente en su propia metadata, y un servidor que necesita estado entre llamadas devuelve un identificador explícito que el modelo pasa de vuelta como un argumento. Los servidores escritos contra la revisión de 2025-11-25, que sí usaban sesiones, siguen funcionando porque se requiere que los clientes detecten la era anterior y retrocedan; un nuevo servidor no debería adoptar sesiones.

Autorización: para quién es la llamada

Para los transportes HTTP, la especificación define un flujo OAuth 2.1. El servidor es un servidor de recursos y debe publicar metadatos de recursos protegidos (RFC 9728) nombrando su servidor de autorización; cuando llega una solicitud sin un token, responde 401 con un encabezado WWW-Authenticate que apunta a esos metadatos y, idealmente, al alcance mínimo necesario. El cliente descubre los puntos finales del servidor de autorización, se identifica (los documentos de metadatos del ID del cliente son la ruta recomendada; se mantiene el registro dinámico por compatibilidad), ejecuta un flujo de código de autorización con PKCE y debe incluir la URI canónica del servidor como el parámetro de recurso para que el token esté vinculado solo a este servidor. El servidor debe validar esa audiencia, debe rechazar tokens emitidos para cualquier otra cosa y nunca debe pasar un token a otro servicio.

La consecuencia para un ERP es la importante. Debido a que el token identifica a una persona, el servidor puede variar el resultado de tools/list por las credenciales en la solicitud, y la especificación lo dice explícitamente. Ese es el mecanismo para el filtrado basado en roles: la lista de un usuario de finanzas y la lista de un usuario de almacén provienen del mismo servidor y son diferentes. Un alcance insuficiente en tiempo de ejecución se señala con un 403 y un desafío de alcance del que el cliente puede avanzar, aunque para la mayoría de los sistemas empresariales el verdadero límite es el rol en el ERP en lugar del alcance amplio de OAuth.

La parte difícil: permisos y transacciones

Todo lo anterior se puede implementar en una tarde con un SDK. Lo que separa a un servidor ERP MCP de una demostración es el tratamiento de las dos cosas que el protocolo deja al servidor: si se permite una llamada y qué significa una llamada.

La autorización debe ser verificada dos veces. Filtrar la lista de herramientas evita que el modelo elija algo que no debería, lo que ahorra tokens y confusión. Verificar de nuevo cuando la herramienta se ejecuta es el límite real, porque un cliente puede enviar cualquier llamada que desee. Un rechazo es mejor devuelto como un error de ejecución de la herramienta, para que el modelo lo lea y lo informe, en lugar de como un fallo de transporte que termina el turno. Así es como se ve una llamada rechazada desde un espacio de trabajo de Sois: un resultado normal, marcado, con una razón.

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Tool not permitted for this account: approveInvoice requires the finance approver role."
      }
    ],
    "isError": true
  }
}

Un rechazo de autorización devuelto como un error de ejecución de la herramienta. El modelo aprende por qué y puede pedir a la persona que apruebe en su lugar; no se escribió nada. Sois también reserva códigos de error JSON-RPC para sesiones no autorizadas, créditos insuficientes, herramientas no permitidas y límites de presupuesto alcanzados.

Las transacciones son la segunda mitad. Una herramienta debe mapearse a una transacción empresarial con un claro antes y después: crear factura produce un borrador con un identificador, registrarPago aplica un pago a una factura, y ninguno deja un estado a medio escribir si falla. Los modelos reintentan, por lo que las escrituras deben ser seguras para repetir o deben rechazar una repetición con un mensaje claro; las anotaciones de la especificación permiten a un servidor declarar una herramienta como de solo lectura, idempotente o destructiva, y clientes como ChatGPT utilizan esas pistas al decidir si pedir confirmación. Donde un paso necesita una decisión que está por encima de la autoridad del agente, el servidor puede devolver un resultado que requiere entrada pidiendo a la persona una pregunta a través del cliente, en lugar de adivinar.

Cómo Sois implementa uno

Un espacio de trabajo de Sois es un servidor MCP en una única URL, la dirección del espacio de trabajo seguida de /api/mcpResponde al desafío 401 con metadatos de recursos protegidos, publica los metadatos de su servidor de autorización, requiere PKCE y emite tokens limitados al espacio de trabajo; un conector en Claude o ChatGPT completa el inicio de sesión sin nada copiado. Un token portador con una clave API está disponible para scripts que no utilizan OAuth, con la identidad y el gasto mantenidos en credenciales separadas a propósito.

La lista de herramientas se genera a partir de las definiciones de herramientas en vivo y se filtra por rol y aplicaciones instaladas; luego, cada llamada se verifica en cuanto a permisos en la ejecución y falla de forma segura. Las llamadas tienen un límite de tasa por conexión, se miden donde el propio agente del espacio de trabajo realiza el razonamiento y son gratuitas en cuanto a cargos de IA donde lo hace el agente del llamador, con un límite establecido por un presupuesto que define el espacio de trabajo, y se registran con entradas y resultados en relación con la persona que las realizó. Las aplicaciones publicadas en el mercado añaden sus herramientas a la misma lista bajo las mismas reglas, por lo que la aplicación de un desarrollador es operativa por un agente en el momento en que se instala.

Preguntas que la gente hace

Este artículo se revisa cuando cambian los productos que describe. Próxima revisión programada: 4 de diciembre de 2026.