Model Context Protocol — MCP

Problema que resuelve

Model Context Protocol es un protocolo abierto de interoperabilidad que conecta aplicaciones AI con capacidades y contexto externos mediante interacciones estandarizadas entre clientes y servidores. El contrato permite describir y utilizar ciertas capacidades sin diseñar una integración completamente distinta para cada combinación de aplicación y proveedor. La definición conserva ese propósito sin depender de un producto, SDK o revisión particular.

El problema no consiste solamente en llegar a una URL. Una aplicación necesita saber qué se ofrece, cómo solicitarlo y cómo interpretar respuestas o errores. MCP proporciona semántica compartida para esas interacciones; la lógica comercial y los efectos del sistema conectado siguen perteneciendo a su implementación. Un servidor puede adaptar APIs existentes sin reemplazarlas ni convertir cualquier endpoint HTTP en MCP.

En un repositorio .NET, el agente puede necesitar consultar un issue o recuperar documentación de un servicio. MCP puede ofrecer una frontera común para esas capacidades. No determina si conviene consultarlas, qué evidencia basta para corregir el defecto o si el usuario autorizó modificar el servicio. Interoperabilidad facilita comunicación; la calidad y autoridad del trabajo necesitan contratos adicionales.

Especificación vigente y evolución

Consulta fechada 2026-10-27: la revisión publicada de referencia es 2026-07-28. El proyecto aparece en AAIF, bajo Linux Foundation, y tiene su propia gobernanza técnica. No se define aquí como un producto de su proveedor de origen ni como un framework para construir agentes.

El changelog describe un cambio sustancial respecto de 2025-11-25: requests autocontenidos, sin el handshake initialize ni sesiones implícitas del protocolo. Roots, Sampling y Logging quedan deprecados; deprecación no significa eliminación inmediata. Estos hechos son versionados. Un tutorial de una revisión anterior puede ser correcto para ella y equivocado si se aplica literalmente al contrato actual.

El ID y el título del documento no incluyen esa revisión. La identidad del conocimiento permanece estable mientras cambian detalles del protocolo. La versión de un SDK tampoco identifica automáticamente qué revisión soporta una integración. Para evaluar compatibilidad interesa la versión efectiva de los mensajes y las capacidades admitidas, además de la biblioteca instalada.

Host, Client y Server

La arquitectura oficial distingue tres roles. Host es la aplicación que coordina el uso de MCP, contexto y políticas. MCP Client es el participante del lado del host que comunica con un servidor. MCP Server expone capacidades mediante las primitivas del protocolo. Un host puede administrar varios clientes, cada uno asociado con un servidor.

Rol	Responsabilidad	Distinción necesaria
Host	Coordinar integración, contexto y decisiones de uso.	No es solamente el conector MCP.
Client	Hablar el protocolo con un servidor.	No equivale a toda la aplicación visible.
Server	Exponer capacidades y contexto compatibles.	No es automáticamente agente ni herramienta individual.

Son roles lógicos, sin imponer un despliegue idéntico para todos. Un proceso local y un servicio remoto pueden desempeñar el rol servidor. Un servidor HTTP genérico solo cumple ese rol MCP cuando implementa el contrato correspondiente. Un servidor que internamente utiliza AI sigue necesitando distinguir su implementación del rol que expone a sus clientes.

El host tampoco debería interpretarse como un canal ilimitado hacia toda la conversación. Decidir qué información comparte con un servidor es parte de su integración y política. Tener varios servidores conectados no implica que deban verse mutuamente ni recibir todo el contexto de desarrollo. La topología de comunicación y el alcance de datos son decisiones relacionadas pero diferentes.

Discovery y Versioned Capabilities

La compatibilidad actual se declara por request. server/discover permite conocer versiones, identidad y capacidades del servidor antes de otras operaciones, pero el cliente no está obligado a iniciar con esa llamada. El servidor acepta o rechaza la versión solicitada; no existe un handshake de negociación equivalente al de revisiones legacy.

Discovery de capacidades generales y listado de elementos concretos son niveles distintos. Saber que un servidor soporta Tools no identifica todavía cada herramienta disponible. Del mismo modo, encontrar un nombre en un catálogo no demuestra permiso para invocarlo. La disponibilidad puede depender de autorización y cambiar con el tiempo; un consumidor necesita interpretar la información bajo sus condiciones reales.

