Qué es MCP y qué puede hacer por tu empresa de verdad
Una inteligencia artificial puede escribirte un correo impecable y a la vez no tener ni idea de cuántas unidades te quedan en el almacén. Sabe razonar, pero no sabe nada de tu empresa, porque su conocimiento se congeló el día que terminó su entrenamiento.
Durante dos años, conectar esos modelos con los sistemas de una empresa significó programar un adaptador a medida para cada combinación. Un conector para que ChatGPT hablara con tu ERP, otro para que Claude hablara con el mismo ERP, otro más para tu CRM. Y cada vez que una de esas herramientas cambiaba su API, se rompía todo.
MCP es el estándar que acabó con eso. Aquí tienes qué es exactamente, cómo funciona por dentro, qué puede salir mal y, sobre todo, cuándo tiene sentido para una empresa mediana y cuándo es pegarse un tiro en el pie.
1. El problema que resuelve
Imagina que quieres que una IA responda a «¿cuántas chaquetas talla M me quedan en el almacén de Valencia?». El modelo no lo sabe y no puede saberlo, porque ese dato vive en tu base de datos y cambia cada hora.
La solución clásica era programar un puente. El problema aparece cuando multiplicas. Si tienes tres modelos distintos y cinco sistemas que conectar, acabas con quince puentes que mantener, cada uno con su autenticación, su formato y su manera de romperse.
Antes
Un conector por pareja- Cada modelo necesita su propio adaptador a cada sistema
- Tres modelos y cinco sistemas son quince integraciones
- Cambia una API y se rompe todo lo que dependía de ella
- Las herramientas están escritas a fuego en el código
Con MCP
Un servidor por sistema- Cada sistema expone un servidor y ya está
- Tres modelos y cinco sistemas son cinco servidores
- El servidor absorbe los cambios sin tocar el agente
- El modelo descubre las herramientas al conectarse
2. Qué es y quién lo controla ahora
MCP son las siglas de Model Context Protocol. Anthropic lo publicó como estándar abierto en noviembre de 2024 y define una forma común de que una aplicación de IA pregunte «¿qué sabes hacer?» a un servicio externo, reciba una lista de capacidades y las invoque.
El dato que importa para decidir si apostar por él
El 9 de diciembre de 2025, Anthropic donó MCP a la Agentic AI Foundation, una fundación creada dentro de la Linux Foundation. En la misma operación, Block aportó su marco `goose` y OpenAI aportó `AGENTS.md`. Entre los miembros de primer nivel están Amazon Web Services, Google, Microsoft, Cloudflare y Bloomberg, además de las tres anteriores.
Esto no es una nota de prensa sin consecuencias. Significa que MCP dejó de ser el estándar de una empresa para pasar a gobernanza neutral, con sus competidores directos sentados en la misma mesa. Para una pyme que se pregunta si esto seguirá existiendo dentro de tres años, es la diferencia entre apostar por un formato propietario y apostar por algo con el respaldo del sector.
3. Las tres piezas, y quién decide cada una
Un servidor MCP expone tres tipos de cosa. La distinción que casi nadie explica, y que está en la documentación oficial, es que cada una la controla un actor distinto. Entenderlo cambia cómo diseñas el sistema.
| Pieza | Qué es | Quién decide usarla | Ejemplo en una empresa |
|---|---|---|---|
| Herramientas | Funciones que ejecutan algo y cambian el estado de un sistema | El modelo | Reservar stock, crear un ticket, emitir una etiqueta de envío |
| Recursos | Datos de solo lectura, identificados por una dirección | La aplicación | Consultar un pedido, leer el catálogo, ver un histórico |
| Plantillas | Instrucciones reutilizables para tareas repetidas | El usuario | «Prepara el resumen mensual de incidencias» |
Las herramientas son las únicas que el modelo decide invocar por su cuenta, y por eso son la pieza con más riesgo. Los recursos los sirve la aplicación, y las plantillas las lanza una persona a propósito.
La lectura práctica es que el riesgo se concentra en las herramientas. Un recurso mal diseñado, como mucho, enseña datos que no debería. Una herramienta mal diseñada puede borrar una base de datos porque el modelo interpretó mal una frase.
Por eso conviene empezar exponiendo solo recursos, en modo lectura, y añadir herramientas después, una a una y con criterio.
4. MCP, RAG y las llamadas a funciones
Aquí hay mucha confusión y vale la pena separarlo, porque son tres cosas distintas que a menudo conviven en el mismo proyecto.
| Qué hace | Cuándo lo quieres | |
|---|---|---|
| RAG | Busca en tus documentos y le pasa los fragmentos relevantes al modelo. Solo lectura, sobre contenido más o menos estático. | Responder sobre manuales, políticas, contratos o normativa interna. |
| Llamadas a funciones | El modelo devuelve un objeto diciendo qué función quiere llamar. Las funciones las defines tú en el código de tu aplicación. | Cuando tienes dos o tres acciones fijas y no vas a cambiarlas. |
| MCP | Estandariza toda la infraestructura alrededor de esa llamada. El modelo descubre las herramientas al conectarse, se autentica y las invoca sin que reescribas la aplicación. | Cuando quieres datos vivos, acciones reales y poder añadir capacidades sin volver a desplegar. |
5. Cómo se conecta, sin los mitos que circulan
Todos los mensajes van en JSON-RPC, y la especificación define exactamente dos formas de transporte. Esto conviene aclararlo porque circulan guías desactualizadas que mencionan tres o cuatro.
stdio
En la misma máquina- El cliente lanza el servidor como un proceso hijo
- Mensajes JSON separados por saltos de línea
- Rápido y sin red de por medio
- Para herramientas locales y entornos de desarrollo
Streamable HTTP
En remoto- Cada mensaje es una petición HTTP a un único punto
- La respuesta llega como JSON o como flujo de eventos
- Lo que usarás para un servidor de empresa
- Permite respuestas largas y progreso en tiempo real
El protocolo no guarda estado
La versión actual es explícita en esto. MCP no tiene sesiones a nivel de protocolo. Si tu servidor necesita recordar algo entre peticiones, como un carrito o un expediente abierto, emite un identificador y lo recibe de vuelta como un argumento más.
Y aquí va una regla que la especificación marca en mayúsculas. Ese identificador nunca puede valer como autenticación. Quien lo tenga no puede operar por eso solo sobre los datos de otro. Suena obvio y es uno de los fallos que la propia documentación describe como vector de ataque.
6. Lo que puede salir mal
Dar a un modelo la capacidad de ejecutar acciones sobre tus sistemas amplía la superficie de ataque, y conviene mirarlo de frente. Estos son los riesgos que la especificación documenta, no una lista de miedos genéricos.
| Riesgo | Qué pasa | Qué lo evita |
|---|---|---|
| Instrucciones camufladas | Un texto que llega desde un correo, un documento o la respuesta de una herramienta contiene órdenes, y el modelo las obedece como si fueran tuyas. | Marcar todo lo que llega de fuera como dato no fiable, nunca como instrucción. |
| Herramientas envenenadas | Un servidor malicioso publica herramientas con descripciones engañosas para que el modelo las elija o les pase credenciales. | Registro de servidores aprobados y revisión de lo que expone cada uno antes de conectarlo. |
| Delegado confuso | Se engaña al agente para que use sus permisos legítimos y haga algo que el atacante no podría hacer por su cuenta. | Consentimiento por cada cliente antes de reenviar a un servicio de terceros. |
| Reenvío de credenciales | El servidor acepta un token que no se emitió para él y lo pasa hacia el sistema de destino. | La especificación lo prohíbe de forma tajante. Un servidor no debe aceptar tokens que no se emitieron para él. |
| Servidor local comprometido | Se instala un servidor local que ejecuta código en tu máquina con tus permisos. | Confirmación explícita mostrando el comando completo antes de ejecutarlo, y aislamiento del proceso. |
La pieza que no se puede saltar
Todo lo anterior se sostiene sobre una idea simple. Las acciones irreversibles necesitan que una persona diga que sí. Un reembolso, un borrado, una transferencia o un despliegue no deberían ejecutarse porque un modelo lo consideró razonable.
En la práctica eso significa dos catálogos de herramientas. Uno de lectura, siempre disponible, y otro de escritura que solo aparece cuando el flujo ha llegado a un punto en el que tiene sentido y alguien ha confirmado.
7. Cuándo compensa y cuándo no
Esta es la parte que suele faltar en los artículos sobre MCP, porque no todo el mundo lo necesita.
Compensa si…
- Tu equipo pregunta lo mismo todos los días y la respuesta vive en un sistema al que cuesta entrar. Estado de pedidos, stock, vencimientos, histórico de un cliente.
- Ya usas Claude o ChatGPT a diario y notas que la mitad del tiempo se te va en copiar datos para pegárselos.
- Tienes varios sistemas que no se hablan y quieres consultarlos juntos sin montar un almacén de datos.
- Vas a repetir el patrón. Si vas a conectar tres o cuatro sistemas, el estándar se amortiza rápido.
No compensa si…
- Solo necesitas una acción concreta. Para eso, un flujo de automatización normal es más simple, más barato y más fácil de mantener.
- Tu sistema no tiene API. Sin una forma de entrar, no hay nada que exponer, y el problema es otro.
- Nadie en tu empresa usa asistentes de IA. Montar la infraestructura antes que la costumbre es construir una autopista hacia un pueblo vacío.
- Lo que buscas es que te encuentren. Un servidor MCP no te hace aparecer en ChatGPT cuando alguien pregunta por tu sector. Eso es otra cosa y lo explicamos en cómo aparecer en ChatGPT y Perplexity.
8. Por dónde empezar
| Fase | Qué se hace | Cuándo pasar a la siguiente |
|---|---|---|
| 1. Solo lectura | Exponer consultas sobre uno o dos sistemas, sin capacidad de modificar nada. Comprobar que lo que responde es cierto. | Cuando el equipo se fía de las respuestas sin ir a verificarlas. |
| 2. Control de acceso | Autenticación real, permisos por usuario y registro de cada llamada con quién la hizo y qué devolvió. | Cuando puedes reconstruir qué pasó en cualquier momento. |
| 3. Escritura con confirmación | Añadir acciones que modifican datos, cada una con su confirmación humana si es irreversible. | Nunca del todo. Esta fase se amplía poco a poco. |
La fase 1 suele resolver más de lo que la gente espera. Consultar bien ya elimina buena parte del trabajo manual, y no tiene ninguno de los riesgos de la fase 3.
Lo mínimo que hay que dejar montado
- Cada acción se ejecuta con los permisos de la persona que la pidió, no con una cuenta de servicio que lo puede todo.
- El catálogo de herramientas se abre por pasos, no entero desde el principio.
- Todo lo que llega de fuera se trata como dato, nunca como instrucción.
- Cada llamada queda registrada con usuario, herramienta, parámetros y resultado.
- Las acciones irreversibles paran y esperan a una persona.
Fuentes consultadas
Dudas sobre qué es MCP y qué puede hacer por tu empresa de verdad
No, son cosas distintas. Un servidor MCP hay que instalarlo a propósito, así que solo lo usa quien ya te conoce y decide conectarse. Aparecer citado cuando alguien pregunta por tu sector depende de otro trabajo, que es el de posicionamiento para motores generativos.
No necesariamente. Una automatización ejecuta un proceso definido de antemano, siempre igual. MCP tiene sentido cuando quieres preguntar cosas distintas cada vez y que sea el modelo quien decida qué consultar. Conviven bien, y muchas veces la automatización sigue siendo la respuesta correcta.
Depende por completo de cómo esté montado. Con permisos por usuario, catálogo de herramientas acotado, registro de todo y confirmación humana en lo irreversible, es razonable. Sin eso, no lo es. La propia especificación documenta los ataques concretos que hay que prevenir.
Con cualquiera cuya aplicación soporte el protocolo, que hoy son la mayoría de las que se usan en un entorno profesional. Esa portabilidad es justo el argumento del estándar, y se reforzó al pasar a gobernanza de la Linux Foundation.
Entonces no hay nada que exponer y el problema es anterior. Antes de pensar en MCP hay que resolver cómo se entra a ese sistema, y a veces la conclusión es que toca cambiarlo.
Depende de cuántos sistemas haya que conectar y de si te quedas en consulta o llegas a ejecutar acciones. Un servidor de solo lectura sobre un sistema con API decente es un proyecto corto. Una arquitectura con permisos por usuario, auditoría y escritura controlada ya es otra cosa.
Hablemos de tu
próximo proyecto.
Sin discursos de ventas. Una conversación directa sobre cómo la automatización y el desarrollo web pueden transformar tu operación en la era de la IA.
Soporte España, LATAM y EE. UU.
España · Colombia · Latam · EE. UU.
Respuesta directa y diagnóstico en menos de 24 horas.