MCP crece: qué deben planificar los equipos de producción en la nueva especificación
Cómo la revisión del Protocolo de Contexto del modelo del 28-07-2026 modifica la escalamiento, las tareas, la autorización y el caché, y cómo migrar un servidor existente en fases seguras.
Fuentes: **MCP Grows Up: Six Changes Production Teams Need to Plan For**
Una revisión más significativa que un simple aumento de versión
Según el anuncio de lanzamiento del proyecto, el Model Context Protocol publicó su mayor revisión desde su lanzamiento el 28 de julio de 2026. La especificación elimina las sesiones de protocolo, formaliza las extensiones, agrega funcionalidades asíncronas duraderas, refuerza los mecanismos de autorización y proporciona a los implementadores una política real de descontinuación. La versión candidata ya se había congelado desde el 21 de mayo, lo que dio a los mantenedores del SDK, a los desarrolladores de clientes y a los operadores de servidores aproximadamente diez semanas para probar el rediseño.
En conjunto, el documento finaliza con un núcleo sin estado, solicitudes de múltiples viajes, enrutamiento por encabezados, funcionalidades de descubrimiento y resultados de listas que pueden cachearse, un marco para extensiones, tareas, aplicaciones MCP, mecanismos de autorización más estrictos, y un proceso fiable para eliminar gradualmente las funcionalidades obsoletas.
“MCP sin estado” suena como un buen título, pero la lista de cambios es más extensa que eso. Debajo de ella se ocultan varios detalles que causan problemas. Los resultados ahora incluyen un campo resultType. Se ha eliminado la transmisión HTTP GET. subscriptions/listen reemplaza a los métodos antiguos de suscripción. Las transmisiones SSE pierden la posibilidad de reanudación mediante Last-Event-ID. Los resultados de listas y recursos deben incluir indicaciones de caché. Los esquemas de herramientas pueden utilizar toda la especificación JSON Schema 2020-12. Finalmente, cuando falta un recurso ahora se devuelve el código estándar JSON-RPC -32602, en lugar de -32002 anteriormente.
Tratar esto como un simple “actualizar la dependencia y volver a desplegar” sería un error. Se trata de una migración de arquitectura.
1. Un protocolo sin estado no convierte a la aplicación en sin estado
En revisiones anteriores, el contexto se establecía mediante un intercambio de mensajes initialize/initialized. Para servidores HTTP remotos, el servidor también podía proporcionar un Mcp-Session-Id que el cliente repetía en solicitudes posteriores. Esto vinculaba a un cliente a una sola sesión del servidor, y las implementaciones reales solían recurrir a enrutamiento persistente en el balanceador de carga, a un almacén de sesiones compartido, o a una combinación de ambos.
En 2026-07-28, tanto el intercambio de mensajes como la sesión del protocolo desaparecen. Cada solicitud incluye su versión de protocolo, las capacidades del cliente y la identidad del cliente, de forma opcional, dentro de _meta. Los servidores deben implementar server/discover, aunque los clientes no necesitan llamarlo antes de cada operación. En su lugar, un cliente puede enviar su versión preferida e intentarlo de nuevo si recibe un UnsupportedProtocolVersionError.
A través de Streamable HTTP, una solicitud actual lleva metadatos como estos:
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
La misma versión, método y nombre también aparecen en el cuerpo de JSON-RPC. El cuerpo mantiene su autoridad, y los servidores deben rechazar cualquier discrepancia entre los encabezados y el cuerpo. Esto impide que una pasarela apruebe o enrute una operación mientras el servidor ejecuta otra.
“Stateless” no significa “no almacenar nada”
La especificación no elimina el estado de la aplicación; simplemente deja de ocultarlo. Cuando un servidor necesita continuidad de una llamada a otra, debe crear un identificador de dominio, como por ejemplo workspace_id, browser_id, basket_id, analysis_run_id o deployment_id. El cliente o el modelo luego lo proporcionan como un argumento normal de la herramienta en las llamadas posteriores:
create_workspace()
→ { "workspace_id": "ws_7f3..." }
add_file(workspace_id="ws_7f3...", ...)
→ ...
run_analysis(workspace_id="ws_7f3...")
→ ...
Eso es más limpio que el estado de transporte oculto, pero impone nuevas responsabilidades a la aplicación. Debe gestionar las verificaciones de propiedad, el aislamiento de usuarios, la expiración, las reglas de retención, la autorización y la protección contra intentos de adivinación o retransmisión. Los flujos de trabajo persistentes pueden seguir necesitando una base de datos o un caché distribuido, y las tareas de larga duración requieren, por definición, un almacenamiento duradero. La infraestructura puede ser sin estado, mientras que el producto sigue teniendo estado.
2. Donde realmente vale la pena no tener estado
Escalar horizontalmente de forma sencilla
Cuando una solicitud contiene todo su propio contexto, el servidor puede operar detrás de un balanceador de carga estándar de tipo round-robin. En Kubernetes, generalmente son suficientes un Deployment y un Service normales, sin anotaciones de afinidad de sesión ni StatefulSet exclusivamente para gestionar sesiones MCP. Esto brinda beneficios especialmente en términos de escalado automático: un pod nuevo no necesita reconstruir las sesiones de protocolo antes de comenzar a manejar tráfico, y un pod reemplazado durante un despliegue progresivo no deja a los clientes atascados en una sesión inactiva.
Hay un detalle importante: si una aplicación del servidor maneja objetos como tareas, estos seguirán almacenándose en un repositorio externo duradero siempre que sea necesario preservarlos en caso de pérdida de un proceso o pod.
Enrutamiento y políticas en la pasarela
Dado que Mcp-Method y Mcp-Name son encabezados simples, una pasarela puede enrutar, medir y aplicar políticas sin necesidad de analizar el cuerpo en formato JSON. En un servicio multiinquilino que permite establecer cuotas separadas para tools/list, herramientas de búsqueda costosas, herramientas de despliegue y cualquier elemento destructivo:
tools/list → high request allowance
tools/call + search → standard allowance
tools/call + deploy_prod → lower rate limit and stronger policy
resources/read → data-volume quota
Un gateway tampoco debe leer nunca clientInfo como prueba de quién está realizando la llamada. Este campo es autodeclarado y existe con el fin de mostrar información, depurar y registrar datos. Quién es el arrendatario debe determinarse a partir de un token validado o de alguna otra fuente fiable.
Almacenamiento en caché
Las respuestas a resources/read, resources/templates/list, resources/list, prompts/list, tools/list y server/discover incluyen dos campos nuevos: ttlMs y cacheScope. El primero indica el nivel de actualidad, no el intervalo de consulta. El segundo indica si un resultado es público o privado. Todo aquello que varíe según el usuario, el arrendatario, el ámbito o la autorización no debe tratarse como datos públicos compartidos, y las notificaciones de cambios pueden invalidar un resultado que de lo contrario estaría actualizado.
El caché reduce las solicitudes repetidas al catálogo de herramientas y estabiliza las entradas de los prompts de modelo. Una gama incorrectamente elegida también genera una nueva categoría de errores relacionados con la corrección y la privacidad.
Observabilidad
La especificación documenta la propagación del contexto de seguimiento W3C a través de las claves _meta traceparent, tracestate y baggage. De este modo, un host, un cliente MCP, una pasarela, un servidor y un servicio posterior comparten un método para correlacionar las llamadas a herramientas a lo largo de todo el camino de ejecución. El contexto de seguimiento facilita la correlación, pero no constituye un mecanismo de autorización ni una garantía de integridad; además, los datos sensibles, los tokens, los prompts en bruto y la información personal no deben incluirse en el campo baggage.
3. Las extensiones pasan a ser un concepto de primera clase
Cada extensión ahora cuenta con un identificador, reglas de negociación, mantenedores designados, su propio repositorio y su propio ciclo de lanzamiento. Los clientes declaran las extensiones que manejan en las capacidades enviadas con cada solicitud, mientras que los servidores anuncian las suyas a través de server/discover. Solo cuando ambas partes soportan una extensión esta entra en vigor; si la otra parte no la posee, la implementación debe recurrir al comportamiento básico o responder con un error adecuado.
Eso representa un gran paso en la evolución del protocolo, ya que las funcionalidades ya no tienen que esperar a un lanzamiento completo del núcleo. También se crea una matriz de compatibilidad. Un servidor no puede dar por sentado que todos los hosts soportan Tasks, MCP Apps, Enterprise-Managed Authorization o cualquier extensión futura, por lo que el código de producción necesita soluciones alternativas explícitas:
- Una herramienta que admite tareas también ofrece una vía síncrona para clientes que no anuncian tareas, o devuelve un error claro indicando que la capacidad no está soportada.
- Una herramienta respaldada por una aplicación MCP devuelve contenido estructurado o de texto útil cuando el host no puede renderizar su interfaz.
- La autorización empresarial solo se aplica cuando la política organizacional lo permite.
- Los campos específicos de las extensiones nunca se envían a clientes que no los negociaron.
Las extensiones reducen el acoplamiento con la especificación principal y aumentan el riesgo de fragmentación del ecosistema.
4. Las tareas hacen que las herramientas de ejecución prolongada sean más duraderas
Las tareas pasan del núcleo experimental a una extensión oficial, io.modelcontextprotocol/tasks. Si el cliente indica que soporta tareas, el servidor puede responder con una operación normal utilizando un identificador de tarea en lugar del resultado final. El cliente luego utiliza tasks/get para leer el estado actual, tasks/update para proporcionar los datos solicitados y tasks/cancel para solicitar su cancelación.
Una tarea pasa por los estados working, input_required, completed, failed y cancelled. El servidor debe persistir la tarea antes de devolver su identificador. La cancelación es de tipo cooperativo, por lo que la confirmación de una solicitud no garantiza que el proceso subyacente se detenga de inmediato.
Los candidatos naturales son conjuntos de pruebas, pipelines de compilación, generación de código, despliegues en la nube, importaciones de datos, procesamiento de documentos, pasos que esperan aprobación humana, trabajos por lotes y capas de enlace sobre alguna API de trabajo externa. Lo que realmente se obtiene no es la ejecución asíncrona en sí, sino la capacidad de recuperación: un cliente puede interrumpirse, reiniciarse y continuar haciendo consultas utilizando el mismo ID de tarea.
Qué debe añadir un servidor de producción
Las tareas necesitan mucho más que un hilo en segundo plano:
- un repositorio de tareas duradero
- una verificación de autorización cada vez que se llama a
tasks/get,tasks/updateotasks/cancel - aislamiento de propietarios e inquilinos
- validación de las transiciones de estado
- conservación de resultados y errores
- aplicación de TTL y limpieza
- límites en la tasa de consultas
- propagación de cancelaciones
Trate el ID de una tarea como un identificador de recurso, no como un secreto. Poseer el ID nunca debe ser suficiente para autorizar nada.
5. Las solicitudes de múltiples viajes sustituyen a las peticiones iniciadas por el servidor
Un servidor sin estado no puede contar con una conexión bidireccional persistente para hacer preguntas al cliente cuando lo desee. En esos casos entran en juego las solicitudes de múltiples viajes (MRTR). Cuando un servidor necesita confirmación, información adicional, muestreo u otro tipo de entrada proporcionada por el cliente, devuelve un InputRequiredResult. El cliente recopila las entradas y vuelve a intentar la operación original con inputResponses y, si está disponible, requestState.
Tomemos como ejemplo una herramienta destructiva:
delete_resources(resource_ids=[...])
En lugar de abrir una solicitud inversa en una transmisión existente, el servidor responde:
input_required:
"Confirm deletion of 53 resources"
El cliente obtiene la confirmación y vuelve a realizar la llamada original. La repetición es autónoma, por lo que funciona en cualquier instancia, pero también implica que los servidores deben estar diseñados para soportar intentos repetidos.
Reglas para MRTR en producción
- No realice tareas irreversibles hasta tener todos los datos de entrada necesarios.
- Haga que los intentos repetidos sean idempotentes.
- Vincule
requestStatea la operación específica y al usuario que la inició. - Vence el estado de solicitud antiguo.
- Rechace respuestas que hagan referencia a claves que el servidor nunca solicitó o ya recibió.
- Establezca un límite al número de intentos permitidos, para evitar la formación de bucles.
- Autoriche nuevamente la operación en cada intento repetido.
- Nunca asuma que el intento se realizará en la misma instancia.
En los casos en que el flujo de trabajo sea sensible, haga que requestState sea un identificador aleatorio opaco, con los datos reales almacenados en el servidor, o bien un valor que contenga un código de autenticación de mensaje para que se pueda detectar cualquier manipulación.
6. Las aplicaciones MCP cambian el producto, no solo el protocolo
Las aplicaciones MCP permiten que un servidor asocie una herramienta con una interfaz HTML interactiva. Los hosts compatibles la renderizan dentro de un iframe aislado. La aplicación se comunica con el host mediante JSON-RPC a través de postMessage, y el host controla qué capacidades y herramientas puede utilizar la aplicación. Esto permite la creación de formularios, paneles de control, diálogos de confirmación, visores de medios, configuradores de despliegue, pantallas de triaje y otras experiencias que resultan difíciles de expresar únicamente con texto.
Para una startup, esto puede cambiar la dinámica económica del MVP: un flujo de trabajo conversacional interactivo sin necesidad de crear primero una capa de aplicación separada ni una capa de integración. Sin embargo, la ingeniería frontend no desaparece. Los equipos siguen siendo responsables del diseño de interfaces accesibles, del manejo del estado, de la configuración de CSP, del código que se ejecuta dentro del entorno aislado, de la validación de entradas, de la negociación de capacidades del host, del manejo seguro de las llamadas a herramientas, de las pruebas de compatibilidad en diferentes clientes y de una solución alternativa para hosts que no cuentan con soporte de aplicaciones. Dado que las aplicaciones son una extensión opcional, el soporte para hosts varía, por lo que un servidor debe devolver contenido estructurado y significativo incluso cuando no sea posible mostrar la vista.
7. La autorización se vuelve más estricta y difícil
Según las reglas de autorización HTTP, un servidor MCP protegido actúa como servidor de recursos OAuth y el cliente MCP como cliente OAuth. Esta versión toma prestados elementos seleccionados de OAuth 2.1 y estándares relacionados. Los servidores deben publicar metadatos de recursos protegidos para que los clientes puedan encontrarlos, y se aceptan tanto los metadatos de servidores de autorización de OAuth como los de OpenID Connect. PKCE es obligatorio, al igual que los indicadores de recursos en las solicitudes de autorización y de tokens, y las verificaciones del emisor son más estrictas. Las reglas principales son:
- Los clientes envían un parámetro
resourceque indica el servidor MCP al que se dirigen. - Un servidor verifica que el token que recibe haya sido emitido para su propio público objetivo.
- Los servidores de autorización deben incluir el campo
iss, y los clientes verifican el emisor cuando está presente antes de canjear el código de autorización.
Authorization y nunca en una cadena de consulta.S256.Los indicadores de recurso restringen el público al que puede acceder un token. No deben describirse como un mecanismo de vinculación de tokens criptográficos.
La identidad corporativa es un asunto aparte
La autorización básica de MCP abarca el flujo OAuth estándar delegado por el usuario. La política centralizada de acceso corporativo proviene de la extensión opcional de Autorización Gestionada por la Empresa, que permite al proveedor de identidades de una organización controlar el acceso a los servidores MCP, incluyendo procesos de incorporación y salida, acceso condicional y su aplicación. Tanto el cliente como el sistema de autorización del servidor y el entorno de identidades empresariales deben ser compatibles con ella. Para una revisión de seguridad, la arquitectura se divide de la siguiente manera:
Core authorization
OAuth flow
issuer validation
resource/audience validation
scopes and step-up
Protected Resource Metadata
Optional enterprise extension
corporate IdP policy
SSO
centralized approval and revocation
identity-assertion exchange
La especificación aclara la arquitectura sin simplificar operativamente el funcionamiento de OAuth. La obtención de metadatos del cliente plantea problemas de SSRF y políticas de confianza. Los tokens y las credenciales de actualización requieren un almacenamiento seguro. Las implementaciones con múltiples emisores necesitan un registro y un estado de tokens separados. Los metadatos, las URI de redirección, los alcances y los identificadores canónicos de recursos deben mantenerse consistentes.
8. Una política real de obsolescencia
Las funcionalidades ahora tienen tres estados: Activa, Obsoleta y Eliminada. Una funcionalidad esencial generalmente permanece en estado Obsoleta durante al menos doce meses antes de poder ser eliminada, y la obsolescencia requiere un plan de migración documentado además de una entrada en el registro central. La eliminación puede producirse más tarde de la fecha más temprana prevista. Existe un procedimiento acelerado para los riesgos de seguridad actuales, pero incluso este suele requerir al menos 90 días.
HTTP+SSE, el transporte más antiguo, cuenta con su propia regla de transición y podría ser eliminado antes que las otras características recientemente obsoletas. Quienes aún lo utilicen deberían planificar primero la migración a Streamable HTTP. Tenga también en cuenta que la regla de los doce meses se refiere únicamente a las características del protocolo; las APIs de SDK tienen políticas y plazos de soporte separados que pueden diferir.
Cómo se aplica en aplicaciones reales
Herramientas internas empresariales
Imagínese una empresa que publica conocimiento interno, Jira, Confluence, catálogos de servicios y manuales de operaciones a través de MCP. Con el modelo antiguo, un despliegue remoto podría depender de la afinidad de sesiones para que un empleado accediera siempre a la misma instancia. Con 2026-07-28, el nivel MCP puede consistir en un conjunto de contenedores sin estado detrás de un servicio Kubernetes normal y un balanceador de carga:
MCP host
↓
API gateway / authorization
↓
Stateless MCP Deployment
├─ Knowledge connector
├─ Jira connector
├─ Confluence connector
└─ Service catalog connector
↓
OpenTelemetry backend
La autorización diaria puede seguir el OAuth básico, y la extensión de autorización gestionada por la empresa entra en juego cuando se necesita una política central de IdP. La principal limitación es la cantidad de clientes que realmente admiten dicha extensión.
SaaS multiinquilino
Imaginemos que un proveedor de herramientas para desarrolladores vende MCP como una API de pago a cientos o miles de clientes. La falta de estado permite un enrutamiento multi-zona sencillo, y la pasarela puede medir el uso por Mcp-Method y Mcp-Name, tomando la información del cliente de una autorización validada en lugar de los nombres o encabezados que envíe el cliente. Una implementación adecuada dividiría las solicitudes y tareas por cliente, marcaría los catálogos específicos de cada cliente con cacheScope: "private", compararía cada encabezado con el cuerpo de la solicitud, limitaría el uso de herramientas costosas según sus propios límites, bloquearía las búsquedas de tareas entre clientes y mantendría las decisiones de autorización fuera de la memoria del proceso local. El enrutamiento basado en sesiones ya no existe; la isolación de clientes sigue siendo su responsabilidad.
Asistentes de programación con IA
Un servidor de codificación puede exponer run_tests, build_project, generate_patch o deploy_preview como tareas. Devuelve un ID de tarea de inmediato, pone la tarea en cola y permite que el agente continúe leyendo código o revisando otro problema. El cliente hace consultas al intervalo sugerido por el servidor, y cuando un paso destructivo necesita aprobación, la tarea pasa a input_required y el cliente responde con tasks/update. La ventaja es la resiliencia ante reinicios del editor y caídas de red. El precio es un sistema de tareas real: una cola duradera, arrendamientos de trabajadores, resultados almacenados, posibilidad de cancelación, espacios de trabajo aislados y una política de retención.
Salud y servicios financieros
Los indicadores de recursos y las verificaciones de audiencia reducen la probabilidad de que un token emitido para un servidor MCP sea reutilizado en otro, mientras que la validación del emisor disminuye las posibilidades de ataques por confusión de OAuth. W3C Trace Context permite rastrear una solicitud a lo largo del camino MCP y de los servicios que se encuentran detrás de él. Juntos, brindan a los equipos de seguridad y cumplimiento un conjunto más claro de controles, aunque no constituyen una solución completa para el cumplimiento. Aún se necesita autorización dentro de la aplicación, eventos de auditoría inmutables, reglas de retención y eliminación, clasificación de datos, gestión de consentimientos, administración de claves, registros de acceso administrativo, un proceso para incidentes y datos de trazabilidad mínimos. El rastreo ayuda en el diagnóstico; no debería ser el único registro de auditoría.
Una startup nativa de IA
Imaginemos un equipo pequeño que desarrolla un asistente de infraestructura. A través de MCP Apps, podría ofrecer un formulario de plan de despliegue, un panel de control de estimación de costos, un diálogo de aprobación, un monitor de implementación y un control de reversión. El anfitrión proporciona el contexto de conversación, el servidor ofrece herramientas y recursos de interfaz de usuario, y la aplicación invoca esas herramientas a través de un puente controlado por el anfitrión. Al principio, un producto de panel de control separado podría resultar innecesario, pero el diseño de API, la autorización, las pruebas de interfaz, la accesibilidad, las reglas CSP y las soluciones de compatibilidad siguen siendo necesarias.
Dónde la nueva especificación añade complejidad
El estado se ha movido, pero no ha desaparecido. El estado de conexión se convierte en un estado de dominio explícito, lo cual representa una mejora arquitectónica que exige un diseño deliberado en cuanto a manejo, almacenamiento, vencimiento, propiedad e idempotencia.
Mejorar el SDK y adoptar el protocolo son dos proyectos separados. Mientras estaba disponible la versión candidata, los mantenedores del SDK instaron a los equipos a separar la actualización de la versión principal del SDK del cambio al nuevo protocolo de comunicación, y ese consejo sigue siendo válido. Tomemos como ejemplo el SDK de TypeScript v2: divide el paquete único en paquetes separados para servidor y cliente, se distribuye únicamente en formato ESM, funciona en Node.js 20+, Bun y Deno, se valida mediante bibliotecas compatibles con Standard Schema e incluye un codemod para los cambios típicos de la versión v1. Python v2 también representa una gran reestructuración, entre otras cosas al cambiar el nombre de FastMCP a MCPServer. TypeScript v1 recibirá correcciones y actualizaciones de seguridad durante al menos seis meses una vez esté disponible v2, y Python v1 seguirá recibiendo correcciones críticas y parches de seguridad. Un orden de trabajo cauteloso:
- Mejorar el SDK manteniendo el comportamiento del protocolo anterior donde sea posible.
- Corregir los cambios en las API a nivel de aplicación.
- Agregar soporte para protocolos de dos eras diferentes.
- Validar con clientes y tráfico reales.
- Habilitar gradualmente un comportamiento moderno sin estado.
- Retirar el soporte para versiones antiguas solo después de observar la adopción por parte de los clientes.
Las extensiones fragmentan las capacidades. Una herramienta no puede dar por sentado que las tareas o las aplicaciones MCP existan en todas partes, por lo que los equipos de producto necesitan matrices de compatibilidad y una experiencia de usuario de respaldo.
Las reintentos se convierten en un problema de corrección. Los caminos de reintento surgen ahora debido a MRTR, la negociación de versiones de protocolo, flujos de respuesta HTTP perdidos, escaladas de autorización, sondeos de tareas y reconexiones de suscripciones. Por lo tanto, cualquier operación con efectos secundarios requiere un plan de idempotencia deliberado.
OAuth funciona mejor en términos de interoperabilidad, pero sigue siendo exigente. La especificación menciona a OAuth 2.1 y a los Documentos de Metadatos de ID de Cliente como borradores, por lo que los implementadores deben seguir tanto los cambios de MCP como las normas subyacentes.
El caché plantea cuestiones de privacidad. Marcar una respuesta que depende de la autorización como pública podría exponer el catálogo de un usuario o inquilino ante otro. Son adecuados los valores predeterminados conservadores: usar un ámbito privado a menos que el resultado sea realmente idéntico para todos los solicitantes.
Evaluación general
MCP 2026-07-28 acerca el protocolo a la forma en que opera la web moderna: solicitudes autónomas, versiones explícitas, enrutamiento HTTP habitual, semántica de caché real, rastreo distribuido, autorización estándar y capacidades opcionales que evolucionan por separado. La verdadera ventaja no es la ausencia de estado, sino la ausencia de estado oculto en el protocolo.
Escalar horizontalmente, enrutar entre zonas, recuperarse de fallos, establecer políticas de gateway y monitorear el sistema se vuelven considerablemente más fáciles. Lo que surge a cambio es el estado de la sesión de trabajo que se utilizaba para ocultar todo esto: manejadores de aplicaciones, idempotencia, tareas duraderas, soluciones de respaldo para extensiones, metadatos de autorización, privacidad de los cachés y comportamientos de las reintentos.
Si ya tiene un servidor en producción, realice la migración por etapas y mantenga soporte para ambas versiones. Considere la actualización del SDK y el protocolo de comunicación como pasos separados, elimine las suposiciones relacionadas con las conexiones, almacene los procesos de larga duración en estructuras explícitas, pruebe los mecanismos de autorización y las reintentos, y solo elimine el comportamiento heredado una vez que se haya medido una adopción real por parte de los clientes. En el caso de un servidor completamente nuevo, es más sencillo: comience con controladores de solicitudes sin estado y estado explícito, utilice HTTP Streamable y los sistemas de autorización actuales, agregue OpenTelemetry, haga que el caché sea determinista, y planifique desde el primer día la negociación de extensiones.
El protocolo ahora es más fácil de utilizar, pero solo para equipos dispuestos a definir con claridad el estado de su aplicación, los límites de seguridad y su comportamiento en caso de fallos.
Leer más
- Notas prácticas: MCP 2026: El protocolo creció así: esto es la IA en producción — Guía detallada de las Notas prácticas: MCP 2026: El protocolo creció así: esto es la IA en producción: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
- Diez servidores MCP que vale la pena instalar primero, en orden de prioridad para desarrolladores — Lista ordenada de servidores MCP ideales para asistentes de programación con IA, desde Context7 y GitHub hasta Postgres y sistemas de memoria, con configuraciones de instalación y advertencias sobre permisos.