Versioned Capabilities no implica asignar una versión independiente obligatoria a cada herramienta. Abarca cómo evolucionan el protocolo y sus funciones, cómo se declara soporte y qué combinaciones funcionan. Compatibilidad sintáctica tampoco garantiza equivalencia comercial: dos herramientas con campos parecidos pueden tener efectos diferentes. El consumidor debe comprender esos efectos antes de utilizarlas en una tarea.

MCP Tools

Una MCP Tool es una capacidad invocable expuesta bajo las reglas de MCP. La especificación de Tools define descripción, schemas y operaciones de listado e invocación. El concepto general de herramienta es más amplio: una llamada local o una función integrada puede existir sin MCP. El protocolo tampoco impone una única interfaz de interacción humana.

En Commerce, una herramienta puede recuperar el detalle de un incidente o solicitar un cambio en un servicio. Ambas son invocaciones, pero sus consecuencias son diferentes. Un schema válido puede comprobar la forma de argumentos sin demostrar que el usuario autorizó ese cambio o que el destino es correcto. Los nombres y descripciones ayudan a interpretar; no sustituyen autorización ni conocimiento de efectos.

Un error del protocolo y un fallo de la operación requieren lecturas diferentes. No encontrar un método compatible no equivale a consultar correctamente y recibir un resultado comercial negativo. También puede perderse la respuesta después de una mutación. idempotency conserva la semántica necesaria antes de repetirla; envolver una API con MCP no crea ejecución exactamente una vez.

MCP Resources

Una MCP Resource expone contexto o datos direccionables mediante URI. La primitiva Resources permite ofrecer, por ejemplo, documentación o esquemas. Se orienta a acceso a información; una Tool representa una operación invocable. No debe reducirse la diferencia a extensiones de archivo ni asumir que todo dato leído es estático o confiable.

El host decide cómo incorporar el recurso a la tarea. Recuperar una descripción antigua de una tabla no demuestra que represente el estado actual del sistema. context-engineering-for-software-development permite examinar pertinencia, vigencia y procedencia sin convertir el protocolo en una estrategia completa de selección de contexto. Más recursos disponibles no garantizan mejores decisiones.

Resource tampoco significa recurso de infraestructura, permiso de lectura universal o archivo Markdown del Atlas. Es una primitiva protocolar con su contrato de identificación y acceso. La misma información podría llegar mediante otra interfaz; utilizar MCP cambia la frontera de interoperabilidad, sin modificar automáticamente su autoridad como evidencia o instrucción.

MCP Prompts

La primitiva Prompts expone plantillas de mensajes que un cliente puede descubrir y recuperar, incluyendo argumentos cuando corresponda. MCP Prompt nombra esa capacidad del protocolo. task-prompts nombra el encargo concreto de desarrollo y sus límites; persistent-instructions conserva guía reutilizable. Son funciones y niveles semánticos distintos.

Una plantilla expuesta podría ayudar a preparar un encargo de revisión. El trabajo actual todavía necesita identificar revisión, objetivo y scope. Recuperar la plantilla no la convierte en una política superior a la instrucción del usuario ni autoriza acciones adicionales. Tampoco todo prompt que recibe un modelo fue expuesto mediante MCP: prompt es un término más amplio y depende del contexto.

Requests, notificaciones y transportes

El modelo actual de mensajes inicia las interacciones desde el cliente. El servidor responde y puede enviar notificaciones asociadas. Cuando necesita input del cliente para continuar, el patrón Multi Round-Trip Requests devuelve esa necesidad y permite continuar con las respuestas correspondientes. No equivale a mantener el viejo canal de solicitudes JSON-RPC iniciadas por el servidor.

Los bindings de transporte publicados incluyen stdio y Streamable HTTP, además de admitir transportes personalizados que preserven la semántica. Transporte define entrega y framing; no redefine qué es una Tool o Resource. SSE puede transportar actualizaciones sin convertir streaming en la identidad del protocolo ni exigir una conexión permanente para todo uso.

Una llamada puede ser cancelada o interrumpida según su binding. Interrumpir la comunicación no constituye rollback de efectos ya realizados ni garantía de detener toda actividad externa. Terminar un proceso local y cerrar un stream remoto tienen consecuencias distintas. La aplicación necesita conservar qué observó, qué resultado desconoce y qué puede comprobar antes de continuar.

