Remote MCP Server in 2026: Stateless, Authenticated, Deployable

1. The Problem: Sessions Pin Clients to Nodes

From 2025-03-26 through 2025-11-25, a Streamable HTTP server could mint an Mcp-Session-Id, keep per-connection state in memory, send its own requests to the client over SSE streams and let clients resume broken streams with Last-Event-ID. That works on one box. Behind a load balancer or on serverless functions it needs sticky routing, shared stores and event replay — the TypeScript SDK’s own docs describe the sessionful setup as a map of transports routed by the session header, plus idle timers, a session cap and 404 handling for unknown ids.

The new revision flips the default. The protocol is request/response and stateless, and a server that genuinely needs cross-call state returns an explicit, server-minted handle that the model passes back as an ordinary tool argument (SEP-2567). The result is a server any instance can answer, which is exactly what horizontal scaling and serverless platforms want. The price is a migration: the blog is upfront that there will be some migration cost, especially for developers who depended on session identifiers.

2. Minimum Concepts Before Touching Code

Six ideas explain almost everything that changed on the server side. Get these straight and the code below reads like plain English.

3. Step 1 — A Minimal Server with the TypeScript SDK v2

I use the official TypeScript SDK v2: the @modelcontextprotocol/server package, whose npm latest tag was 2.3.1 (published 2026-10-05) at the time of writing, with Node.js 20+ and Zod 4 as its schema library. The older @modelcontextprotocol/sdk package is the v1 line (latest 1.32.1 on the same date). The key function is createMcpHandler: you give it a factory that returns a fresh McpServer and you get back an object whose fetch is a web-standard (Request) => Promise<Response>.

TypeScript — one tool, one handler (SDK docs: 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;
});

That handler is not listening yet. On plain Node you wrap it with toNodeHandler from @modelcontextprotocol/node, bind loopback explicitly and put the Host and Origin guards in front: the handler validates neither, and the spec says servers MUST validate the Origin header and answer 403 when it is invalid, to stop DNS rebinding.

TypeScript — mount on node:http (SDK docs: 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. Step 2 — Authentication: Be a Resource Server, Not an Auth Server

Authorization is optional in the spec, but any remote server that touches user or business data needs it. The model is simple: your MCP server is an OAuth 2.1 resource server and never issues tokens. It answers unauthenticated requests with 401 and a WWW-Authenticate header whose resource_metadata parameter points at your RFC 9728 Protected Resource Metadata; that document lists at least one entry in authorization_servers; and the server accepts only tokens issued specifically for it (RFC 8707). Tokens travel in the Authorization: Bearer header on every request, never in the query string.

TypeScript — bearer gate on a web-standard host (SDK docs: Require authorization)

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

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

// verifier = { verifyAccessToken }, defined in the next snippet
const gate = requireBearerAuth({ verifier, requiredScopes: ['mcp'], expectedResource: mcpServerUrl });
const handler = createMcpHandler(buildServer); // buildServer = the factory from Step 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 });
    }
};

The one function you supply is verifyAccessToken: take the raw token string, return an AuthInfo. Local JWT verification, RFC 7662 introspection or a call to your identity provider all fit behind it. Report the audience entry that matches your server in AuthInfo.resource so expectedResource can compare it, and always populate expiresAt.

TypeScript — token verifier (SDK docs; verifyJwt is your own JWT library call)

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 };
}

Clients find your authorization server through the metadata. The spec lets you advertise it in the WWW-Authenticate challenge, at a well-known URI that includes the endpoint path (for example /.well-known/oauth-protected-resource/mcp) or at the root. On a fetch-native host the SDK’s oauthMetadataResponse serves those documents and returns undefined for anything else, so you fall through to your own routing.

TypeScript — serve metadata (SDK docs) and the 401 challenge (spec example)

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. Step 3 — Deploy Where Stateless Shines (Vercel and Friends)

