A Atenea orchestration core
GitHub

Atenea documentation

MCP compatibility

On this page

MCP compatibility#

Atenea recognizes the exact MCP revisions 2025-06-18 (legacy) and 2026-07-28 (modern). The names and validation policy live in internal/mcpcompat; transports do not silently substitute one revision for the other.

Legacy uses initialize/initialized and may keep a transport session. Modern requests are self-contained: they carry the reserved protocol, client identity and capability metadata in params._meta. Modern HTTP requests use the protocol and method headers and do not send Mcp-Session-Id; modern stdio requests keep JSON-RPC framing and use the same reserved metadata.

The core creates a temporary application session for each modern dispatch and closes it before sending the response. The observed client and capabilities are context, never a permission grant. A workflow can continue across calls only through its explicit persisted identifier; transport reconnects do not carry application permissions or hidden client state.

Both transports preserve cancellation semantics for their era. HTTP modern cancellation closes the request context, while legacy cancellation uses the protocol notification. stdio cancellation uses notifications/cancelled for both eras. Reconnection re-establishes the selected protocol and keeps the application allow-list separate from the transport lifecycle.

Modern results share the MRTR contract. complete is accepted; input_required is preserved as untrusted data, including the inputRequests map, opaque requestState string and any inputResponses field, and is reported to the caller. inputResponses is a retry parameter and does not make a server result valid by itself. Atenea does not execute those requests, manufacture responses or retry them automatically. The current core does not initiate an MRTR input exchange; interactive input handling remains a future, explicit capability.

Modern server/discover is validated as a cacheable result with an object capabilities value and a version intersection. The core advertises only its modern stateless revision and its actual tools/prompts capabilities. A future peer version may appear alongside modern and is ignored until supported. Modern-pin performs and validates discovery before its first request on HTTP, stdio and passthrough transports. HTTP passthrough mirrors valid primitive x-mcp-header tool arguments into Mcp-Param-*, with strict RFC token names, safe integer handling and encoded non-header-safe string values.

The compatibility tests cover local Unix-socket core dispatch, streamable HTTP, stdio, probes and passthrough backends. They do not claim that every external desktop client or remote MCP server has been functionally validated.