MCP para empresas: cómo diseñar un servidor MCP privado

MCP (Model Context Protocol) es un protocolo abierto, publicado por Anthropic a finales de 2024 y adoptado desde entonces por los principales proveedores de modelos y herramientas de desarrollo, que estandariza cómo un agente de IA accede a herramientas, datos y capacidades externas. En una empresa, MCP resuelve un problema muy concreto: que cada agente no tenga que llevar su propia integración con cada sistema.

El problema sin MCP: una integración por agente

Sin una capa común, la arquitectura típica es: el agente de atención al cliente tiene su conector con Salesforce, el agente de pedidos tiene otro, el copilot de ventas tiene un tercero. Tres integraciones con el mismo sistema, tres formas distintas de autenticarse, tres lugares donde revisar permisos y tres puntos de fallo cuando Salesforce cambia. Es lento, caro y difícil de gobernar.

La propuesta: Company Systems → Enterprise MCP Layer → agentes autorizados

Con una capa MCP empresarial, cada sistema se conecta una vez y se expone como un conjunto de capacidades con contrato explícito: "consultar cliente", "buscar pedido", "comprobar disponibilidad", "crear reserva", "consultar factura", "actualizar CRM". Los agentes, sean de Twinny, copilots corporativos o agentes de partners, invocan capacidades; no tocan tablas. Es el principio "connect once, use everywhere".

Cómo diseñar un servidor MCP privado: seis decisiones

• Capacidades, no tablas: modela verbos de negocio (buscar pedido) en lugar de exponer consultas libres sobre la base de datos.
• Contrato por capacidad: entradas, salidas, errores y efectos secundarios documentados; una capacidad que escribe se distingue de una que solo lee.
• Identidad y scopes: cada agente y, cuando aplica, cada usuario final invoca con una identidad propia y un alcance acotado (sus pedidos, no los de otros clientes).
• Aprobación humana: las acciones críticas (un reembolso, una cancelación) pasan por confirmación antes de ejecutarse.
• Origen de datos flexible: la capacidad puede apoyarse en la API del sistema, en la Company Memory ya unificada o, en sistemas legacy sin API, en RPA o automatización de navegador encapsulada.
• Auditoría: cada invocación queda registrada con quién, qué, cuándo, con qué datos y con qué resultado.

Ejemplo: MCP sobre Salesforce para un trabajador digital de ventas

Un trabajador digital que cualifica leads necesita cuatro capacidades: buscar cuenta y contacto, consultar oportunidades abiertas, crear una tarea de seguimiento y actualizar el estado del lead. Se exponen como cuatro herramientas MCP con scopes de solo lectura para las dos primeras y de escritura acotada para las otras dos. El mismo servidor sirve después al agente de atención al cliente, que solo recibe permiso sobre las dos de lectura. La conexión con Salesforce se construyó una vez.

Ejemplo: MCP sobre SAP sin API disponible

En muchos ERP la operación que se necesita no está expuesta o el acceso a la API no está autorizado. La capacidad "consultar estado de pedido" se implementa entonces con RPA sobre la interfaz de SAP, encapsulada exactamente igual que si fuera una llamada a API. El agente no nota la diferencia, y cuando más adelante se habilite la API, la capacidad se reimplementa por dentro sin tocar a los agentes.

Un MCP empresarial no expone bases de datos: expone capacidades controladas.

Dónde encaja MCP en la AI Operating Layer

MCP es la interfaz entre los sistemas y datos de la empresa (incluida la Company Memory) y los agentes que ejecutan. Por encima, el Agent Gateway aplica identidad, permisos, límites y auditoría también a agentes externos autorizados. Por debajo, el Data Lake y la Company Memory garantizan que las capacidades devuelven contexto correcto. Es la pieza que convierte a Twinny en infraestructura y no en un ecosistema cerrado.