Qué es MCP (Model Context Protocol) y qué cambia para un negocio que ya tiene sus sistemas

MCP (Model Context Protocol) es un estándar abierto para conectar aplicaciones de IA con sistemas externos: bases de datos, herramientas y procesos. En vez de programar una integración distinta para cada asistente, expones una vez tus datos y tus acciones, y cualquier cliente compatible puede usarlos. La propia documentación lo compara con un puerto USB-C para aplicaciones de IA.

Para un negocio que ya tiene CRM, facturación y automatizaciones, la pregunta útil no es qué es MCP, sino qué cambia. Y lo que cambia es concreto: deja de tener sentido construir una integración a medida cada vez que aparece un asistente nuevo, y empieza a tener sentido decidir con cuidado qué parte de tu operación queda al alcance de un modelo.

Este artículo explica el protocolo en términos de negocio, lo compara con una API normal, y se detiene donde casi nadie se detiene: en los permisos. Si lo que buscas es qué es un agente y cuándo compensa, está en agentes de IA para negocios.

Aviso de caducidad: MCP se versiona por fecha y cambia rápido. Todo lo técnico de este artículo está contrastado con la documentación oficial y la especificación, consultadas en septiembre de 2026, sobre la versión de protocolo 2026-07-28. Antes de construir nada, comprueba la versión vigente.

¿Qué problema resuelve MCP?

El problema es de multiplicación. Si tienes cuatro sistemas que un asistente debería consultar (el CRM, la plataforma de cursos, la facturación y la base de conocimiento) y usas tres aplicaciones de IA distintas, alguien tiene que mantener doce integraciones. Cada una con su autenticación, su formato y su mantenimiento. Cuando cambia un campo del CRM, cambian tres sitios.

MCP invierte el planteamiento. Expones cada sistema una vez como servidor, y cada aplicación de IA se conecta a él con el mismo protocolo. Cuatro servidores en lugar de doce integraciones. Es el mismo argumento que justifica cualquier estándar: no es que haga algo imposible antes, es que deja de haber una traducción distinta por cada par.

La definición oficial lo dice sin adornos: MCP es un estándar de código abierto para conectar aplicaciones de IA a sistemas externos. Lo anunció y liberó Anthropic el 25 de noviembre de 2024 (consultado en septiembre de 2026), con la especificación, los SDK y un repositorio abierto de servidores de referencia. Hoy lo soportan clientes como Claude, ChatGPT, Visual Studio Code o Cursor.

¿Quién es quién: host, cliente y servidor?

Tres piezas, y conviene no confundirlas porque los tres nombres se usan mal continuamente.

• MCP Host: la aplicación de IA que coordina uno o varios clientes. Es el programa con el que habla la persona.
• MCP Client: el componente que mantiene la conexión con un servidor y le lleva el contexto al host. El host crea un cliente por cada servidor al que se conecta.
• MCP Server: el programa que proporciona el contexto. Es la pieza que tú construyes o instalas.

Cuando alguien dice “he montado un MCP”, casi siempre quiere decir que ha montado un servidor. El servidor puede ejecutarse en la misma máquina que el host, con transporte stdio, o en remoto, con transporte Streamable HTTP y autenticación HTTP estándar. Para los tokens, la especificación recomienda OAuth.

Por debajo hay dos capas: la capa de datos, que es un protocolo basado en JSON-RPC 2.0, y la capa de transporte, que se ocupa de la conexión y la autenticación. No necesitas saber más para decidir, pero sí para entender una cosa: MCP define cómo se intercambia el contexto, y nada más. No dice cómo debe usarlo el modelo ni qué debe hacer con él. Esa parte sigue siendo tuya.

¿Qué expone un servidor MCP?

Tres primitivas. Traducidas a lo que significan en una operación real:

