Qué es MCP y cómo usarlo en tu empresa

Un asistente de IA puede redactar, resumir y razonar muy bien, pero no sabe nada de tu empresa. No ve tu CRM, no conoce el estado de un pedido en el ERP y no puede mirar la base de datos de facturación. Para que sirva de algo en el día a día, alguien tiene que conectarlo a esos sistemas.

Hasta hace poco, esa conexión se hacía a mano, integración por integración, y para cada herramienta de IA por separado. Es trabajo a medida que se rompe cuando cambia el modelo, la API o el proveedor. MCP existe para acabar con ese pegamento: una forma estándar de que la IA hable con tus sistemas. Aquí te explicamos qué es, qué puedes hacer con él en una empresa y dónde se tuerce cuando se implanta con prisa.

Qué es MCP (Model Context Protocol)

MCP son las siglas de Model Context Protocol, un estándar abierto que define cómo una aplicación de IA se conecta a fuentes de datos y herramientas externas. Lo presentó Anthropic en noviembre de 2024 como proyecto abierto, y desde entonces lo han adoptado OpenAI, Google, Microsoft y muchos fabricantes de software. En diciembre de 2025 pasó a la Agentic AI Foundation, dentro de la Linux Foundation, así que ya no depende de una sola empresa. La especificación está en modelcontextprotocol.io.

Cuando alguien pregunta qué es “un MCP”, casi siempre se refiere a un servidor MCP: el conector concreto que expone un sistema, como “el MCP de GitHub” o “el MCP de nuestro CRM”. El protocolo es la norma; cada servidor es una pieza que la cumple.

La analogía que más se usa es la del USB-C de la IA: un único conector en lugar de un cable distinto para cada par de dispositivos. Y tiene sentido por el problema que resuelve. Si tienes 3 aplicaciones de IA y 3 sistemas internos, sin estándar hay que construir 9 integraciones. Con MCP son 3 + 3: cada sistema tiene su servidor MCP y cada aplicación su cliente MCP. Y como los grandes asistentes ya traen el cliente de serie, en la práctica tú solo construyes los 3 servidores.

Cómo funciona: host, cliente y servidor

La arquitectura es cliente–servidor y tiene tres piezas:

• Host: la aplicación con la que trabaja la persona. Puede ser Claude, ChatGPT, un editor como Cursor o una aplicación interna tuya.
• Cliente MCP: el componente del host que habla con los servidores. El host abre un cliente por cada servidor al que se conecta.
• Servidor MCP: un programa pequeño que expone un sistema tuyo (CRM, ERP, base de datos, documentación) en el formato que entiende el protocolo. Es la pieza que construyes tú, o que construimos nosotros.

Cada servidor MCP ofrece tres tipos de capacidades. Conviene distinguirlas porque no implican el mismo riesgo: leer un documento no es lo mismo que ejecutar una acción.

• Tools (herramientas): acciones que el modelo puede pedir que se ejecuten, como “crear una tarea” o “buscar pedidos de un cliente”.
• Resources (recursos): datos y contexto que se pueden leer, como un documento, una ficha o el resultado de una consulta.
• Prompts: plantillas de instrucciones reutilizables, por ejemplo “prepara el resumen semanal de cuenta”.

En cuanto al transporte, hay dos formas de conectar. stdio sirve para servidores locales que corren en el mismo equipo que el host. Streamable HTTP sirve para servidores remotos, y para esos la especificación define la autorización sobre OAuth 2.1. En una empresa, casi todo lo interesante es remoto y compartido, así que la autenticación no es un detalle.

Para qué sirve MCP en una empresa

Estos son los usos que más nos encontramos, todos apoyados en sistemas que ya tienes:

• Ventas que consultan el CRM en lenguaje natural. “¿Qué oportunidades de este trimestre llevan dos semanas sin actividad?” Con un servidor MCP sobre Zoho CRM, el comercial lo pregunta en su asistente y, si quiere, pide que cree la tarea de seguimiento. Sin abrir el CRM ni montar filtros.
• Soporte con contexto completo. El agente lee el ticket y, en la misma conversación, consulta el estado del pedido y las facturas en el ERP. La respuesta deja de depender de cambiar de pestaña cuatro veces.
• Finanzas y operaciones que consultan datos. Un servidor de solo lectura sobre la base de datos permite preguntar por cobros pendientes o stock y obtener la respuesta con la fuente. El modelo no puede modificar nada, porque el servidor solo expone consultas acotadas.
• Búsqueda en el conocimiento interno. Manuales, contratos, procedimientos y documentación técnica accesibles como recursos, con los permisos de quien pregunta.
• Herramientas de desarrollo. Los equipos técnicos conectan su asistente de código a GitHub, a Sentry o a su documentación interna para investigar un fallo con datos reales.
• Operaciones que disparan flujos. Desde el asistente se lanza un proceso ya existente, como generar un informe o reprocesar una remesa, con confirmación previa.

Fíjate en el patrón: en todos los casos, el trabajo pesado (reglas de negocio, validaciones, permisos) ya vive en tu sistema. MCP solo hace que la IA pueda llegar hasta ahí de una forma controlada. Si te interesa la parte de procesos, lo desarrollamos en automatización de procesos con IA.

MCP vs API: en qué se diferencian

Es la duda que más nos plantean cuando explicamos MCP, y tiene sentido: los dos conectan software con software. La diferencia está en quién es el cliente.

