Servidor MCP Remoto en 2026: Stateless, Autenticado y Desplegable

1. El Problema: Las Sesiones Atan al Cliente a un Nodo

Entre 2025-03-26 y 2025-11-25, un servidor Streamable HTTP podía generar un Mcp-Session-Id, guardar estado por conexión en memoria, enviar sus propias peticiones al cliente por streams SSE y dejar que los clientes reanudaran streams rotos con Last-Event-ID. Eso funciona en una sola máquina. Detrás de un balanceador o en funciones serverless exige routing sticky, almacenes compartidos y reproducción de eventos — la propia documentación del SDK de TypeScript describe el despliegue con sesiones como un mapa de transportes enrutado por la cabecera de sesión, más timers de inactividad, un tope de sesiones y un 404 para ids desconocidos.

La nueva revisión invierte el valor por defecto. El protocolo es petición/respuesta y stateless, y un servidor que de verdad necesita estado entre llamadas devuelve un handle explícito, generado por el servidor, que el modelo reenvía como un argumento normal de la herramienta (SEP-2567). El resultado es un servidor que cualquier instancia puede atender, justo lo que quieren el escalado horizontal y las plataformas serverless. El precio es una migración: el blog admite abiertamente que habrá algo de costo de migración, sobre todo para quienes dependían de identificadores de sesión.

2. Conceptos Mínimos Antes de Tocar Código

Seis ideas explican casi todo lo que cambió del lado del servidor. Con esto claro, el código de abajo se lee como lenguaje natural.

3. Paso 1 — Un Servidor Mínimo con el SDK de TypeScript v2

Uso el SDK oficial de TypeScript v2: el paquete @modelcontextprotocol/server, cuyo tag latest en npm era 2.3.1 (publicado el 2026-10-05) al momento de escribir, con Node.js 20+ y Zod 4 como librería de schemas. El paquete anterior @modelcontextprotocol/sdk es la línea v1 (latest 1.32.1 en la misma fecha). La función clave es createMcpHandler: le pasas una factory que devuelve un McpServer nuevo y recibes un objeto cuyo fetch es un (Request) => Promise<Response> estándar web.

TypeScript — una herramienta, un handler (docs del SDK: Serve over HTTP)

// npm install @modelcontextprotocol/server zod
import { createMcpHandler, McpServer } from '@modelcontextprotocol/server';
import * as z from 'zod/v4';

const handler = createMcpHandler(() => {
    const server = new McpServer({ name: 'notes', version: '1.0.0' });
    server.registerTool(
        'add-note',
        {
            description: 'Save a note',
            inputSchema: z.object({ text: z.string() })
        },
        async ({ text }) => ({ content: [{ type: 'text', text: `Saved: ${text}` }] })
    );
    return server;
});

Ese handler todavía no escucha en ningún puerto. En Node puro lo envuelves con toNodeHandler de @modelcontextprotocol/node, haces bind explícito a loopback y pones las guardas de Host y Origin por delante: el handler no valida ninguna, y la spec dice que los servidores DEBEN validar la cabecera Origin y responder 403 si es inválida, para frenar el DNS rebinding.

TypeScript — montar en node:http (docs del SDK: Serve over HTTP)

import { createServer } from 'node:http';
import {
    toNodeHandler,
    localhostHostValidation,
    localhostOriginValidation
} from '@modelcontextprotocol/node';

const nodeHandler = toNodeHandler(handler);
const validateHost = localhostHostValidation();
const validateOrigin = localhostOriginValidation();

createServer((req, res) => {
    if (!validateHost(req, res) || !validateOrigin(req, res)) return;
    void nodeHandler(req, res);
}).listen(3000, '127.0.0.1');

4. Paso 2 — Autenticación: Sé un Resource Server, No un Auth Server

La autorización es opcional en la spec, pero cualquier servidor remoto que toque datos de usuarios o de negocio la necesita. El modelo es simple: tu servidor MCP es un resource server de OAuth 2.1 y nunca emite tokens. Responde las peticiones sin autenticar con 401 y una cabecera WWW-Authenticate cuyo parámetro resource_metadata apunta a tu Protected Resource Metadata (RFC 9728); ese documento lista al menos una entrada en authorization_servers; y el servidor acepta solo tokens emitidos específicamente para él (RFC 8707). Los tokens viajan en la cabecera Authorization: Bearer en cada petición, nunca en el query string.

TypeScript — gate bearer en un host web-standard (docs del SDK: Require authorization)

import { createMcpHandler, requireBearerAuth } from '@modelcontextprotocol/server';

const mcpServerUrl = new URL('https://api.example.com/mcp');

// verifier = { verifyAccessToken }, definido en el siguiente snippet
const gate = requireBearerAuth({ verifier, requiredScopes: ['mcp'], expectedResource: mcpServerUrl });
const handler = createMcpHandler(buildServer); // buildServer = la factory del Paso 1

