MCP explicado: qué conecta, qué no hace y dónde encaja

El Protocolo de Contexto de Modelo (MCP) es un protocolo abierto para conectar aplicaciones de IA a capacidades e información externas mediante contratos estandarizados de cliente-servidor. Un servidor MCP puede exponer herramientas, recursos y prompts; un host o cliente compatible con MCP descubre y utiliza esas capacidades en nombre de una aplicación de IA. MCP no requiere que el servidor ejecute su propio modelo de lenguaje, y no reemplaza el entorno de ejecución del agente, la autorización empresarial, el aislamiento de inquilinos, las API de aplicación ni la arquitectura de dominio detrás de las capacidades expuestas.

Qué estandariza realmente MCP

Antes de MCP, cada aplicación de IA podía integrar sistemas externos mediante su propio esquema de herramientas, formato de complementos, convención de autenticación y código de conexión. El mismo servicio podía necesitar adaptadores diferentes para un cliente de IA de escritorio, un agente de IDE y una aplicación personalizada.

MCP crea un límite de protocolo reutilizable. El sistema externo expone capacidades a través de un servidor MCP, mientras que los hosts de IA compatibles implementan un cliente MCP. Esto reduce el acoplamiento de integración entre la aplicación de IA y el proveedor subyacente de herramientas o datos.

El protocolo no estandariza toda la aplicación. Estandariza cómo se describen, descubren e invocan las capacidades a través de ese límite.

El ejemplo más simple

Supongamos que una aplicación de IA para programar necesita acceso a un directorio de proyecto local. Sin MCP, la aplicación podría implementar su propia integración de sistema de archivos directamente.

Con MCP, un servidor de sistema de archivos puede exponer capacidades como listar directorios, leer archivos aprobados o escribir dentro de un espacio de trabajo permitido. El host de IA se conecta a través de un cliente MCP y presenta esas capacidades al modelo o al entorno de ejecución del agente.

El servidor no necesita entender la solicitud en lenguaje natural del usuario. El host/modelo decide qué capacidad es útil; el servidor MCP ejecuta la solicitud estructurada bajo sus propias reglas de seguridad.

Dónde se detiene el ejemplo simple

MCP no define cómo el host elige una herramienta, cómo planifica un agente, cómo se modela un flujo de trabajo empresarial o cómo debería comportarse un objeto de dominio como una factura o un despliegue.

Un protocolo puede hacer que la integración sea interoperable mientras la aplicación subyacente sigue siendo incorrecta, insegura o mal diseñada. Una solicitud MCP perfectamente válida aún puede llamar a la capacidad empresarial equivocada.

El límite central es: MCP estandariza la semántica de integración, no la verdad de la aplicación ni la corrección del negocio.

La arquitectura MCP: host, cliente y servidor

Un host puede conectarse a múltiples servidores MCP, y un servidor MCP puede estar frente a uno o varios sistemas subyacentes. El host sigue siendo responsable de integrar los resultados de MCP en la aplicación de IA más amplia.

El servidor puede ser local al host, ejecutarse como un proceso separado o ser remoto a través de un transporte de red. La topología de alojamiento y la ubicación del modelo son decisiones independientes.

Las tres primitivas centrales del servidor

Herramientas: capacidades invocables

Las herramientas son operaciones estructuradas que un servidor MCP pone a disposición del host. Una herramienta tiene un nombre, una descripción y un esquema de entrada; las implementaciones modernas también pueden proporcionar salida estructurada.

Los ejemplos incluyen buscar en un repositorio, leer un registro de cliente, crear un ticket, ejecutar una compilación o enviar un mensaje. Las herramientas pueden ser de solo lectura o tener efectos secundarios.

Una buena superficie de herramientas MCP debería representar objetivos coherentes del usuario o del agente en lugar de reflejar mecánicamente cada punto final de API interno. Las operaciones con diferentes permisos, requisitos de confirmación o radio de impacto generalmente deberían ser herramientas separadas.

Recursos: contexto y datos legibles

Los recursos exponen datos o contenido que un cliente puede listar o leer. Encajan naturalmente cuando la operación semántica es «dame este artefacto o información» en lugar de «realiza esta acción».