Because every request is self-contained, the handler is a function from Request to Response. That fits any fetch-native runtime: the SDK docs mount it with export default handler on Cloudflare Workers, Deno and Bun, and Node frameworks use toNodeHandler. On Vercel, the platform’s docs (last updated 2026-09-18) deploy MCP servers as Vercel Functions in a Next.js App Router app with the mcp-handler package, pinning mcp-handler@2.1.1 next to @modelcontextprotocol/server@2 and Zod 4; npm’s latest tag for mcp-handler was 2.3.0 on 2026-10-14. Version 2 dropped HTTP+SSE and Redis configuration.

TypeScript — app/api/mcp/route.ts with mcp-handler (shape from the Vercel docs)

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 };

Auth uses helpers from the same package. withMcpAuth wraps the route with a token verifier, a required flag and required scopes, and protectedResourceHandler serves the metadata document from app/.well-known/oauth-protected-resource/route.ts. Vercel’s docs are explicit that the package verifies bearer tokens and publishes metadata but does not issue tokens, and that production verification must check issuer, audience, expiration and scopes.

TypeScript — auth wrapper and metadata route (shape from the Vercel docs)

// 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. Step 4 — Test with the Inspector CLI and curl

The MCP Inspector defaults to the legacy era (plain initialize, no probing), so for this spec you opt in: --protocol-era modern pins 2026-07-28 with no fallback, and auto probes server/discover and falls back to initialize. The CLI runs one method per invocation and returns stable exit codes, which makes it CI-friendly: 3 means the server demands authentication, 4 means it is unreachable and 5 means a tool returned isError.

Bash — Inspector CLI against a remote server (flags from the Inspector docs)

# 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"

When you want to see the bytes, curl is enough because there is no handshake to perform. This request is assembled from the spec’s own examples: the three required headers plus the _meta envelope. Add an Authorization: Bearer header once the gate is on.

curl — a raw tools/call (assembled from the spec’s Streamable HTTP examples)

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. Migration Checklist: From Stateful or SSE to 2026-07-28

If you run a stateful or SSE-era server today, this is the order I would follow. The SDK ships a codemod and the spec defines a compatibility matrix, so you do not need a flag day.

8. Common Errors (Mostly Fixable in an Afternoon)

These are the failures the spec and SDK docs warn about most often. The left column is what working deployments do; the right column is what pages you at night.

Conclusion

The 2026-07-28 revision turns the remote MCP server into something most backend engineers already know how to run: a stateless HTTP endpoint behind OAuth. You saw the full path: createMcpHandler for a per-request server, a bearer gate with Protected Resource Metadata, a Vercel-style deployment, tests in the modern era and a migration checklist for stateful and SSE servers.

This week, take one existing server, run the codemod on a branch, swap the transport for createMcpHandler and test it with --protocol-era modern. Then decide, tool by tool, which hidden state becomes an explicit handle. If Python is your stack, the official SDK is listed as Tier 1 and speaks 2026-07-28 according to the MCP blog (mcp was at 2.3.0 on PyPI on 2026-10-02, fastmcp at 4.1.0 on 2026-10-08); check their release notes for exact behavior. I used TypeScript because its docs include the HTTP and auth recipes used here.

Sources

• MCP blog — The 2026-07-28 release (stateless core, deprecations, SDK support)
• MCP spec 2026-07-28 — Key changes (changelog)
• MCP spec 2026-07-28 — Streamable HTTP transport (headers, Origin validation, backward compatibility)
• MCP spec 2026-07-28 — Authorization (resource server, metadata, scopes, audience)
• MCP spec 2026-07-28 — server/discover
• TypeScript SDK v2 docs — Serve over HTTP (createMcpHandler)
• TypeScript SDK v2 docs — Require authorization (requireBearerAuth, metadata)
• TypeScript SDK v2 docs — Upgrade from v1.x (codemod, transports, auth split)
• Vercel docs — Deploy MCP servers to Vercel (mcp-handler, withMcpAuth)
• MCP Inspector docs — CLI client and protocol eras
• AAIF — What is changing and how to migrate (release-candidate era post)