MCP en la empresa: el contexto de negocio que falta a la IA

Para que un modelo llame a una herramienta externa hace falta un contrato explícito: qué recursos existen, qué parámetros admiten y qué devuelven. Eso es MCP, el Model Context Protocol que Anthropic liberó como estándar abierto y que hoy se declara en `claude_desktop_config.json` o se registra directamente desde Claude Code. El análisis que publicó AiThority el 27 de agosto entra por el otro extremo del mismo problema: la adopción de IA dentro de las empresas ya ha ocurrido, y ha ocurrido sin pasar por el departamento de IT.

El matiz importa más de lo que parece. Cuando alguien de operaciones pega un fragmento de contrato en un chat para que se lo resuma, el modelo responde con lo que sabe del mundo, no con lo que sabe de esa empresa. No conoce el catálogo de productos, ni el histórico de incidencias de ese cliente, ni la política de descuentos que se aprobó en marzo. El texto sale correcto y encaja mal, que es la peor combinación posible dentro de un proceso de trabajo.

De pegar texto a exponer sistemas

La propuesta de MCP es sustituir ese copiar y pegar por una conexión declarada. Un servidor MCP expone un conjunto acotado de herramientas y recursos: consultar el CRM, leer la tabla de precios vigente, abrir un ticket, buscar en la documentación interna. El modelo no recibe una base de datos entera, recibe una lista de operaciones que puede invocar y nada más. Quien monta el servidor decide qué entra en esa lista, con qué permisos y con qué límites.

Ahí está la parte de gobierno del dato que el artículo subraya y que suele quedar tapada cuando el protocolo se explica solo en clave técnica. Un servidor MCP se versiona, se revisa en un pull request, se restringe por rol y se registra. Una pestaña del navegador con un asistente dentro no ofrece ninguna de esas cuatro cosas.

Dónde encaja en el resto del stack

MCP no trabaja solo. En Claude Code convive con las skills, que son paquetes reutilizables de instrucciones y contexto que el modelo invoca bajo demanda; con los subagentes, pensados para delegar tareas acotadas; con los hooks, comandos de shell que se ejecutan en eventos del ciclo de vida como PreToolUse o PostToolUse; y con los plugins, que empaquetan todo lo anterior para distribuirlo por marketplace. La división de trabajo que nos ha funcionado es esta:

1. MCP para el acceso a sistemas externos: datos vivos, escrituras, integraciones con terceros.
2. Skills para el conocimiento de negocio estable: cómo se nombra un proyecto, qué formato tiene un informe, qué no se le promete nunca a un cliente.
3. Hooks para las reglas duras: validar antes de escribir, bloquear una ruta, avisar en un canal.

Confundir esas capas es el error más repetido que vemos en auditorías. Meter la política de descuentos dentro de un servidor MCP la convierte en código que alguien tiene que desplegar cada vez que cambia; dejarla en una skill la deja donde puede editarla quien la entiende, que casi nunca es el equipo de desarrollo.

Para quién es útil

Para un equipo de IT que ya ha perdido la batalla de prohibir asistentes y necesita reconducirla: un servidor interno con lectura sobre tres o cuatro sistemas resuelve bastante más que una política de uso colgada en la intranet. Para responsables de datos que necesitan saber qué consultó el modelo y cuándo. Y para equipos pequeños, porque el coste de entrada es bajo: un servidor MCP mínimo cabe en unos cientos de líneas y una entrada de configuración.

No sirve de nada, en cambio, si el problema de fondo está en los datos. Un protocolo bien diseñado sobre un CRM sucio devuelve lo mismo de siempre, solo que mejor formateado y con más apariencia de autoridad.

Nuestra lectura, después de bastantes meses montando servidores MCP para clientes, es que el protocolo resuelve la fontanería y la resuelve bien, pero el trabajo que de verdad mueve los resultados es el aburrido: decidir qué expone cada herramienta y quién puede llamarla. Quien se salte esa parte acabará con un asistente mejor conectado dando las mismas respuestas genéricas de antes.