Un URI de recurso no es una concesión de autorización. El servidor sigue siendo el propietario del control de acceso y debe verificar qué principal puede leer el objeto subyacente.

La revisión del protocolo del 28-07-2026 añade semántica de caché para las respuestas de listado y lectura de recursos, incluida la frescura y el alcance de la caché, lo que hace que el comportamiento de almacenamiento en caché sea más explícito.

Prompts: plantillas reutilizables

Los prompts MCP permiten que un servidor publique plantillas de prompts reutilizables para clientes compatibles. Esto puede mantener las instrucciones específicas del dominio cerca del proveedor de capacidades.

Un prompt proporcionado por un servidor MCP no supera automáticamente las instrucciones del sistema o de seguridad del host. El host decide cómo el material del prompt entra en su jerarquía de contexto.

Por lo tanto, el contenido de los prompts proporcionado por el protocolo debe tratarse como datos de capacidad con semántica de confianza explícita, no como autoridad de instrucción sin restricciones.

¿Herramienta o recurso?

¿Dónde está el modelo de IA?

MCP no requiere que el modelo se ejecute en el servidor MCP. El modelo puede estar alojado en la nube, alojado localmente, integrado en la aplicación de escritorio o accedido a través de otro proveedor.

El host normalmente posee la interacción con el modelo. El servidor MCP expone capacidad externa. Por lo tanto, un servidor MCP local puede ser utilizado por un host cuyo modelo se ejecuta en la nube, y un servidor MCP remoto puede ser utilizado por un host cuyo modelo se ejecuta localmente.

Si el propio servidor MCP llama internamente a un LLM, ese modelo forma parte de la implementación del servidor detrás del límite del protocolo; MCP no lo requiere.

MCP no reemplaza las API

Un servidor MCP a menudo envuelve API o servicios existentes. REST, GraphQL, SQL, llamadas a SDK y contratos de servicios internos pueden permanecer exactamente donde están.

MCP añade una capa de interoperabilidad orientada a la IA. La API de dominio subyacente puede seguir siendo el contrato de aplicación autoritativo para clientes deterministas ordinarios.

Por lo tanto, la arquitectura habitual es primero API/servicio, segundo capacidad seleccionada orientada a la IA — no “reemplazar cada API con MCP”.

MCP vs llamada a funciones

OpenAI actualmente expone servidores MCP remotos como un tipo de herramienta junto con la llamada a funciones ordinaria, búsqueda web, shell y otras herramientas. Esa implementación ilustra la relación arquitectónica: la conectividad MCP y la interfaz de llamada a herramientas del propio modelo pueden componerse.

MCP no crea el bucle del agente

Un agente de IA necesita un runtime que pueda decidir, invocar herramientas, observar resultados, actualizar el estado y continuar o detenerse. MCP puede proporcionar algunas de las herramientas y datos utilizados por ese bucle.

El servidor MCP no se convierte automáticamente en el planificador, el sistema de memoria o el orquestador. Esas responsabilidades normalmente permanecen en el host o en el runtime del agente.

Una aplicación no agéntica también puede usar MCP. Una llamada determinista a una herramienta MCP no requiere un agente autónomo de varios pasos.

MCP vs A2A

MCP conecta principalmente un host de IA o un agente con capacidades como herramientas, recursos y datos. A2A se orienta a la colaboración entre sistemas de agentes independientes.

Un agente remoto puede usar MCP internamente para acceder a bases de datos y herramientas mientras expone una interfaz A2A a otros agentes. Por lo tanto, los protocolos pueden estratificarse en lugar de sustituirse.

El artículo existente sobre la pila de protocolos es el responsable de la comparación más amplia entre MCP/A2A/UCP/AP2/A2UI; G02 sigue siendo la definición canónica de MCP.

El uso local y remoto de MCP tiene realidades de transporte diferentes

MCP puede conectarse a servidores locales y remotos. Las integraciones de escritorio locales suelen usar transportes a nivel de proceso como stdio; los servidores remotos usan transporte orientado a HTTP.