El núcleo stateless no obliga a que el negocio carezca de estado. Una operación puede producir un identificador explícito que otras llamadas utilicen. Lo que no corresponde es suponer que una sesión protocolar implícita conserva automáticamente la conversación o permisos entre requests. Las integraciones legacy necesitan tratamiento específico; no deben mezclarse sus garantías con las de la revisión moderna.

Tool Calling, Skills, Packages y APIs

Tool Calling describe una interacción donde el modelo solicita una invocación estructurada y el runtime media su ejecución. MCP puede aportar descubrimiento y acceso a la herramienta utilizada, pero no define todo ese loop. Puede haber Tool Calling sin MCP y MCP sin que cada operación sea seleccionada autónomamente por un modelo. No vuelve agentic una aplicación por conectarla a un servidor.

agent-skills aporta procedimientos reutilizables que pueden utilizar herramientas MCP. El procedimiento para investigar un incidente y la función que consulta el tracker tienen responsabilidades diferentes. Un servidor no se convierte en skill por exponer una herramienta, y una skill no se vuelve servidor por describir cómo llamarla. Tampoco se presupone un nuevo actor por cargar sus instrucciones.

agent-extension-packages puede distribuir configuración o componentes MCP. Packaging y protocolo siguen separados. Instalar un plugin no demuestra conexión, confianza o autorización del servicio. Una API existente puede quedar detrás de un adapter MCP; conservará su contrato comercial y sus controles. El protocolo no reemplaza REST en general ni elimina la necesidad de APIs especializadas.

Autorización, confianza y límites técnicos

La especificación de autorización define un flujo para transportes HTTP apoyado en estándares OAuth. Su soporte es opcional y stdio tiene otro tratamiento de credenciales. No corresponde afirmar que toda conexión MCP realiza el mismo login o que toda identidad autenticada dispone de autorización sobre cualquier operación.

agent-permissions-and-approval-boundaries distingue capacidades, autorización y aprobaciones adicionales. Discovery comunica lo soportado; autorización delimita lo permitido. El usuario puede autorizar investigar un fallo sin permitir mutaciones en producción. Un servidor que acepta técnicamente una llamada puede estar expuesto con una política demasiado amplia: respuesta exitosa y acción apropiada no son equivalentes.

agent-sandboxing conserva restricciones técnicas del entorno. Un servidor remoto puede actuar fuera del sandbox del agente y producir efectos con otra identidad. Un proceso local tampoco es confiable automáticamente: importa el código que ejecuta y los recursos accesibles. Conectar no crea aislamiento; localizar un componente en otra máquina no demuestra una frontera de seguridad adecuada.

La salida de tools, resources o prompts puede contener información no confiable. Incorporarla al contexto no debe elevarla a instrucción autoritativa. Prompt injection, tool abuse y supply chain risk son relaciones relevantes, sin materializar aquí sus canónicos. Validar un schema demuestra conformidad estructural dentro de su alcance, no seguridad, verdad o corrección del contenido.

Protocol Extensions y Skills Extension

Las extensiones de MCP agregan funciones opcionales al núcleo mediante capacidades identificadas. No equivalen a plugins de producto. Su existencia no exige que todos los participantes las soporten; compatibilidad del núcleo puede convivir con ausencia de una extensión necesaria para una tarea. La aplicación necesita detectar esa diferencia antes de depender de ella.

La Skills Extension oficial, io.modelcontextprotocol/skills, tiene especificación publicada; SEP-2640 figura Final en la consulta. Su snapshot estable utiliza MCP 2026-07-28. Expone discovery y lectura de Agent Skills mediante MCP; soporte de hosts y SDKs sigue evolucionando. No es una propuesta informal ni una primitiva obligatoria del core.

Agent Skill, Agent Skills specification y MCP Skills Extension conservan niveles distintos. La primera es capacidad/procedimiento; la segunda define su representación; la tercera permite exponer y recuperar esos artefactos por un protocolo. Leer SKILL.md no activa automáticamente la skill: el host aplica su carga y controles. La extensión tampoco promete ejecutar scripts o trasladar todas las características entre productos.

Comparación y composición con ACP y A2A

La tabla transpone los ejes para facilitar lectura. Resume responsabilidades desarrolladas en agent-client-protocol y agent2agent-protocol, sin declarar capas excluyentes ni una escala de madurez.

