Microsoft anunció la versión 2.0 del kit de desarrollo de software oficial de MCP para C#, coincidiendo con la implementación de la especificación 2026-07-28. La versión cambia la forma de ejecutar servidores MCP mediante HTTP al hacer que funcionen sin estado de forma predeterminada, añade cabeceras HTTP unificadas y admite solicitudes de varias rondas que permiten a las herramientas solicitar entradas al usuario o al modelo de lenguaje sin depender de una sesión persistente.
La versión está dirigida a desarrolladores que crean servidores y clientes MCP sobre .NET, manteniendo el funcionamiento de las API estables de la versión 1.x y admitiendo los marcos net8.0, net9.0 y net10.0, además de netstandard2.0 para su uso con .NET Framework.
Servidores sin estado de forma predeterminada
En versiones anteriores, el uso de Streamable HTTP requería completar el intercambio de inicialización y crear una sesión, y después enviar la cabecera Mcp-Session-Id con cada solicitud posterior. Esto vinculaba las solicitudes a la instancia del servidor que emitió el identificador, lo que exigía enrutamiento persistente o la transferencia de sesiones al ejecutar varias instancias.
La especificación 2026-07-28 elimina el intercambio initialize e initialized y la cabecera Mcp-Session-Id, y transporta la versión del protocolo y las capacidades en cada solicitud. Como resultado, cualquier instancia del servidor puede procesar cualquier solicitud, sin necesidad de sesiones persistentes ni de almacenes de sesiones compartidos a nivel de protocolo. Esto hace que el despliegue de servidores MCP en entornos serverless, de varias instancias o de edge se parezca más a ejecutar una aplicación ASP.NET Core normal detrás de un equilibrador de carga.
La opción HttpServerTransportOptions.Stateless queda establecida en true de forma predeterminada en la versión 2.0, con la posibilidad de activar el modo con estado cuando se necesiten mensajes no solicitados del servidor al cliente o un estado de transporte vinculado a la sesión. Las sesiones siguen siendo una opción disponible, pero ya no constituyen la configuración básica.
Cabeceras HTTP para el enrutamiento y la supervisión
El modo sin estado convierte una solicitud MCP en una solicitud HTTP POST autónoma, lo que permite a la infraestructura habitual gestionarla como cualquier otro tráfico HTTP. La especificación permite cabeceras como Mcp-Method y Mcp-Name, además de la posibilidad de promover algunos parámetros de la herramienta a cabeceras del tipo Mcp-Param-*.
El equilibrador de carga, el proxy, la puerta de enlace o el firewall de aplicaciones web pueden utilizar estas cabeceras para el enrutamiento y la supervisión sin analizar el cuerpo de la solicitud JSON-RPC. El cuerpo de la solicitud sigue siendo la fuente de confianza; si el valor de la cabecera difiere del valor presente en el cuerpo, el servidor rechaza la solicitud con un error HeaderMismatch. El diseño también admite la codificación en las cabeceras de valores no compatibles, como los valores no ASCII, mediante un indicador Base64.
Solicitudes de varias rondas para herramientas interactivas
La función Multi Round-Trip Requests, o MRTR, añade una forma de gestionar herramientas que no pueden completar su trabajo en una sola llamada. En lugar de que el servidor se conecte al cliente mediante una sesión activa durante la ejecución de la solicitud, devuelve un resultado de tipo InputRequiredResult que incluye las solicitudes de entrada y un estado opaco denominado requestState.
El cliente ejecuta lo solicitado, como pedir confirmación al usuario, invocar un modelo de lenguaje o mostrar las raíces de los espacios de trabajo, y después vuelve a enviar la misma llamada a la herramienta acompañada de inputResponses y requestState. El proceso puede repetirse durante varias rondas, mientras la información de continuidad se transmite dentro de la carga útil, por lo que la operación no necesita una sesión.
El McpClient de alto nivel gestiona MRTR automáticamente después de registrar los controladores correspondientes. La versión también puede utilizar un puente de compatibilidad con clientes antiguos cuando existe una sesión con estado. En cambio, un cliente antiguo que funcione sin sesión no puede ejecutar la interacción de varias rondas, por lo que la herramienta debe proporcionar una vía alternativa, como pasar directamente el valor requerido en un parámetro de la llamada.
Compatibilidad y paquetes disponibles
Las API estables y no obsoletas de 1.x siguen compilándose y ejecutándose en 2.0, mientras que los cambios obsoletos aparecen como advertencias y no como eliminaciones. Un cliente 2.0 puede utilizar el antiguo intercambio de inicialización al conectarse a un servidor antiguo, y un servidor 2.0 también acepta ese intercambio de un cliente antiguo.
La única excepción en la compatibilidad del protocolo es la extensión Tasks; su diseño revisado en 2.0 sustituye a la versión experimental de Tasks presente en la especificación 2025-11-25 y no es compatible con ella a nivel de interfaz ni de protocolo. Tasks está ahora disponible en el paquete independiente ModelContextProtocol.Extensions.Tasks, mientras que las MCP Apps experimentales se incluyen en ModelContextProtocol.Extensions.Apps.
Los paquetes principales incluyen ModelContextProtocol.Core para el cliente y los componentes de bajo nivel, ModelContextProtocol para la mayoría de los servidores y ModelContextProtocol.AspNetCore para servidores Streamable HTTP. La publicación señala que el siguiente foco de la serie 2.x será la autenticación y autorización integrales, basadas en una compatibilidad más estrecha con OAuth y OpenID Connect.