La revisión del 2026-07-28 hace que el núcleo del protocolo sea sin estado. Las solicitudes llevan la información necesaria para el manejo del protocolo en lugar de depender del modelo de sesión anterior a nivel de protocolo.

La revisión actual también coloca los nombres de métodos y capacidades en encabezados HTTP para que las pasarelas, WAF, limitadores de velocidad y balanceadores de carga puedan enrutar y medir el tráfico MCP de forma más natural.

Por qué importa la conciencia de la versión de MCP

La versión del SDK y la versión del protocolo también son cosas diferentes. El SDK actual de TypeScript v2 es la línea estable para la revisión del 2026-07-28, mientras que el anterior v1.x sigue siendo una línea de mantenimiento para el comportamiento de la era 2025.

La documentación de arquitectura debe registrar tanto la versión del SDK/biblioteca como la revisión del protocolo cuando el comportamiento de interoperabilidad dependa de ellas.

Qué cambió en MCP 2026-07-28

Roots, sampling y logging ya no son la dirección para nuevas implementaciones

La versión 2026-07-28 marca roots, sampling y logging como capacidades de protocolo obsoletas con una ventana de compatibilidad definida.

Los tutoriales más antiguos pueden seguir mostrando estas características como primitivas centrales. El nuevo trabajo de implementación debe seguir la especificación actual en lugar de copiar ciegamente diagramas de ciclo de vida antiguos.

La deprecación no significa eliminación inmediata. Significa que los nuevos sistemas deben evitar dependencias nuevas innecesarias sobre capacidades de las que el protocolo se está alejando.

El trabajo de larga duración no es lo mismo que la invocación ordinaria de herramientas MCP

Las operaciones de larga duración necesitan semántica de ciclo de vida más allá de un simple resultado inmediato de herramienta. En el ecosistema actual, Tasks se trasladó a una extensión MCP dedicada.

Esto refuerza un principio de diseño útil: el protocolo base no necesita absorber todas las preocupaciones del tiempo de ejecución del agente.

Una aplicación también puede mantener la propiedad del flujo de trabajo de larga duración enteramente en su propio tiempo de ejecución y usar herramientas MCP ordinarias como operaciones subyacentes.

MCP Apps extiende la capacidad de la interfaz de usuario sin redefinir el protocolo central

MCP Apps asocia experiencias de interfaz de usuario interactivas más ricas con herramientas MCP a través del modelo de extensión.

El host sigue controlando cómo se incrusta, se aísla y se protege esa interfaz de usuario.

Por lo tanto, el intercambio de capacidades centrales y la representación de la interfaz de usuario deben seguir siendo responsabilidades arquitectónicas separadas.

La autorización MCP no es su modelo de autorización completo

MCP remoto necesita mecanismos de autenticación y autorización a nivel de protocolo para que los clientes y servidores puedan establecer acceso confiable. La especificación actual continúa fortaleciendo el comportamiento relacionado con OAuth/OIDC.

Esa capa responde si un cliente tiene permitido conectarse o solicitar ámbitos de protocolo. No responde automáticamente si Alice puede reembolsar el pedido 123, si un agente puede escribir configuración de producción o si el Inquilino A puede leer datos del Inquilino B.

Esas decisiones de dominio pertenecen al modelo de autorización del servidor/aplicación y deben aplicarse antes de invocar la operación subyacente.

La identidad puede cruzar varios límites

Una solicitud MCP puede involucrar la aplicación cliente MCP, el humano que inició sesión, una identidad de agente/sesión y una cuenta de servicio posterior.

El servidor necesita una política explícita sobre en nombre de qué principal se realiza la operación. De lo contrario, una credencial de servicio poderosa puede convertirse en una ruta de diputado confundido.

Para uso empresarial, la correlación entre la identidad del usuario, la identidad del agente, la conexión MCP y la autorización posterior es tan importante como la compatibilidad del protocolo.

El aislamiento de inquilinos permanece fuera del descubrimiento de capacidades de MCP

