> ## Documentation Index
> Fetch the complete documentation index at: https://redop.useagents.site/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Transport Model and Compatibility

> Understand how Redop chooses transports, what HTTP and stdio expose, and what the current HTTP transport optimizes for.

Redop currently supports two transports:

* `http`
* `stdio`

HTTP can run as:

* Bun `.listen(...)` (default long-running server)
* a portable `app.handler()` fetch function via runtime adapters (Cloudflare, Vercel, Node)

## How transport selection works

* `listen(3000)` defaults to HTTP
* `listen({ port: ... })` defaults to HTTP
* `listen({ transport: "stdio" })` forces stdio
* `listen({ transport: "http" })` forces HTTP

## HTTP in practice

The HTTP transport gives you:

* a network endpoint at `/mcp`
* **MCP `2026-07-28`**: stateless requests (no session), `server/discover`, `Mcp-Method` / `Mcp-Name` routing headers, list cache hints, MRTR `input_required`, and `subscriptions/listen`
* **legacy versions**: session-aware client communication with `Mcp-Session-Id` and Inspector-style `GET` SSE
* an optional health endpoint when enabled
* transport debug logs with `debug: true`

## stdio in practice

The stdio transport gives you:

* a local command-based integration path
* no network port
* one strict rule: keep stdout clean for MCP messages
* the same protocol versions as HTTP, including `server/discover` and MRTR on `2026-07-28`

## Compatibility notes

The HTTP transport negotiates multiple MCP protocol versions. Prefer `2026-07-28` for scalable, load-balanced deployments. Older clients that speak `initialize` + sessions continue to work.