Eje	MCP	ACP	A2A
Frontera principal	Aplicación AI y capacidades/contexto.	Cliente/editor y coding agent.	Sistemas agentes interoperables.
Participantes	Host, Client, Server.	Client y Agent.	Client y Server/Remote Agent.
Contrato	Primitivas y mensajes para capacidades.	Sesiones, turnos, actividad e interacción.	Mensajes, tareas, estados y resultados.
Discovery	Versiones/capacidades y catálogos.	Inicialización y capacidades compatibles.	Agent Cards y capacidades anunciadas.
Relevancia en desarrollo	Consultar sistemas y contexto externo.	Integrar el agente con el entorno del usuario.	Solicitar trabajo a otro sistema agente.
Coexistencia	Puede combinarse con ambos.	Puede conectar un agente que use los otros.	El agente remoto puede usar MCP y otros clientes.
No define	Loop completo, autorización comercial o sandbox.	Corrección del agente ni aislamiento.	Estrategia completa de coordinación ni autoridad heredada.

Una composición posible para un repositorio .NET es la siguiente. Los enlaces representan contratos de interacción, sin exigir que cada caja sea un proceso separado:

flowchart TB
    Developer[Developer] --> Client[IDE / Agent Client]
    Client <-->|ACP| Coding[Coding Agent + Harness]
    Coding <-->|MCP| Server[MCP Server]
    Server --> Systems[Tools / Resources / APIs]
    Coding <-->|A2A| Other[Other Agent System]

El cliente recibe un encargo de revisar una migración. El agente consulta issues mediante MCP y solicita una revisión especializada a otro sistema mediante A2A. Cada frontera necesita datos, permisos y evidencia proporcionados al encargo. Ninguno de los tres protocolos es obligatorio para esa arquitectura: podrían usarse otras integraciones. La composición ilustra responsabilidades, sin prescribir un workflow de desarrollo.

Evaluar una integración concreta

Una revisión útil separa disponibilidad, compatibilidad, autorización y resultado. Si el host no puede iniciar un proceso servidor, todavía no se observó su comportamiento protocolario. Si recibe una respuesta de versión incompatible, hay comunicación pero no un contrato compartido suficiente. Si lista una herramienta pero su invocación es rechazada, el diagnóstico necesita examinar autorización y condiciones de la operación. Llamar a todo «MCP no funciona» oculta dónde está la incertidumbre y puede llevar a cambiar componentes que estaban cumpliendo su contrato.

En la composición de Commerce, el equipo puede autorizar consulta de un issue y documentación, sin abrir acceso a datos productivos. El host debe disponer de herramientas con ese alcance real. Si una herramienta de consulta también permite mutaciones, el nombre amigable no reduce técnicamente esa capacidad. Si el servidor usa otra identidad para llegar a una API, hay otra frontera que revisar. La conectividad uniforme ayuda a integrar; no sustituye decisiones sobre credenciales, destino y efectos.

También interesa comprobar la interpretación del resultado. Una consulta puede devolver datos válidos del repositorio equivocado o documentación de una revisión anterior. El intercambio puede ser conforme al protocolo mientras la evidencia sea inadecuada para la tarea. El agente necesita contrastar qué recibió con el encargo y comunicar límites. Este análisis no exige agregar una plataforma de integración al Atlas: explica qué afirmaciones pueden sostenerse responsablemente al evaluar una implementación existente.

Relaciones en el Atlas

agent-harness puede alojar clientes MCP y mediar su uso; no es el protocolo. agent-execution-environment sitúa recursos y efectos; no queda definido por el transporte. coding-agent puede utilizar estas capacidades sin que soporte universalmente MCP. development-context-and-execution-records ayuda a conservar qué se solicitó y observó, sin convertir éxito protocolar en completion demostrada.

Interoperabilidad significa compartir un contrato de comunicación. Portabilidad significa poder trasladar artefactos o implementaciones entre sistemas. MCP puede mejorar la primera sin garantizar que prompts, skills, agentes o conducta migren sin adaptación. ai-assisted-software-engineering conecta este conocimiento con los artefactos existentes y los workflows futuros.

Fuentes

Fuentes primarias consultadas el 2026-10-27. Los ejemplos, distinciones y composición son síntesis editorial del Atlas; los requisitos del protocolo pertenecen a las revisiones citadas. No se instalaron servidores o SDKs.

• MCP: Specification 2026-07-28, changelog y gobernanza.
• Architecture, versioning, message patterns y transports.
• Tools, Resources y Prompts.
• Authorization, Extensions, Skills overview y Skills stable specification.
• AAIF: About, contexto institucional actual.