• Tools (herramientas): funciones ejecutables que la aplicación de IA puede invocar. En un negocio digital: consultar el estado de un pedido, buscar al alumno por email, crear una tarea en el CRM, comprobar si una factura está pagada.
• Resources (recursos): fuentes de datos que aportan contexto. El catálogo de productos, las políticas de devolución, el esquema de una base de datos.
• Prompts: plantillas reutilizables de interacción. Por ejemplo, la forma estándar de preparar el resumen de un lead antes de una llamada.

La diferencia práctica entre una herramienta y un recurso es quién actúa. Un recurso se lee. Una herramienta hace algo, y ahí es donde empieza el riesgo.

Del lado del cliente, la primitiva vigente es elicitation: el servidor puede pedirle información o una confirmación a la persona antes de seguir. Es el mecanismo natural para meter una aprobación humana. Conviene saber que en la versión 2026-07-28 quedaron obsoletas sampling y logging; si te encuentras un tutorial que se apoya en ellas, está desactualizado.

MCP frente a una API normal

Es la pregunta que más se repite, y la respuesta corta es que no compiten.

Lo importante de la tabla está en la última fila. Con una API, el alcance de lo que puede pasar lo fija tu código. Con MCP, el alcance lo fija lo que hayas expuesto, porque el orden de las llamadas ya no lo decides tú.

Y una aclaración que ahorra discusiones: MCP no sustituye a tu API. Lo normal es que el servidor MCP se apoye en la API que ya tienes y le ponga delante una capa pensada para que la consuma un modelo: nombres explícitos, descripciones útiles y esquemas de entrada estrictos.

¿Qué cambia esto para un negocio que ya tiene sus sistemas?

Tres cosas, por orden de impacto.

Primera: el coste de conectar una IA nueva baja. Si mañana el equipo quiere probar otro asistente, no se rehace la integración. Esto solo es una ventaja si ya tienes varios sistemas y algo parecido a una fuente de verdad. Si tus datos están repartidos entre tres herramientas que no coinciden, MCP no lo arregla; lo hace accesible más deprisa, que no es lo mismo. Ese trabajo previo es el de sistemas para negocios digitales.

Segunda: la superficie de acceso se vuelve explícita. Hasta ahora, lo que un asistente podía tocar estaba implícito en el código de cada integración. Con un servidor MCP, queda escrito en una lista de herramientas. Eso es bueno: se puede revisar. También significa que alguien tiene que revisarlo.

Tercera: aparece una decisión de producto. Qué parte de tu operación quieres que sea conversacional. No todo gana por serlo.

¿Cuándo compensa montar un servidor MCP propio?

Cuándo sí

• Tenéis un sistema propio, un backoffice o un CRM a medida que ninguna integración estándar cubre, y varias personas quieren consultarlo desde una aplicación de IA.
• Las consultas son variadas y en lenguaje natural: “¿cuántos alumnos del lanzamiento de marzo siguen sin acceder?” no cabe en un informe fijo.
• Ya existe una API interna estable, así que el servidor es una capa fina encima y no un proyecto nuevo.
• Hay alguien que va a mantenerlo cuando cambie el esquema de datos o la versión del protocolo.

Cuándo no

• Cuando la consulta es siempre la misma. Un informe programado cuesta menos y no se equivoca.
• Cuando no hay API ni modelo de datos claro. Primero el sistema, después la conexión.
• Cuando lo que se quiere automatizar es determinista. Dar acceso al aprobarse un pago, asignar un lead por país o deduplicar por email son reglas: van en código o en una automatización, como explico en IA aplicada en negocios digitales.
• Cuando ya existe un servidor oficial para esa herramienta y cubre lo que necesitáis.
• Cuando nadie va a revisar los logs. Un servidor MCP sin registro falla en silencio igual que cualquier automatización, y eso lo cuento en automatizaciones que fallan en silencio.

Permisos y riesgo: la parte que no se cuenta

Aquí es donde se rompen los proyectos, y casi nunca por el protocolo.

El fallo grave es el token con demasiado alcance. Expones una herramienta que se llama consultar_alumno, pero la credencial que usa por debajo tiene permiso de escritura sobre toda la base. El día que el modelo interprete mal una petición, el límite no será el nombre de la herramienta: será el permiso real. El nombre es una etiqueta; el token es la frontera.