export default {
    async fetch(request: Request): Promise<Response> {
        const auth = await gate(request);
        if (auth instanceof Response) return auth;
        return handler.fetch(request, { authInfo: auth });
    }
};

La única función que escribes tú es verifyAccessToken: recibe el token en crudo y devuelve un AuthInfo. Verificación local de JWT, introspección RFC 7662 o una llamada a tu proveedor de identidad caben detrás. Reporta en AuthInfo.resource la audiencia que corresponde a tu servidor para que expectedResource pueda compararla, y rellena siempre expiresAt.

TypeScript — verificador de tokens (docs del SDK; verifyJwt es tu librería de JWT)

async function verifyAccessToken(token: string): Promise<AuthInfo> {
    const payload = await verifyJwt(token);
    // `aud` is one value, a list, or absent: report the entry on this server's origin, if any,
    // and let `expectedResource` compare it.
    const audience = [payload.aud ?? []].flat().find(aud => URL.canParse(aud) && new URL(aud).origin === mcpServerUrl.origin);
    const resource = audience ? new URL(audience) : undefined;
    return { token, clientId: payload.sub, scopes: payload.scopes, expiresAt: payload.exp, resource };
}

Los clientes encuentran tu servidor de autorización a través de la metadata. La spec te deja anunciarla en el challenge WWW-Authenticate, en una URI well-known que incluye la ruta del endpoint (por ejemplo /.well-known/oauth-protected-resource/mcp) o en la raíz. En un host fetch-native, oauthMetadataResponse del SDK sirve esos documentos y devuelve undefined para todo lo demás, así que sigues con tu propio routing.

TypeScript — servir la metadata (docs del SDK) y el challenge 401 (ejemplo de la spec)

import { oauthMetadataResponse } from '@modelcontextprotocol/server';

async function webStandardFetch(request: Request): Promise<Response> {
    // serveMcp = the gated fetch from the first snippet
    return oauthMetadataResponse(request, { oauthMetadata, resourceServerUrl: mcpServerUrl }) ?? serveMcp(request);
}

// What an unauthenticated client receives (spec example):
// HTTP/1.1 401 Unauthorized
// WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
//                          scope="files:read"

5. Paso 3 — Despliega Donde lo Stateless Brilla (Vercel y Similares)

Como cada petición es autocontenida, el handler es una función de Request a Response. Eso encaja en cualquier runtime fetch-native: la documentación del SDK lo monta con export default handler en Cloudflare Workers, Deno y Bun, y los frameworks de Node usan toNodeHandler. En Vercel, la documentación de la plataforma (actualizada el 2026-09-18) despliega servidores MCP como Vercel Functions dentro de una app Next.js App Router con el paquete mcp-handler, fijando mcp-handler@2.1.1 junto a @modelcontextprotocol/server@2 y Zod 4; el tag latest de mcp-handler en npm era 2.3.0 el 2026-10-14. La versión 2 eliminó HTTP+SSE y la configuración de Redis.

TypeScript — app/api/mcp/route.ts con mcp-handler (forma tomada de la documentación de Vercel)

import { createMcpHandler } from 'mcp-handler';
import { z } from 'zod';

const handler = createMcpHandler((server) => {
  server.registerTool(
    'add-note',
    {
      description: 'Save a note',
      inputSchema: z.object({ text: z.string() }),
    },
    async ({ text }) => ({
      content: [{ type: 'text', text: `Saved: ${text}` }],
    }),
  );
});

export { handler as GET, handler as POST };

La auth usa helpers del mismo paquete. withMcpAuth envuelve la ruta con un verificador de tokens, un flag required y los scopes requeridos, y protectedResourceHandler sirve el documento de metadata desde app/.well-known/oauth-protected-resource/route.ts. La documentación de Vercel es explícita: el paquete verifica bearer tokens y publica metadata pero no emite tokens, y la verificación en producción debe comprobar emisor, audiencia, expiración y scopes.

TypeScript — wrapper de auth y ruta de metadata (forma tomada de la documentación de Vercel)

// app/api/mcp/route.ts
import type { AuthInfo } from '@modelcontextprotocol/server';
import { createMcpHandler, withMcpAuth } from 'mcp-handler';

const handler = createMcpHandler(/* ...same factory as above... */);

const verifyToken = async (
  _req: Request,
  bearerToken?: string,
): Promise<AuthInfo | undefined> => {
  // Verify issuer, audience, expiry and scopes with your IdP here.
  // On success return { token: bearerToken, scopes: [...], clientId: '...' }.
  return undefined; // reject everything until real verification exists
};

const authHandler = withMcpAuth(handler, verifyToken, {
  required: true,
  requiredScopes: ['notes:write'],
  resourceMetadataPath: '/.well-known/oauth-protected-resource',
});

export { authHandler as GET, authHandler as POST };