Un servidor MCP multiinquilino debe aplicar el alcance del inquilino cuando lee o modifica recursos propiedad del inquilino. Devolver una herramienta llamada search_documents no define a qué inquilino pertenecen los documentos elegibles.

El alcance del inquilino debe derivarse de una identidad o membresía confiable y trasladarse a bases de datos, cachés, búsqueda vectorial, almacenamiento de objetos y API posteriores.

Recuperar contenido entre inquilinos y pedirle al modelo que no lo use ya es un fallo de aislamiento.

MCP no define la Fuente de Verdad

Un servidor MCP puede exponer una base de datos, un repositorio de documentos, un servicio de búsqueda web o un resumen generado por IA. El protocolo no declara qué fuente es autoritativa para una afirmación.

Las reglas de Fuente de Verdad pertenecen a la arquitectura de la aplicación o del dominio. El host o el servidor pueden codificar la autoridad mediante el diseño de herramientas, metadatos, políticas de acceso o validación, pero MCP por sí mismo no hace que una capacidad sea “verdadera”.

Por lo tanto, una herramienta puede ser perfectamente invocable a través de MCP y aun así devolver información obsoleta, secundaria o no autoritativa.

MCP e ingeniería de contexto

MCP puede aumentar las capacidades y la información disponibles para una aplicación de IA, pero la ingeniería de contexto sigue determinando qué llega al modelo.

Los catálogos de herramientas consumen contexto visible para el modelo en muchos hosts. Los resultados de las herramientas pueden ser grandes. Los recursos pueden ser numerosos. Un host necesita selección, filtrado, carga dinámica y compactación en lugar de exponer todo en cada turno.

Por lo tanto, la disponibilidad de capacidades y el contexto visible para el modelo deben tratarse como capas separadas.

Diseñar herramientas MCP en torno a resultados y límites de riesgo

Las aprobaciones pertenecen a la arquitectura de ejecución

Un host puede requerir la aprobación del usuario antes de invocar herramientas MCP seleccionadas. La integración MCP actual de OpenAI admite patrones de ejecución automática o con aprobación explícita.

La aprobación del host es útil, pero no debería ser la única protección del servidor, porque otro cliente MCP compatible puede usar un modelo de aprobación diferente.

Para acciones destructivas o con consecuencias financieras, utilice defensa en profundidad: contrato de herramienta claro, aprobación en tiempo de ejecución cuando corresponda, autorización del lado del servidor, validación de negocio y auditoría.

La observabilidad de MCP debe conectar las llamadas de protocolo con las acciones de dominio

Un rastro de MCP es más útil cuando puede correlacionarse con la llamada de aplicación subyacente, el cambio de base de datos o la transacción de negocio.

El ecosistema de 2026-07-28 estandariza las convenciones de propagación de W3C Trace Context, lo que facilita seguir una solicitud a través del host, cliente, servidor y servicios posteriores.

Los registros de protocolo por sí solos no son suficientes para operaciones con consecuencias. La evidencia de auditoría también debe registrar el principal relevante, el inquilino, el recurso objetivo, la aprobación y el cambio de estado resultante.

Lo que MCP no puede solucionar

Evidencia de implementación original: Aaasaasa AI Client

La aplicación puede ejecutar un endpoint MCP Streamable HTTP autenticado en loopback. El endpoint expone solo directorios seleccionados a través del broker central de permisos del espacio de trabajo.

El endpoint local y la ruta remota son preocupaciones separadas: el conector local puede enlazarse solo a loopback, mientras que un Secure MCP Tunnel puede hacer que el servicio MCP aprobado sea accesible para un cliente de IA externo permitido sin exponer toda la máquina local.

El modelo central de permisos distingue perfiles de solo chat, solo lectura, escritura de proyecto y directorio personalizado. Direct Chat no tiene acceso al sistema de archivos ni al shell; los tiempos de ejecución de agentes con capacidad de herramientas utilizan el perfil de permisos seleccionado.

Esta es una implementación directa del límite G02: MCP proporciona la conexión de capacidad estandarizada, mientras que el broker de permisos propiedad de la aplicación decide qué directorios puede exponer el servidor.

Cuándo MCP es una buena opción

