«Lo conectamos por MCP y listo.» Es la frase de este año. La dice quien monta su primer agente un domingo por la tarde y la dice el comité de IA de una gran empresa. Y tiene parte de razón: MCP (Model Context Protocol) es el estándar abierto que permite a un asistente de IA —Claude, ChatGPT, Gemini, Copilot— conectarse a herramientas y datos sin una integración a medida para cada sistema. Pero mucha gente lo usa sin saber qué es ni qué está conectando. Y la frase esconde una trampa: MCP resuelve cómo llega un agente a tus datos. No decide qué datos debería poder ver. Este artículo explica qué es MCP, cómo funciona por dentro, qué ventajas y limitaciones tiene y, sobre todo, qué buenas prácticas hacen falta para usarlo sin perder el control.
Antes de empezar: seis palabras que vas a leer
Si llegas a la tecnología a través de la IA, algunas de estas palabras se dan por sabidas. No lo están. Una frase para cada una:
- Agente de IA: un modelo de lenguaje que no solo responde, sino que actúa: decide pasos, usa herramientas y consulta datos para cumplir un objetivo.
- Herramienta (tool): una acción concreta que el agente puede ejecutar, como «buscar cliente» o «crear incidencia».
- API: la puerta por la que un programa habla con otro. Casi todos los sistemas de una empresa tienen una.
- Token: aquí, una credencial, una especie de llave digital que demuestra quién eres ante un sistema. Ojo: en IA, «token» también es la unidad en la que se mide el texto que procesa un modelo. Son dos cosas distintas con el mismo nombre.
- OAuth: el estándar con el que una aplicación obtiene permiso para actuar en tu nombre sin conocer tu contraseña. Es lo que pasa cuando pulsas «Continuar con Google».
- Linaje del dato: el rastro de cada dato: de qué sistema viene, cuándo se registró y qué transformaciones ha sufrido por el camino. Es lo que permite comprobar de dónde sale cada afirmación de una IA.
Qué es MCP, sin tecnicismos
MCP es un protocolo: un acuerdo sobre cómo se hablan dos programas. En este caso, una aplicación de IA y un sistema que le ofrece capacidades —buscar un cliente, leer un contrato, consultar una base de datos—.
La comparación que más se repite es la del USB-C, y es buena. Antes de MCP, conectar un asistente al CRM, al ERP y al gestor documental eran tres integraciones a medida. Y para el siguiente asistente, otras tres. Con MCP, cada sistema se expone una vez y lo usa cualquier aplicación compatible. Un conector para todo.
Lo presentó Anthropic como código abierto el 25 de noviembre de 2024. Un año después, el 9 de diciembre de 2025, lo donó a la Agentic AI Foundation, un fondo de la Linux Foundation cofundado por Anthropic, Block y OpenAI, con el apoyo de Google, Microsoft, AWS, Cloudflare y Bloomberg. Hoy no es el protocolo de una empresa. Es el estándar de la industria.
Cómo funciona por dentro: host, cliente y servidor
MCP tiene tres piezas. Son pocas, y entenderlas es lo que te permitirá razonar sobre todo lo demás.
- Host: la aplicación de IA con la que trabajas. Por ejemplo, Claude Desktop, ChatGPT, Cursor, un agente propio.
- Cliente MCP: el conector, dentro del host, que mantiene la conexión con un servidor. Uno por cada servidor conectado.
- Servidor MCP: el programa que ofrece las capacidades de un sistema concreto. Por ejemplo, uno para el CRM, otro para los ficheros, otro para la base de datos.
Un servidor MCP puede ofrecer tres cosas: herramientas, que el modelo ejecuta; recursos, que son datos y contexto que se pueden leer, como un documento; y prompts, plantillas de mensajes predefinidas. Por debajo, todo viaja en mensajes con un formato estándar (JSON-RPC 2.0), por una de dos vías: directamente dentro de tu ordenador, si el servidor es local, o por internet (HTTP), si es remoto.
Veámoslo con un ejemplo. Le preguntas a tu asistente: «¿Qué facturas tiene pendientes el cliente López?»
- Al arrancar, el cliente MCP le ha preguntado a cada servidor conectado qué sabe hacer. El modelo tiene delante la lista de herramientas, con una descripción de cada una.
- El modelo lee tu pregunta y decide, por su cuenta, que la herramienta adecuada es «buscar facturas» del servidor del ERP.
- El cliente envía la petición al servidor del ERP.
- El servidor llama a la API del ERP con su credencial y obtiene las facturas.
- El resultado vuelve al modelo, que lo lee y redacta la respuesta.
Fíjate en el paso 2. Es el modelo quien decide qué herramienta usa y con qué datos. No un programador. Retén esta idea, porque de ella sale todo lo demás.
Qué es un servidor MCP
Un servidor MCP es la pieza que convierte un sistema —una base de datos, un SaaS, un repositorio de documentos— en algo que un asistente puede usar sin integración a medida. Muchos envuelven una API que ya existía: reciben la petición del modelo, llaman a la API del sistema y devuelven el resultado.
Hay dos tipos, y la diferencia importa más de lo que parece:
- Locales: se instalan y se ejecutan en tu ordenador. Funcionan con tus permisos: pueden leer tus ficheros y usar lo que tú puedes usar.
- Remotos: los publica el propio proveedor del sistema y te conectas a ellos por internet, normalmente autorizándolos con OAuth.
Según Anthropic, a finales de 2025 ya había más de 10.000 servidores MCP públicos activos. Esa abundancia es la gran virtud de MCP. Y, a la vez, su gran problema: instalar un servidor es tan fácil que, en pocos meses, nadie sabe cuántos hay conectados, quién los escribió ni a qué datos llegan.
MCP o API: la diferencia que casi nadie explica
MCP no sustituye a las API. Se apoya en ellas. La diferencia está en para quién está pensada cada una.
- Pensada para. API: un programador que escribe código contra ella. MCP: un modelo de IA que decide qué usar en tiempo real.
- Cómo se descubre. API: leyendo su documentación. MCP: el cliente le pregunta al servidor qué sabe hacer.
- Formato. API: propio de cada sistema. MCP: el mismo para todos los servidores.
- Integración. API: una por cada pareja aplicación–sistema. MCP: un servidor por sistema, válido para cualquier cliente.
- Quién decide la llamada. API: el código, de forma determinista. MCP: el modelo, a partir de un texto descriptivo.
La última fila es la que cambia el juego. Con una API, un programador decide exactamente qué se llama y cuándo, y lo hará igual mil veces. Con MCP, lo decide un modelo de lenguaje leyendo una descripción. Eso da una flexibilidad enorme. Y también abre la puerta a todo lo que viene a continuación.
Ventajas y limitaciones de MCP
MCP es un gran avance. Pero no es magia, y conviene conocer las dos caras antes de conectarlo a nada importante.
Ventajas
- Estándar abierto, gobernado por una fundación y adoptado por los grandes asistentes
- Una integración sirve para todos los asistentes compatibles
- Descubrimiento automático: el asistente sabe qué puede hacer sin programar nada
- Ecosistema enorme: miles de servidores listos para usar
- Local o remoto, según lo que necesites
Limitaciones
- El modelo decide qué herramienta usa: es flexible, pero no determinista; puede equivocarse de herramienta
- Cada herramienta ocupa contexto: con muchos servidores, el agente gasta tokens y elige peor (lo contamos aquí)
- La seguridad depende de cada servidor: el protocolo define cómo autorizar, no qué se puede ver
- Calidad muy desigual: cualquiera puede publicar un servidor, bien o mal hecho
- Sin registro por defecto: si el servidor no lo hace, nadie sabe después qué datos se consultaron
La conclusión de esta tabla es sencilla: MCP te da la conexión. El control lo tienes que poner tú.
Lo que MCP no decide
Volvamos al cliente López, al que ya conoces si leíste Soy un agente. El equipo comercial quiere que un agente prepare la reunión de mañana. Alguien conecta por MCP el CRM, el ERP y la carpeta de contratos. En diez minutos, funciona.
Ahora mira lo que ha pasado por debajo. El agente puede leer todo lo que la credencial de cada servidor permite leer: López, sí, pero también el resto de clientes, los márgenes, quizá las condiciones de otros contratos. Nadie ha decidido que el agente que prepara una reunión comercial deba ver eso. Simplemente, nadie ha decidido lo contrario.
El riesgo de MCP no está en el protocolo. Está en lo que se conecta y en cómo se conceden los permisos. OWASP, la referencia mundial en seguridad de aplicaciones, ya mantiene un Top 10 de riesgos propios de MCP. Estos son los que más pesan cuando el agente llega a datos de negocio:
- Tokens y secretos mal gestionados: credenciales fijas o de larga duración que acaban en registros, en el contexto del modelo o en manos de un atacante.
- Permisos que crecen solos: accesos concedidos «de momento» que nadie retira y dan al agente más alcance del que su tarea necesita.
- Herramientas envenenadas: una herramienta, o su descripción, manipulada para meter instrucciones o datos falsos en el contexto del agente.
- Inyección de prompts por contenido: un documento, un correo o una web con instrucciones ocultas que el agente lee y obedece.
- Autenticación y autorización insuficientes: servidores que no comprueban quién llama ni qué puede hacer.
- Falta de auditoría: nadie puede reconstruir después qué datos consultó el agente, para quién y por qué.
- Servidores en la sombra: servidores instalados por cuenta propia, fuera del inventario de la empresa.
- Exceso de contexto compartido: el agente recibe muchos más datos de los que necesita para responder.
Fíjate en lo que tienen en común: ninguno se resuelve pidiéndole al modelo que se porte bien. Una instrucción en el prompt es una sugerencia que el modelo puede ignorar y que un atacante puede anular. Lo explicamos a fondo en Guardrails y seguridad del dato: lo que vigila lo que el agente dice no gobierna aquello a lo que accede.
Buenas prácticas para usar MCP
Esta es la parte que casi nadie cuenta. La dividimos en dos: lo que conviene hacer si usas MCP en tu día a día, y lo que hace falta cuando lo despliega una empresa.
Si usas MCP en tu día a día (Claude, ChatGPT, Cursor…)
- Instala solo servidores de fuentes fiables. Los oficiales del proveedor del sistema o los de repositorios con mantenimiento visible. Recuerda que un servidor local se ejecuta en tu ordenador, con tus permisos.
- Mira qué herramientas trae y desactiva las que no uses. Menos herramientas es un agente más rápido, más barato, que elige mejor y que tiene menos superficie de ataque.
- Dale el mínimo permiso posible. Si solo necesitas leer, usa una credencial de solo lectura. Si puedes, una cuenta separada para el agente.
- No pegues contraseñas ni tokens en el chat ni en ficheros de configuración que compartas o subas a un repositorio.
- No desactives las confirmaciones. La mayoría de asistentes te piden permiso antes de una acción que escribe, envía o borra. Esa pausa es tu último control: léela antes de aceptar.
- Desconfía del contenido que lee el agente. Una web, un PDF o un correo pueden llevar instrucciones ocultas. Si el agente propone algo que no le has pedido, para.
- Haz limpieza. Actualiza los servidores y quita los que ya no usas.
Si lo despliega una empresa
- Un solo punto de acceso gobernado a los datos. En lugar de un servidor MCP por sistema, cada uno con sus permisos, el agente pregunta a una única capa que conoce todos los datos y aplica la misma política. Es la idea de centralizar, relacionar y describir los datos antes de que el agente pregunte.
- Identidad real de quien pregunta. La especificación de MCP basa la autorización en OAuth 2.1 y prohíbe expresamente el token passthrough: un servidor no puede reenviar a otro sistema la credencial que recibió. Cada acceso tiene que saber qué agente pregunta y en nombre de quién.
- Mínimo privilegio por tarea, no por agente. El agente que prepara la reunión con López no necesita ver nóminas, aunque tenga acceso técnico al sistema donde están. El permiso se decide en cada consulta.
- La autorización, en la infraestructura y no en el prompt. Quien decide si un dato es accesible es un sistema determinista, por debajo del modelo. Con la misma identidad, la misma tarea y el mismo dato, la respuesta es siempre la misma.
- Registro inmutable de cada acceso. Quién preguntó, qué datos se devolvieron, bajo qué política y cuándo. Sin ese registro no hay forma de responder a un incidente ni de cumplir con normas como el RGPD, DORA o el EU AI Act.
- Respuestas con su linaje. Cada dato que llega al agente debería traer de dónde viene. Si no, el agente acaba infiriendo sobre inferencias y nadie puede comprobar sus respuestas.
- Inventario de servidores. Qué servidores MCP hay conectados, quién los aprobó y a qué sistemas llegan. Lo que no está en el inventario, no se conecta.
Cómo lo resuelve Opendome
Opendome tiene su propio servidor MCP, construido precisamente sobre estas reglas. Funciona así:
- Conecta identidades, no solo agentes. Por el mismo MCP preguntan usuarios, agentes o sistemas, y cada uno lo hace con su identidad. Siempre se sabe quién pregunta.
- Filtra cada acceso con las políticas. Antes de tocar el dato, cada consulta se compila con la política que le aplica: filas, columnas y contenido quedan filtrados en la propia consulta. Es lo que llamamos el Modelo de Celda: el acceso se autoriza por identidad, tarea, entidad y campo exacto, y lo impone la infraestructura, no el prompt.
- Registra cada acceso de forma inmutable. Quién preguntó, qué se devolvió y bajo qué política, en un registro que no se puede alterar después.
- Devuelve el resultado con el conjunto de datos usado y su linaje. El agente no recibe solo una respuesta: recibe qué datos se usaron para construirla, de qué sistema viene cada uno, cuándo se registró y qué transformaciones ha sufrido. Cualquier afirmación del agente se puede rastrear hasta el dato que la sustenta.
El agente conserva toda la flexibilidad de MCP. Lo que deja de depender de él son los permisos, el registro y la trazabilidad. Puedes ver cómo encaja todo en Tecnología y en nuestro centro de seguridad.
La conclusión
MCP ha resuelto en dos años un problema que la industria arrastraba desde siempre: conectar la IA a los sistemas sin una integración a medida para cada combinación. Merece la pena entenderlo, porque va a estar en todas partes.
Lo que no resuelve —ni pretende resolver— es quién puede ver qué. Esa decisión sigue siendo tuya. Y no se toma en el prompt.
Conectar un agente por MCP es fácil. Conectarlo bien exige decidir los permisos fuera del modelo, registrar cada acceso y saber de dónde viene cada dato. Quien lo haga así desde el principio podrá multiplicar sus agentes sin multiplicar el riesgo.
Si estás conectando agentes a los datos de tu empresa y quieres hacerlo bien desde el principio, hablemos.
Opendome da a cualquier agente, de cualquier proveedor, un único punto de acceso por MCP a los datos de la empresa: centralizados, relacionados y descritos, con cada acceso filtrado por política, registrado de forma inmutable y devuelto con su linaje. La flexibilidad de MCP, sin renunciar al control.
Fuentes
- Model Context Protocol, especificación oficial (arquitectura, herramientas, recursos y prompts; JSON-RPC 2.0) — https://modelcontextprotocol.io/specification/latest
- MCP, transportes (stdio y Streamable HTTP) — https://modelcontextprotocol.io/specification/latest/basic/transports
- MCP, autorización (OAuth 2.1; prohibición del token passthrough) — https://modelcontextprotocol.io/specification/latest/basic/authorization
- MCP, buenas prácticas de seguridad (confused deputy, token passthrough, secuestro de sesión) — https://modelcontextprotocol.io/specification/latest/basic/security_best_practices
- Anthropic, Introducing the Model Context Protocol (25/11/2024) — https://www.anthropic.com/news/model-context-protocol
- Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation (09/12/2025; más de 10.000 servidores públicos activos) — https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
- OWASP MCP Top 10 — https://owasp.org/www-project-mcp-top-10/
