MCP en 2026: qué cambia para conectar agentes con herramientas

Conectar una herramienta sin rehacer cada integración

Quieres que un asistente consulte tu calendario y que otro pueda utilizar esa misma conexión. MCP, Model Context Protocol, ofrece una forma común de comunicar aplicaciones de IA con servidores que exponen herramientas, datos y prompts.

La aplicación decide qué capacidades presenta al modelo y qué operaciones permite. Compartir una conexión no significa compartir todos los permisos, ni garantiza que el agente elija bien la herramienta.

Esta guía revisa la especificación 2026-07-28, publicada el 28 de julio. Separa los cambios ya publicados de las ideas del roadmap y los lleva a un ejemplo concreto.

Qué hacen la aplicación, el cliente y el servidor

La aplicación donde utilizas la IA es el host. Dentro de ella, el cliente MCP habla con un servidor que ofrece capacidades. Por ejemplo, ese servidor podría exponer una búsqueda de eventos. El cliente obtiene la lista de herramientas con tools/list y solicita una operación con tools/call.

Cada herramienta describe sus argumentos mediante un esquema. Eso permite saber qué información necesita una llamada, pero no demuestra que la consulta sea adecuada para tu tarea. Revisaría también qué devuelve el servidor y cómo lo presenta la aplicación antes de dejar que el modelo lo utilice.

Un ejemplo: consultar una agenda de conciertos

Imagina una agenda pública y una petición como «busca conciertos de jazz para el sábado». Es un ejemplo hipotético. El servidor podría ofrecer search_events para buscar por fecha y estilo, y get_event para consultar los detalles de un evento concreto. El agente buscaría candidatos y comprobaría horarios y lugar antes de preparar una respuesta con enlaces.

Diseñaría la respuesta para que una fecha ausente o una búsqueda vacía se indiquen claramente. El agente no debería convertir «no hay resultados» en «no habrá conciertos». También distinguiría un horario publicado de una disponibilidad que el servicio no puede comprobar.

Si más adelante añades reserve_place para reservar una plaza, tendrá una responsabilidad diferente. Dar acceso a la agenda no concede permiso para reservar. Separaría esa acción, verificaría la identidad y los permisos en el servicio y pediría la confirmación correspondiente antes de ejecutarla.

Qué cambia al desaparecer la sesión del protocolo

La publicación 2026-07-28 elimina el intercambio initialize/initialized y Mcp-Session-Id. Cada petición lleva su versión y las capacidades necesarias. El anuncio explica que esto facilita repartir peticiones entre instancias sin mantener una sesión del protocolo compartida. Antes de migrar, comprueba si tu integración dependía de ese intercambio o del identificador anterior.

La aplicación puede seguir guardando estado. Si el ejemplo evoluciona hacia una selección de conciertos favoritos, podrías guardar esa selección con un identificador propio. El servicio tendría que comprobar quién puede acceder a ella en cada llamada. Quitar una sesión de transporte no elimina esa responsabilidad.

La versión también añade información para almacenar temporalmente respuestas de listas y enrutar peticiones HTTP. Son cambios de integración. Mediría por separado si reducen consultas o mejoran la respuesta de tu servicio, en lugar de atribuirles un ahorro automático.

Tasks sirve para operaciones que tardan más

Tasks es una extensión opcional para trabajo asíncrono. El servidor puede devolver un identificador de tarea y el cliente consultar su estado con tasks/get. Ambos deben declarar soporte. Una llamada breve de búsqueda no necesita adoptar esta extensión solo porque esté disponible.

Podría ser útil si la agenda ofreciera preparar un informe extenso sobre sus eventos. El cliente conservaría el identificador para volver a consultar la misma tarea tras desconectarse, en lugar de crear otro informe por error. El ejemplo plantea ese uso; la integración tendría que comprobar cómo lo soportan cliente y servidor.

Conviene distinguir recibir el identificador de obtener el resultado terminado. También hay que tratar fallos y caducidad. La cancelación de Tasks es cooperativa: pedirla no garantiza que el servidor detenga el trabajo. Comprobaría esos comportamientos con el cliente y servidor elegidos.

Qué está publicado y qué sigue en la hoja de ruta

El roadmap, actualizado el 22 de agosto de 2026, incluye identidad de agentes, delegación y descubrimiento progresivo de capacidades. Describe prioridades para próximas versiones y advierte de que pueden cambiar. Que exista una propuesta no acredita que tu producto la soporte.

El descubrimiento progresivo busca evitar presentar todo un catálogo de herramientas desde el principio. Mientras revisas esa evolución, comprueba el conjunto concreto que expones y prueba si el agente selecciona la operación correcta. Un catálogo pequeño y pertinente es una decisión que puedes evaluar en tu aplicación.

Cómo comprobar una conexión antes de actualizar

Anota cliente, servidor, SDK, versiones y extensiones utilizadas. En un entorno separado, probaría primero una búsqueda conocida y otra sin resultados. Después comprobaría una herramienta ausente, argumentos incorrectos, un fallo del servicio y una acción fuera de permiso. La actualización tiene que conservar las respuestas útiles y explicar los errores.

Para la agenda, revisaría qué eventos selecciona y si horarios y enlaces coinciden con los datos originales. Si hay Tasks, añadiría desconexión, recuperación por identificador y cancelación. Repite esas pruebas propuestas antes y después del cambio para detectar qué se conserva y qué se rompe.

Empieza por una operación de lectura que puedas verificar y conserva una forma de volver a la integración anterior. Amplía capacidades cuando resuelvan una necesidad concreta. MCP facilita la conexión; la autorización, el tratamiento de datos externos y la evaluación siguen necesitando atención en tu aplicación.

Fuentes