// app/.well-known/oauth-protected-resource/route.ts
import {
  protectedResourceHandler,
  metadataCorsOptionsRequestHandler,
} from 'mcp-handler';

const metadata = protectedResourceHandler({
  authServerUrls: ['https://your-authorization-server-issuer.example'],
  resourceUrl: 'https://your-app.vercel.app/api/mcp',
});

const corsHandler = metadataCorsOptionsRequestHandler();

export { metadata as GET, corsHandler as OPTIONS };

6. Paso 4 — Prueba con el Inspector CLI y curl

El MCP Inspector usa por defecto la era legacy (initialize normal, sin probing), así que para esta spec hay que activarlo: --protocol-era modern fija 2026-07-28 sin fallback, y auto prueba server/discover y cae a initialize si falla. El CLI ejecuta un método por invocación y devuelve exit codes estables, lo que lo hace apto para CI: 3 significa que el servidor exige autenticación, 4 que no es alcanzable y 5 que una herramienta devolvió isError.

Bash — Inspector CLI contra un servidor remoto (flags de la documentación del Inspector)

# Pin the 2026-07-28 era and list tools
npx @modelcontextprotocol/inspector --cli http://127.0.0.1:3000/mcp \
  --transport http --protocol-era modern --method tools/list

# Same, with a bearer token
npx @modelcontextprotocol/inspector --cli https://mcp.example.com/mcp \
  --transport http --protocol-era modern \
  --header "Authorization: Bearer $MCP_TOKEN" --method tools/list

# Call a tool
npx @modelcontextprotocol/inspector --cli http://127.0.0.1:3000/mcp \
  --transport http --protocol-era modern \
  --method tools/call --tool-name add-note --tool-arg text="ship the release notes"

Cuando quieres ver los bytes, curl alcanza porque no hay handshake que hacer. Esta petición está armada con los propios ejemplos de la spec: las tres cabeceras requeridas más el envelope _meta. Añade una cabecera Authorization: Bearer cuando actives el gate.

curl — un tools/call en crudo (armado con los ejemplos de Streamable HTTP de la spec)

curl -i -X POST http://127.0.0.1:3000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/call' \
  -H 'Mcp-Name: add-note' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"add-note","arguments":{"text":"hello"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientInfo":{"name":"curl","version":"0.0.1"},"io.modelcontextprotocol/clientCapabilities":{}}}}'

7. Checklist de Migración: de Servidores con Estado o SSE a 2026-07-28

Si hoy tienes un servidor con estado o de la era SSE, este es el orden que seguiría. El SDK incluye un codemod y la spec define una matriz de compatibilidad, así que no necesitas un flag day.

8. Errores Comunes (Casi Todos Arreglables en una Tarde)

Estos son los fallos sobre los que más advierten la spec y la documentación del SDK. La columna izquierda es lo que hacen los despliegues que funcionan; la derecha es lo que te despierta de noche.

Conclusión

La revisión 2026-07-28 convierte al servidor MCP remoto en algo que casi cualquier ingeniero backend ya sabe operar: un endpoint HTTP stateless detrás de OAuth. Viste el camino completo: createMcpHandler para un servidor por petición, un gate bearer con Protected Resource Metadata, un despliegue estilo Vercel, pruebas en la era moderna y un checklist de migración para servidores con estado y SSE.

Esta semana, toma un servidor existente, corre el codemod en una rama, cambia el transporte por createMcpHandler y pruébalo con --protocol-era modern. Después decide, herramienta por herramienta, qué estado oculto pasa a ser un handle explícito. Si tu stack es Python, el SDK oficial figura como Tier 1 y habla 2026-07-28 según el blog de MCP (mcp estaba en 2.3.0 en PyPI el 2026-10-02 y fastmcp en 4.1.0 el 2026-10-08); revisa sus notas de versión para el comportamiento exacto. Usé TypeScript porque su documentación incluye las recetas de HTTP y auth que usé aquí.

Fuentes

• Blog de MCP — La versión 2026-07-28 (núcleo stateless, deprecaciones, soporte de SDKs)
• Spec MCP 2026-07-28 — Cambios clave (changelog)
• Spec MCP 2026-07-28 — Transporte Streamable HTTP (cabeceras, validación de Origin, compatibilidad)
• Spec MCP 2026-07-28 — Autorización (resource server, metadata, scopes, audiencia)
• Spec MCP 2026-07-28 — server/discover
• Docs del SDK TypeScript v2 — Serve over HTTP (createMcpHandler)
• Docs del SDK TypeScript v2 — Require authorization (requireBearerAuth, metadata)
• Docs del SDK TypeScript v2 — Actualizar desde v1.x (codemod, transportes, split de auth)
• Docs de Vercel — Deploy MCP servers to Vercel (mcp-handler, withMcpAuth)
• Docs del MCP Inspector — cliente CLI y eras de protocolo
• AAIF — Qué cambia y cómo migrar (post de la era release candidate)