Reglas que aplicamos siempre:

• Empezar en solo lectura. Se abre escritura herramienta a herramienta, cuando hay un motivo.
• Una credencial por servidor, con el alcance mínimo. Nunca la clave de administración que ya teníais por ahí.
• Las decisiones que mueven dinero o accesos no pasan por el modelo. Cobrar, dar de baja, cambiar un precio o conceder acceso a un curso son lógica determinista. Van en código, son auditables y se pueden revisar. Un modelo acierta estadísticamente; eso no es suficiente cuando la consecuencia es que alguien pierde el acceso que pagó.
• Aprobación humana para lo irreversible, usando elicitation o un paso previo en vuestro propio flujo.
• Registro de cada llamada: qué herramienta, con qué argumentos, qué devolvió y en nombre de quién. Sin esto no hay forma de reconstruir un incidente.
• Datos personales decididos antes de conectar, no después: qué ve el servidor, a qué proveedor viaja y cuánto se guarda.

Hay un riesgo más, propio de este modelo de trabajo: el servidor describe sus herramientas con texto, y ese texto entra en el contexto del modelo. Si instaláis un servidor de terceros, estáis confiando en lo que ese servidor dice de sí mismo. Trátalo como tratarías a una dependencia con permisos sobre vuestros datos, porque es exactamente eso.

Errores comunes con MCP

• Exponer la base de datos entera en vez de un conjunto corto de herramientas con un propósito claro.
• Herramientas mal descritas. El modelo elige a partir de la descripción; una descripción vaga produce llamadas equivocadas.
• Esquemas de entrada laxos. Si el parámetro admite cualquier cadena, alguna vez recibirá cualquier cosa.
• Confundir el servidor con el producto. MCP conecta; el valor sigue estando en que los datos sean correctos.
• Copiar tutoriales de versiones antiguas. El protocolo cambia y hay primitivas ya obsoletas.
• Montarlo sobre un sistema que todavía no existe. Si el proceso vive en hojas de cálculo, lo que toca es lo que cuento en software a medida o no-code.
• Sin dueño. Nadie actualiza el servidor cuando cambia el esquema, y las respuestas empiezan a mentir.

Checklist antes de conectar un servidor MCP a vuestros sistemas

• El caso de uso está escrito y no se resuelve con un informe fijo.
• Existe una fuente de verdad para los datos que va a consultar.
• La lista de herramientas es corta y cada una tiene un propósito claro.
• Cada herramienta tiene esquema de entrada estricto y descripción precisa.
• Las credenciales son específicas del servidor y con el alcance mínimo.
• Todo empieza en solo lectura; la escritura se abre caso a caso.
• Las acciones irreversibles exigen confirmación de una persona.
• Cobros, accesos y precios se deciden en código, no en el modelo.
• Cada llamada queda registrada con argumentos, resultado y responsable.
• Está decidido qué datos personales quedan expuestos y a dónde viajan.
• La versión de protocolo está anotada y hay alguien que revisa los cambios.
• Hay un responsable del servidor cuando cambie el esquema de datos.

Por dónde empezar

Si la idea os interesa pero no tenéis claro el caso, el primer paso barato es instalar un servidor oficial de una herramienta que ya uséis, en solo lectura, y ver qué preguntas hace la gente de verdad. Esas preguntas os dirán qué merece un servidor propio y qué no.

Cuando el caso toca datos de clientes, pagos o accesos, o cuando hay que integrarlo con el CRM y el resto de la operación, conviene hacerlo con criterio de sistema: herramientas mínimas, permisos mínimos, logs y un responsable. Es el mismo orden que seguimos en cualquier trabajo de IA aplicada y agentes, y cuando hace falta una capa propia por debajo, en software a medida.

Si tenéis un sistema interno que os gustaría poder consultar en lenguaje natural y no sabéis si eso es un servidor MCP, un informe o nada, cuéntame qué proceso os está frenando y te digo qué tiene sentido.