Cuándo no necesita MCP

No agregues MCP solo porque la aplicación use IA. Si tu backend ya llama a una API interna y ningún cliente MCP independiente necesita esa capacidad, una función o llamada de servicio ordinaria puede ser más clara.

MCP aporta valor en un límite de interoperabilidad. Sin ese límite, el protocolo puede convertirse en una capa de adaptador innecesaria.

La pregunta arquitectónica no es "¿Este proyecto tiene IA?" sino "¿Se benefician hosts de IA y proveedores de capacidades que evolucionan de forma independiente de un contrato estándar?"

Lista de verificación de seguridad de MCP

Conceptos erróneos comunes

Una secuencia práctica de diseño de MCP

Lista de verificación de arquitectura de MCP

Casos límite y limitaciones

Un servidor MCP local por stdio puede tener poca exposición de red y seguir siendo peligroso si el proceso en sí tiene permisos excesivos de sistema de archivos o shell.

Un servidor MCP remoto puede exponer solo documentación pública o acciones empresariales altamente sensibles. "MCP remoto" dice poco sobre el riesgo sin el contexto de capacidad y autorización.

Algunos servidores pueden usar solo herramientas e ignorar recursos/prompts. La compatibilidad con MCP no requiere que cada primitiva opcional sea igualmente importante.

Un host puede traducir entre su propio modelo interno de herramientas y MCP. Es posible que los usuarios nunca vean directamente el límite del protocolo, lo cual es aceptable si la seguridad y la atribución siguen siendo claras.

MCP sigue evolucionando rápidamente. Las extensiones, los patrones de autorización, las API de los SDK y las convenciones del ecosistema pueden cambiar más rápido que la distinción arquitectónica central.

¿Qué cambiaría esta respuesta?

Las futuras revisiones de MCP pueden cambiar el ciclo de vida, los transportes, la autorización y los mecanismos de extensión. La revisión de julio de 2026 ya demuestra por qué las afirmaciones específicas de una implementación deben estar fechadas.

El límite canónico solo cambiaría si MCP se expandiera de un protocolo de interoperabilidad a un estándar de arquitectura de aplicación/agente de extremo a extremo. Eso no es lo que define el protocolo actual.

Para el trabajo de implementación, consulte siempre la especificación actual y la línea exacta del SDK en lugar de copiar ejemplos sensibles a la versión de tutoriales más antiguos.

Conocimiento canónico relacionado

MCP pertenece a la parte posterior de Agentic AI: primero comprenda el límite agente/tiempo de ejecución/herramienta, luego use MCP cuando las capacidades externas necesiten un contrato de protocolo portátil.

MCP también depende de RBAC y del aislamiento de inquilinos porque la exposición de capacidades a nivel de protocolo no determina la autorización de la aplicación.

El artículo más amplio sobre la pila de protocolos explica dónde se sitúa MCP junto a A2A, UCP, AP2 y A2UI. G02 sigue siendo la fuente canónica para MCP en sí.

Preguntas frecuentes

Glosario

Conclusión

MCP es más fácil de entender cuando su límite se mantiene estrecho: conecta aplicaciones de IA con capacidades externas a través de un protocolo estándar.

El modelo no tiene que residir en el servidor MCP. El servidor no se convierte en el tiempo de ejecución del agente. Una herramienta listada no se convierte en una acción empresarial autorizada. Y MCP no reemplaza la API subyacente, la Fuente de Verdad, el aislamiento de inquilinos ni la arquitectura de dominio.

Esa estrechez es la fortaleza del protocolo. MCP puede estandarizar cómo los sistemas de IA acceden a herramientas y datos, dejando la propiedad de la aplicación, la seguridad, la semántica empresarial y la elección del modelo en las capas que realmente las poseen.

Fuentes primarias y documentación actual

MCP evoluciona rápidamente, por lo que las afirmaciones sensibles a la versión en este artículo están vinculadas al estado del 8 de octubre de 2026. La sección Aaasaasa AI Client es evidencia de implementación original y está explícitamente limitada al alcance verificado del conector MCP y del intermediario de permisos.