Un autor invitado de HackerNoon sostiene que toda aplicación SaaS debería publicar un servidor MCP (Model Context Protocol, protocolo de contexto de modelos) para que los asistentes de IA puedan usar sus funciones directamente, y que hoy es un factor diferencial que pronto será un requisito mínimo. La propuesta llega cuando la especificación oficial acaba de cambiar a fondo con su revisión del 28/07/2026 y cuando OWASP, la fundación de referencia en seguridad de aplicaciones, ya tiene en fase beta una lista de los diez riesgos principales de este protocolo.
Las claves de MCP en cualquier aplicación en 20 segundos
- MCP permite que un agente de IA use herramientas y datos de una aplicación sin integraciones a medida.
- La versión vigente, 2026-07-28, elimina las sesiones y hace el protocolo sin estado.
- La especificación trata cada herramienta como ejecución de código arbitrario y exige consentimiento del usuario.
- OWASP mantiene en beta un Top 10 de riesgos específicos de MCP.
El artículo, firmado el 20/10/2026 por James, un redactor de HackerNoon que desarrolla una aplicación de tareas, parte de una observación: cada vez más gente empieza su trabajo en un chat de IA, y una aplicación que no sea accesible desde ahí queda fuera de ese flujo. Según el autor, MCP funciona como un adaptador universal entre agentes y aplicaciones. Su argumento numérico es el clásico problema N×M: diez agentes y diez aplicaciones necesitan cien integraciones a medida, mientras que con un protocolo común bastan veinte piezas, diez clientes y diez servidores.
El autor recuerda que Anthropic presentó MCP en noviembre de 2024 como estándar abierto. Hoy el proyecto figura en su web oficial como una serie de LF Projects, la estructura de la Linux Foundation para proyectos abiertos. Y la API de siempre no desaparece: según el texto, MCP es una capa adicional, pensada para agentes, que envuelve los servicios REST existentes.
Qué expone un servidor MCP y qué ha cambiado en la versión 2026-07-28
La especificación describe tres papeles: el anfitrión (la aplicación de IA que inicia las conexiones), el cliente (el conector dentro de ese anfitrión) y el servidor (el servicio que ofrece capacidades). Los mensajes viajan en formato JSON-RPC 2.0, ya sea por la entrada y salida estándar del sistema (stdio) en local o por Streamable HTTP en remoto. Un servidor puede ofrecer tres tipos de elementos, que el autor de HackerNoon resume bien: herramientas (acciones que el agente ejecuta, como crear una factura), recursos (datos que puede leer) y prompts (plantillas). Cada herramienta lleva un nombre, una descripción y un esquema de entrada, y el modelo decide en tiempo de ejecución cuál llamar a partir de esa descripción.
Lo que el artículo no recoge es el alcance de la última revisión. La versión 2026-07-28, que sustituye a la del 25/11/2025, elimina las sesiones a nivel de protocolo y la cabecera Mcp-Session-Id, suprime el saludo inicial de conexión y obliga a que cada petición lleve su versión de protocolo y las capacidades del cliente. Los servidores deben implementar un nuevo método, server/discover, para anunciar versiones y capacidades. Las funciones Roots, Sampling y Logging pasan a estar obsoletas, con un plazo mínimo de doce meses antes de retirarse, y las tareas asíncronas salen del núcleo para convertirse en una extensión oficial, igual que MCP Apps, que permite mostrar elementos interactivos dentro de la conversación.
En autorización también hay cambios. El autor insiste, con razón, en que los servidores remotos deben usar OAuth 2.1 para que cada usuario se identifique con su propia cuenta y nunca recurrir a una única clave maestra. La nueva revisión añade que los clientes deben validar el emisor de la respuesta de autorización cuando venga indicado, que las credenciales quedan ligadas al servidor de autorización que las emitió y que el registro dinámico de clientes queda obsoleto en favor de los documentos de metadatos de identificador de cliente. Quien siga hoy una guía escrita para versiones anteriores tendrá que revisar su implementación.
Los riesgos: lo que dicen la especificación, OWASP y freeCodeCamp
La propia especificación es clara en su apartado de seguridad. Las herramientas representan ejecución de código arbitrario y deben tratarse con cautela; las descripciones de su comportamiento, como las anotaciones, se consideran no fiables salvo que procedan de un servidor de confianza; y el anfitrión debe obtener el consentimiento explícito del usuario antes de invocar cualquier herramienta o de exponer sus datos a un servidor. El documento admite que MCP no puede imponer esos principios a nivel de protocolo, así que la responsabilidad recae en quien lo implementa.
OWASP concreta esos riesgos en su MCP Top 10, todavía en fase beta y de pruebas piloto. La lista incluye la mala gestión de tokens y la exposición de secretos, la escalada de privilegios por permisos que crecen sin control, el envenenamiento de herramientas (descripciones manipuladas para engañar al modelo), los ataques a la cadena de suministro, la inyección de comandos, la inyección de prompts a través del contenido, la autenticación y autorización insuficientes, la falta de auditoría y telemetría, los servidores MCP «en la sombra» que nadie ha aprobado y la exposición excesiva de contexto.
El curso gratuito que freeCodeCamp anunció el 29/10/2026 añade un marco útil para quien diseña estas integraciones: la «tríada letal» descrita por el desarrollador Simon Willison. Un agente es estructuralmente vulnerable cuando reúne a la vez acceso a datos privados, exposición a contenido no fiable (páginas web, correos, incidencias públicas o esquemas de herramientas de terceros) y alguna vía para comunicarse con el exterior. El curso propone romper esa combinación con límites de arquitectura en vez de confiar en filtros de prompts, y advierte de que fallos clásicos como la inyección de comandos o la fuga de tokens se ejecutan a velocidad de máquina cuando hay un agente de por medio.
Cómo propone el autor empezar
La guía de HackerNoon recomienda empezar con dos o tres flujos de trabajo clave, elegir pocas herramientas a partir de lo que los usuarios piden de verdad y escribir descripciones claras, porque son lo que el agente lee para decidir. También aconseja probar con MCP Inspector antes de conectar un cliente real, usar stdio para herramientas locales y Streamable HTTP con OAuth 2.1 para servicios en la nube. El autor cita SDK oficiales en diez lenguajes y asegura que un primer servidor puede estar listo en un fin de semana, algo que conviene tomar como una estimación del autor y no como una regla para proyectos con datos de clientes.
Hay ejemplos de esa tendencia en plataformas grandes. WordPress, por ejemplo, prepara MCP, la API de Abilities y OAuth en el núcleo para la versión 7.3, lo que llevaría el protocolo a millones de sitios. Y el debate sobre cuándo compensa adoptarlo sigue abierto, como ya contó noticias.ai al analizar que MCP crece, pero exige más criterio para llevarlo a producción.
Preguntas frecuentes
¿Qué es un servidor MCP?
Es un servicio que expone herramientas, datos y plantillas de una aplicación siguiendo el protocolo Model Context Protocol, para que un asistente o agente de IA pueda usarlos sin una integración a medida.
¿Cuál es la versión actual de la especificación MCP?
La revisión estable vigente es la 2026-07-28, que sustituye a la 2025-11-25. Elimina las sesiones del protocolo, lo hace sin estado y declara obsoletas las funciones Roots, Sampling y Logging.
¿Sustituye MCP a la API de una aplicación?
No. Según el autor de HackerNoon, MCP es una capa adicional pensada para agentes que suele envolver la API REST existente.
¿Cuáles son los principales riesgos de seguridad de MCP?
OWASP destaca, entre otros, la exposición de secretos, el envenenamiento de herramientas, la inyección de prompts y de comandos y la autorización insuficiente. La especificación exige el consentimiento explícito del usuario antes de invocar cualquier herramienta.
Fuentes:
