Transports
EDITED MCP speaks Streamable HTTP — a single endpoint that handles both standard request/response and, where needed, server-pushed events over SSE.
| Transport | Used here? | Notes |
|---|---|---|
| stdio | no | Process-local; clients spawn the server as a child |
| SSE (legacy) | no | Replaced by Streamable HTTP in the 2025-06 spec |
| Streamable HTTP | yes | One endpoint at /mcp accepting POST JSON-RPC |
Endpoint
POST https://mcp.edited.com/mcp
No trailing slash. The gateway answers at /mcp; the /mcp/ form gets a
307 redirect to an absolute plain-http URL, which HTTP clients either
refuse to follow or follow in a way that drops the request body. Symptoms of
the slashed form: bare 307 responses from curl, failed handshakes from SDK
clients, and 405 errors from clients that fall back to the legacy SSE
transport (EDITED MCP doesn't serve SSE).
Required headers:
| Header | Value |
|---|---|
Content-Type | application/json |
Accept | application/json, text/event-stream |
x-api-key | YOUR_API_KEY |
Optional:
| Header | Value |
|---|---|
MCP-Protocol-Version | the negotiated revision, e.g. 2025-06-18 |
The official SDKs send MCP-Protocol-Version automatically — and the
2025-06-18 spec requires clients to send it, so it's optional only in the
sense that this gateway doesn't enforce that. The gateway accepts it, doesn't
validate it, and does not use it to select a protocol revision — that
happens in initialize. See
Versioning → Protocol version.
The body is a single JSON-RPC 2.0 envelope. A batch array of envelopes is also
accepted, up to a cap of 64 — a larger batch is rejected with HTTP 400 /
-32600. But JSON-RPC batching was removed from MCP in 2025-06-18 — treat it
as backwards compatibility for older clients rather than something to build on,
and send one envelope per request.
Authentication
Every request must carry an x-api-key header. Without a key — or with one
that isn't enabled for MCP — the server replies 401 Unauthorized. Replace
YOUR_API_KEY above with your own key; see
Authentication & access for how to get one
and keep it safe.
Response shape
The server replies with one of:
Content-Type: application/json— a single JSON-RPC response (most calls)Content-Type: text/event-stream— an SSE stream of one or more responses, used for long-running operations and progress notifications
The protocolVersion coming back is the negotiated revision — the one you
offered if we speak it, otherwise our newest. Because the server is
stateless, that answer is scoped to the initialize response
itself: nothing here remembers it afterwards, and no later call behaves
differently because of it. See
Versioning → Protocol version.
Stateless mode
The server runs statelessly, so:
- Every request is independent — no session ID to track
- No per-client state lives between calls
- Any replica can serve any request, so horizontal scaling is trivial
A client that ignores Mcp-Session-Id headers entirely still works against
this server — it simply doesn't issue them.
Why HTTP and not stdio?
EDITED MCP depends on shared backend services, so a process-per-client (stdio) model isn't practical. HTTP is the right shape for a service tier; stdio is the right shape for local desktop integrations.
If you specifically need stdio (e.g. air-gapped Claude Desktop), see
Recipes → Connect Claude Desktop — Claude
Desktop reaches remote servers via the mcp-remote proxy, which bridges stdio
to HTTP.