Una API está pensada para programas. Un desarrollador lee la documentación, decide qué endpoint llamar y con qué parámetros, y lo deja programado. Si mañana quieres usar esa API desde otra herramienta, vuelves a programar la integración.

Un servidor MCP está pensado para modelos de IA. El cliente MCP pregunta al servidor qué herramientas ofrece, y cada herramienta llega con una descripción en lenguaje natural y un esquema de parámetros que el modelo entiende. Es el modelo el que decide, en cada conversación, qué herramienta usar. Y como el protocolo es el mismo para todos, ese servidor funciona con cualquier asistente compatible.

	API	MCP
Quién la usa	Un programa escrito por un desarrollador	Un modelo de IA, a través de un cliente MCP
Cómo se descubre	Leyendo la documentación	El cliente pregunta al servidor qué ofrece
Quién decide qué llamar	El código, fijado de antemano	El modelo, según la petición
Reutilización	Una integración por cada herramienta	Un servidor para cualquier host compatible

La conclusión práctica: no es MCP o API, es MCP encima de la API. El servidor MCP traduce las peticiones del modelo a llamadas a tu API, con los permisos y límites que tú defines. Por eso, cuando un cliente nos pide “un MCP para su ERP”, lo primero que miramos es si ese ERP tiene una API decente.

Beneficios de MCP para una empresa

• Lo construyes una vez y lo reutilizas. Un servidor MCP sobre tu CRM lo pueden usar Claude, ChatGPT o tu propia aplicación. Si mañana cambias de proveedor de IA, el conector sigue ahí y no dependes de un solo fabricante.
• Control sobre lo que se expone. Tú decides qué herramientas y qué datos existen, con qué permisos y con qué registro. El modelo solo puede hacer lo que el servidor le ofrece.
• Integración más rápida. El protocolo ya resuelve el descubrimiento de capacidades, el formato de las llamadas y los errores. Se dedica el tiempo a lo que importa: qué exponer y con qué reglas.
• Tú decides qué datos salen. El servidor corre en tu infraestructura y devuelve al modelo solo lo mínimo necesario para responder. Lo que no expone, el proveedor de IA no lo ve nunca. Si esto te preocupa, tenemos otro artículo sobre RGPD y datos con modelos de lenguaje.

Riesgos y errores que conviene evitar

MCP es potente precisamente porque da manos a la IA. Y eso es lo que hay que cuidar. Los errores que más vemos:

• Exponer herramientas de escritura sin confirmación. Un modelo puede equivocarse al interpretar una petición. Crear, modificar o borrar debe pedir confirmación humana, y lo irreversible, mejor no exponerlo.
• Permisos demasiado amplios. Conectar el servidor con un token de administrador “para que funcione” es el atajo más caro. Cada servidor debe usar credenciales con el mínimo privilegio, idealmente las del propio usuario.
• Inyección de instrucciones (prompt injection). El contenido que devuelve una herramienta o un recurso, como un correo, una ficha o un ticket, puede incluir texto pensado para manipular al modelo. Trata todo lo que viene de fuera como dato, no como órdenes, y limita lo que el modelo puede hacer después de leerlo.
• Volcar respuestas gigantes al contexto. Devolver 5.000 filas no hace al modelo más listo: lo hace más lento, más caro y menos preciso. Las herramientas deben filtrar, paginar y resumir.
• No registrar nada. Si no sabes quién pidió qué y qué se ejecutó, no puedes auditar ni depurar. Cada llamada debería quedar en un log.
• Tratar MCP como sustituto de una API bien hecha. MCP se apoya en tu API, no la reemplaza. Si el sistema no tiene una API fiable, con validaciones y permisos, el servidor MCP heredará ese problema.

Cómo te ayudamos a implantarlo

Trabajamos con un método corto y verificable, pensado para que veas resultados con un equipo real antes de comprometer más:

1. Descubrimiento. Repasamos qué sistemas tienes y qué preguntas o tareas te harían ahorrar tiempo de verdad. Priorizamos uno o dos casos, no diez.
2. Diseño. Definimos qué herramientas y recursos se exponen, cuáles son solo lectura y cuáles necesitan confirmación, y qué permisos tiene cada perfil.
3. Construcción. Montamos el servidor MCP sobre tus APIs existentes o, si no hay API fiable, la creamos primero. Es habitual cuando el sistema es un ERP antiguo.
4. Seguridad y operación. Autenticación, registro de auditoría y límites de uso desde el primer día, no como parche posterior.
5. Piloto. Un equipo lo usa con datos reales durante unas semanas y medimos si le ahorra trabajo.
6. Iteración. Ajustamos lo que no funciona, ampliamos a más sistemas y equipos solo si el piloto lo justifica.

El resultado es que tu equipo puede pedirle a su asistente de IA cosas sobre tus sistemas con las reglas y los permisos que tú has decidido, y que cualquier herramienta compatible puede reutilizar esa base.

Cierre

MCP no es una moda, es el cable estándar que estaba faltando. Pero un conector mal diseñado le da a la IA más acceso del que debería. Diseñar bien ese conector es justo lo que hacemos en IA aplicada. Cuéntanos qué sistemas tienes en contacto y te decimos si compensa. Y si tu punto de partida son las APIs, mira antes cómo integrar sistemas con una API a medida.