¿Qué es MCP?
Conocimiento, datos e integración
MCP significa Model Context Protocol. Es un protocolo abierto para conectar aplicaciones y asistentes de IA con herramientas externas, fuentes de datos y contexto reutilizable de forma más estandarizada. En lugar de construir una conexión completamente a medida entre cada cliente de IA y cada sistema empresarial, MCP define un patrón común para que esos sistemas puedan describir capacidades e intercambiar información. Eso no convierte a MCP en un adaptador mágico ni en un estándar empresarial garantizado. Significa que ahora existe un protocolo compartido que puede reducir la fricción de integración si se adopta y gestiona con sensatez.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
La traducción práctica para los líderes es sencilla. Si una API es la interfaz hacia un sistema específico, MCP es con frecuencia el patrón que permite a un host de IA descubrir y utilizar herramientas o contexto que pueden estar por encima, junto a o detrás de esas APIs. En otras palabras, MCP no suele reemplazar a las APIs. Más bien orquesta el acceso a capacidades que, en última instancia, están respaldadas por APIs, bases de datos, sistemas de archivos, servicios de búsqueda u otras tecnologías existentes.
Esa distinción importa porque gran parte del debate actual sobre MCP mezcla valor real con exageración. El valor es genuino: un protocolo puede reducir la fricción de conectar asistentes a fuentes y herramientas aprobadas. La exageración aparece cuando se habla como si un protocolo por sí solo resolviera la confianza, los permisos, la madurez o el riesgo operativo. No es así. MCP puede simplificar los patrones de conexión. No puede decidir qué debe tener permitido hacer un asistente, si una fuente es fiable o si el resultado debe aceptarse sin revisión.
Por qué importa
¿Por qué importa ahora? Porque muchos despliegues de IA se detienen en la frontera entre "demo interesante" y "trabajo útil". Los equipos pueden lograr que un modelo hable con fluidez, pero en el momento en que quieren que consulte el sistema de tickets, busque orientación interna, abra una tarea, inspeccione registros o trabaje dentro de un flujo de trabajo gobernado, se topan con fricción de integración. El atractivo de MCP es que ofrece una forma común de exponer esas capacidades a los hosts de IA sin crear un contrato personalizado nuevo para cada combinación.
Eso puede ser útil para el acceso al conocimiento interno, la recuperación gobernada, los asistentes de programación, los copilotos de soporte y los flujos de trabajo más agénticos. Un equipo puede querer que un asistente busque documentación aprobada, otro que llame a una herramienta de consulta de casos, y un tercero que ejecute una acción interna restringida. Si cada conexión se construye de forma diferente, la revisión de seguridad y el mantenimiento se vuelven lentos. Un protocolo estandarizado puede hacer que la forma de esas integraciones sea más coherente, lo que beneficia tanto a quienes las construyen como a quienes las operan.
Pero el lado del riesgo crece con la comodidad. Una vez que un host de IA puede acceder a herramientas y sistemas en vivo, la organización ha abierto una superficie de acción más amplia. El Centro Nacional de Ciberseguridad del Reino Unido ha advertido que los sistemas agénticos aumentan el riesgo porque pueden tener un acceso más amplio al sistema, comportarse de formas más difíciles de predecir y actuar más rápido de lo que los humanos pueden revisar de forma significativa. MCP no crea esos problemas por sí solo, pero con frecuencia se sitúa exactamente donde esos problemas se vuelven operativos.
Cómo funciona
A nivel de arquitectura, MCP utiliza un patrón de host, cliente y servidor. El host es la aplicación de IA con la que interactúa el usuario. Puede ser un cliente de chat, un entorno de programación u otra superficie de asistente. El host crea clientes que mantienen conexiones con los servidores MCP. Esos servidores proporcionan capacidades y contexto. La especificación oficial describe la comunicación mediante mensajes JSON-RPC y la negociación de capacidades entre los componentes.
El lado del servidor puede exponer varios tipos de primitivas. Las herramientas son funciones que el modelo puede invocar, como consultar un sistema, activar un cálculo o llamar a otro servicio. Los recursos son elementos de datos o contexto, como archivos, esquemas o información específica de la aplicación, que pueden presentarse o adjuntarse para su uso. Los prompts son flujos de trabajo o instrucciones con plantilla que el servidor suministra para que los usuarios los invoquen. Esto importa porque "conectado a MCP" no siempre significa lo mismo. Un despliegue puede ofrecer solo herramientas. Otro puede exponer también recursos y prompts. Un tercero puede añadir capacidades de interfaz interactiva mediante soporte específico del producto.
El modelo de control también varía según la primitiva. En la especificación, los prompts están diseñados para ser controlados por el usuario. Los recursos son gestionados por la aplicación. Las herramientas son controladas por el modelo, y la especificación recomienda mantener a una persona en el bucle con la capacidad de denegar invocaciones de herramientas. Eso es una pista de diseño útil para los líderes no técnicos: no todas las capacidades deben dejarse a la elección automática del modelo. Algunas acciones merecen confirmación, especialmente cuando se trata de acceso de escritura, efectos externos o datos regulados.
La autorización es otra área donde la madurez importa. La especificación incluye un marco de autorización para transportes basados en HTTP y lo alinea con patrones de identidad establecidos como el descubrimiento OAuth y los metadatos de recursos protegidos. Al mismo tiempo, la especificación deja claro que el soporte de autorización es opcional y específico del transporte. En la práctica, eso significa que compradores y desarrolladores aún deben hacer preguntas difíciles sobre identidad, gestión de tokens, acceso delegado, consentimiento y revocación. La existencia de una especificación no elimina la necesidad de un diseño de acceso empresarial.
También existe una diferencia operativa entre servidores locales y remotos. Un servidor local puede ejecutarse en la máquina del usuario y puede ser útil para tareas de alcance reducido, como el acceso a repositorios o archivos. Un servidor remoto puede atender a muchos clientes a través de HTTP y puede ser más fácil de gobernar de forma centralizada. Ninguno de los dos modelos es automáticamente más seguro. Los servidores locales amplían lo que se ejecuta en el endpoint. Los servidores remotos crean dependencias de red claramente visibles. La elección correcta depende del flujo de trabajo, el límite de confianza y el modelo de control.
Dónde aparece en flujos de trabajo reales
Un buen ejemplo de flujo de trabajo es el soporte interno. Imaginemos un asistente de operaciones de servicio utilizado por el personal que gestiona escalaciones de clientes. A través de MCP, el host podría exponer una herramienta de consulta de tickets de solo lectura, un recurso con la política de escalación vigente y una plantilla de prompt para resumir el traspaso de un caso. Eso es mucho más útil que una ventana de chat genérica. Pero solo funciona bien si el asistente está limitado a las cuentas necesarias, si sus resultados quedan registrados y si cualquier acción de escritura sigue requiriendo confirmación humana.
Un segundo ejemplo es la entrega de software. Un asistente de programación en un IDE puede usar MCP para inspeccionar incidencias del repositorio, consultar registros de despliegue, obtener documentación de API y ejecutar utilidades relacionadas con pruebas. Esto puede acelerar el triaje y la depuración. También puede crear un modo de fallo grave si se confía en el servidor equivocado, si una herramienta devuelve contenido manipulado o si se permite al asistente modificar recursos orientados a producción sin revisión. El protocolo facilita que la conexión exista; no elimina la necesidad de separación de entornos ni de puertas de aprobación.
Un tercer ejemplo es el trabajo de conocimiento en finanzas o compras. Un asistente puede buscar en un conjunto gobernado de recursos con políticas, datos de proveedores y plantillas aprobadas, y luego sugerir un borrador de respuesta o rellenar previamente una solicitud con los datos recuperados. En ese modelo, MCP puede ser genuinamente útil porque mantiene la interacción vinculada a los sistemas fuente actuales en lugar de a lo que el personal decida pegar en el chat. Pero el patrón más seguro suele ser restringido y consciente del rol: leer la política, sugerir el borrador, pedir a la persona que apruebe el siguiente paso.
Malentendidos frecuentes
El malentendido más común es que MCP es el nuevo nombre de las APIs. No lo es. Las APIs siguen siendo la interfaz subyacente de muchos sistemas empresariales. MCP suele situarse un nivel por encima, empaquetando herramientas y contexto para los clientes de IA y coordinando cómo los alcanza un host. Otro malentendido es que MCP es simplemente RAG con otro nombre. Tampoco. RAG es un patrón de recuperación. MCP puede ayudar a exponer recursos o herramientas utilizados en la recuperación, pero es más amplio que la recuperación y puede incluir acciones además de contexto.
También es un error pensar que protocolo abierto equivale a seguridad resuelta. La inyección de prompts sigue siendo un riesgo central porque los sistemas de IA no separan con firmeza las instrucciones del contenido no fiable. Un servidor MCP puede exponer recursos o devolver resultados de herramientas que pasan a formar parte del contexto del modelo. Si esas entradas contienen instrucciones maliciosas, el asistente puede ser manipulado a menos que el sistema más amplio aplique límites sensatos. El modelo mental correcto no es "MCP hace que la IA agéntica sea segura". Es "MCP le da a la IA agéntica otra superficie de conexión que debe ser gobernada".
Un último malentendido es tratar el soporte actual de los productos como uniforme. No lo es. Los principales clientes ya documentan el soporte de MCP, pero los conjuntos de funciones varían. Algunos admiten herramientas, recursos y prompts. Algunos admiten solo herramientas. Algunos admiten flujos HTTP remotos y patrones de autorización basados en OAuth. Otros no. Esa variación es normal para un estándar emergente, pero significa que el diseño de adquisiciones y pilotos debe basarse en el producto host específico, no solo en la marca del protocolo.
Riesgos y límites
Esta desigualdad se refleja claramente en la documentación pública de los productos. La documentación oficial de las principales herramientas muestra que MCP ya está soportado en algunos asistentes de IA y entornos de desarrollo, pero no siempre de la misma manera. VS Code documenta soporte para herramientas, recursos, prompts y aplicaciones interactivas. GitHub Copilot documenta el soporte de MCP y los controles empresariales, pero el agente en la nube de Copilot actualmente solo admite herramientas y no admite servidores MCP remotos basados en OAuth. OpenAI documenta tanto servidores MCP remotos como conectores gestionados. Esas son señales de un impulso significativo, pero también señales de que los compradores deben verificar capacidad por capacidad qué admite realmente un host determinado.
Las preocupaciones de seguridad no son teóricas. Los límites de las fuentes importan. Los equipos necesitan saber qué servidores están permitidos, qué herramientas están expuestas, qué acciones son reversibles, qué recursos son fiables y qué ocurre cuando el modelo tiene incertidumbre. Deben revisar los servidores de terceros con el mismo cuidado con el que revisarían cualquier componente de integración. También deben decidir qué se registra: la solicitud del usuario, la invocación de la herramienta, el servidor utilizado, la respuesta recibida, el paso de aprobación humana y la acción resultante. Sin eso, la revisión de incidentes y la rendición de cuentas son débiles.
La inyección de prompts merece atención especial. MCP puede mejorar la interoperabilidad, pero no cambia el hecho subyacente de que un modelo de lenguaje grande puede verse influenciado por contenido hostil procedente de un documento, una página web, una entrada de base de conocimiento o una respuesta de herramienta. Por esa razón, el principio de mínimo privilegio importa más, no menos. Si una ejecución comprometida o manipulada solo puede leer un conjunto reducido de recursos de bajo riesgo, el daño queda acotado. Si puede escribir ampliamente en sistemas de finanzas, servicio e identidad, el problema es mucho más grave.
También existe un límite de madurez del proveedor. Algunos productos pueden retener datos de forma diferente, admitir solo subconjuntos de la especificación o exponer controles de administración limitados. MCP es suficientemente prometedor como para que los equipos lo aprendan. Aún es suficientemente joven como para que los equipos no asuman consistencia.
Qué deben hacer los líderes a continuación
Los líderes que estén considerando MCP deben resistir la tentación de empezar con la automatización más amplia posible. Conviene comenzar con un flujo de trabajo de bajo riesgo y orientado a la lectura donde un mejor contexto claramente ayudaría al personal. Hay que elegir un host con controles visibles y un servidor de alcance reducido. Preguntar qué funciones de MCP están realmente soportadas en el producto elegido: ¿solo herramientas, o también recursos y prompts? ¿Transporte local o remoto? ¿Qué modelo de autorización se utiliza? ¿Cómo se almacenan los tokens? ¿Puede limitarse el acceso por rol, proyecto o entorno?
Luego hay que añadir salvaguardas prácticas. Mantener las herramientas de escritura detrás de la aprobación humana. Preferir el mínimo privilegio y las listas de permitidos frente al acceso amplio. Separar los servidores de prueba de los de producción. Aislar los servidores locales en un entorno de pruebas donde el host lo permita. Mantener un inventario de servidores aprobados y sus responsables. Probar escenarios adversariales, incluida la inyección de prompts a través de contenido recuperado y descripciones de herramientas no seguras. Planificar la desconexión además de la incorporación, porque el acceso obsoleto de conectores es un riesgo operativo real.
Gestionado de esta manera, MCP puede ser útil sin romantizarlo. Es un patrón de conexión prometedor en un ecosistema que claramente quiere más interoperabilidad entre los hosts de IA y los sistemas empresariales reales. También es suficientemente temprano como para que el soporte varíe, los controles difieran y las preguntas de gobernanza sigan importando más que los eslóganes. Para la mayoría de las organizaciones, eso significa pilotar con cuidado, aprender los límites y tratar MCP como una capa de integración que merece la misma seriedad que se aplicaría a cualquier otra vía de acceso a sistemas en vivo.
¿Tiene alguna pregunta o sugerencia, o desea entender cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es MCP un reemplazo de las APIs?
No. Las APIs siguen haciendo el trabajo subyacente de exponer datos y operaciones de los sistemas empresariales. MCP con frecuencia utiliza o envuelve esas capacidades para que los hosts de IA puedan descubrirlas y usarlas a través de un protocolo más estandarizado. Si se eliminaran las APIs, bases de datos o archivos subyacentes, MCP por sí solo no los recrearía mágicamente.
¿Debería una organización pequeña o mediana adoptar MCP ahora?
Posiblemente, pero generalmente para un caso de uso concreto más que como una apuesta de plataforma amplia. MCP ya es útil en algunas herramientas y flujos de trabajo, especialmente cuando el mismo asistente necesita acceso gobernado a contexto externo o utilidades. El enfoque sensato es probar el soporte, los permisos, el registro y los controles de revisión en un escenario acotado antes de ampliar.
¿Puede usarse MCP de forma segura con sistemas internos y datos privados?
Puede, pero solo si se trata como un patrón de conexión gobernado y no como una función de conveniencia. Hay que decidir si el servidor es local o remoto, cómo se gestiona la identidad, qué datos se exponen, qué acciones están permitidas, cómo funcionan las aprobaciones y qué se registra. La pregunta sobre seguridad tiene que ver principalmente con el alcance, el control y la monitorización, no con el acrónimo en sí.
Fuentes
Model Context Protocol: Specification - Core description of MCP, JSON-RPC communication, hosts, clients, servers, features and security notes.
Model Context Protocol: Architecture - Host-client-server architecture, security boundaries and host responsibilities.
Model Context Protocol: Resources - Definition of resources and their application-driven interaction model.
NIST NCCoE: Accelerating the Adoption of Software and AI Agent Identity and Authorization - Claims about agent identity, authorisation, least privilege, auditing, prompt injection and MCP's relevance to agentic architectures.
UK National Cyber Security Centre: Thinking carefully before adopting agentic AI - Claims about broader access, unpredictability, faster action and governance risks in agentic systems.
UK National Cyber Security Centre: Prompt injection is not SQL injection - Claims about prompt injection as a distinct and serious control problem for generative AI systems.