Independent

gaikwad.madhav@gmail.com https://github.com/mcpx-project

ART Independent Submission proxy gateway agent intermediary MCP Agent-tool protocols such as the Model Context Protocol (MCP) enable AI applications to discover and invoke external tools, resources, and prompts through a standardized JSON-RPC interface. As deployments scale, intermediaries (proxies, gateways, sidecars) are inserted between clients and servers to provide transport adaptation, capability aggregation, security enforcement, and operational governance. No specification currently defines the behavioral requirements for such intermediaries. This document establishes a taxonomy of proxy modes, a layered architecture for pluggable proxy functionality, and normative requirements for each mode. It is designed to be protocol-agnostic in its architecture while referencing MCP as the primary instantiation.

Introduction

Problem Statement Agent-tool protocols define how AI clients discover and invoke capabilities exposed by servers. The Model Context Protocol is the protocol for which the largest number of independent intermediary implementations is known to the author, and is used throughout as the worked instantiation. Production deployments routinely insert intermediaries between clients and servers. The author surveyed twelve MCP intermediary implementations in Q1 2026, listed in Appendix E. Each had arrived independently at its own semantics for namespace collision resolution, session management, authentication propagation, capability aggregation, and failure handling. No two of the twelve could be substituted for one another without changing client or server configuration, which is the property this document exists to supply. The survey is a convenience sample of implementations that were public and documented at that date. It is not exhaustive, and the count should be read as a lower bound on the population rather than a measurement of it. The requirements in this document are written in terms of an abstract agent-tool protocol. MCP is used throughout as the worked instantiation because it is the protocol for which implementation experience exists (); the taxonomy and layer model are intended to apply to any JSON-RPC agent-tool protocol with capability discovery. This fragmentation mirrors the early history of HTTP proxying, which was resolved through a series of RFCs (RFC 2616, RFC 7230, RFC 9110) that defined proxy behavior normatively. Agent-tool protocols require equivalent treatment.

Scope This document defines:

• A taxonomy of proxy modes applicable to agent-tool protocols
• A layered architecture enabling pluggable proxy functionality
• Normative behavioral requirements per mode and per layer
• Security considerations specific to intermediaries in agent-tool protocol deployments

This document does not define:

• The agent-tool protocol itself (see )
• Transport-layer specifications, which are defined by each agent-tool protocol
• Specific authentication protocols (see )

Relationship to Other Specifications This document references and builds upon:

• Model Context Protocol for protocol-specific semantics
• for HTTP proxy terminology
• for token propagation patterns
• for authorization server identification
• for proxy hop tracing precedent
• W3C Trace Context for distributed tracing

Relationship to Agent-Tool Protocol Governance Agent-tool protocols such as MCP are specified and governed outside the IETF. This document does not modify any such protocol and imposes no requirements on protocol specifications, their maintainers, or their conformance processes. Its normative requirements apply solely to intermediaries, and only to those that claim conformance to this document. Where a protocol community adopts these requirements, it does so through its own process and its own document, which is self-contained and normatively independent of this one. A companion specification for MCP exists on that basis ().

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Definitions Agent-Tool Protocol: A JSON-RPC-based protocol enabling AI applications (clients) to discover and invoke capabilities (tools, resources, prompts) exposed by servers. MCP is the primary example. Client: An application that initiates connections and sends requests for tool discovery, invocation, and resource access. Server: A process that exposes tools, resources, and prompts to clients via the agent-tool protocol. Intermediary: Any component inserted into the communication path between a client and one or more servers. Synonyms include "proxy," "gateway," and "sidecar." Backend: A server as seen from the perspective of an intermediary. An intermediary may connect to one or more backends. Capability Surface: The set of tools, resources, and prompts that an entity (server or intermediary) advertises to its clients. Namespace: A scoping mechanism that prevents name collisions when an intermediary aggregates capabilities from multiple backends. Mode: A classification of intermediary behavior based on protocol awareness, deployment position, and client visibility. Layer: A functional stratum within an intermediary's processing pipeline, with defined input/output interfaces. Transport: The wire protocol used for message delivery (e.g., stdio, SSE, Streamable HTTP, WebSocket). Binding: The mapping of this document's abstract requirements onto a specific agent-tool protocol. A binding is a separate document, produced by that protocol's own process.

Binding-Defined Parameters This document specifies intermediary behavior in terms of an abstract agent-tool protocol. Seven parameters are left to the binding. A binding MUST define each; this document uses the terms below wherever the value would otherwise appear. A binding MUST additionally state whether the protocol carries an initialization handshake, which selects between the dispositions of . gives these values for two protocols.

Proxy Mode Taxonomy This document defines seven proxy modes. Modes are not mutually exclusive; a single intermediary MAY implement multiple modes simultaneously.

Mode Classification Axes Modes are classified along three axes:

1. Protocol awareness: Whether the intermediary understands agent-tool protocol semantics (message types, tool names, capability negotiation) or operates on raw transport data.

1. Deployment position: Whether the intermediary is deployed by the client operator (client-side), the server operator (server-side), or the network operator (network-side).

1. Client visibility: Whether the client is configured to address the intermediary explicitly or is unaware of its presence.

Mode Summary

Mode Topologies The three axes above resolve into four distinct placements. ==> marks a link the client explicitly addresses; --> marks a link the client does not know it is traversing. I ---> backend(s) client-addressed, one hop, client knows the hop exists Reverse, Conversion client ==> I ---> backend(s) client addresses I believing I is the backend Transparent client ---> [ I ] ---> backend client addresses the backend; the network diverts the connection through I Sidecar client ---> I ---> backend +--- co-located ---+ I is bound to one backend at the same host or pod Federation client ==> I ---> I' ---> backend I' is itself an intermediary; hops chain ]]> Relay and Forward differ in protocol awareness, not topology. Reverse and Conversion differ in whether the backend speaks the agent-tool protocol at all.

Layered Proxy Architecture An intermediary's processing pipeline is organized into seven layers. Each layer defines an interface contract. Implementations MUST implement Layer 1 (Transport). All other layers are OPTIONAL and independently pluggable. OPTIONAL means optional to implement; an intermediary that implements a layer MUST satisfy that layer's normative requirements. names the conformance classes that group these layers.

Layer Stack

Layer Independence and Conformance Tiers Each layer MUST define its interface independently of other layers. Swapping the implementation of one layer MUST NOT require changes to adjacent layers. This ensures:

• A minimal transport-adapting intermediary implements Layer 1 only.
• A routing intermediary adds Layers 2 and 3.
• A full intermediary implements all seven layers.
• All conform to the same specification at different levels.

These groupings are the named conformance tiers:

Tier	Layers
Tier 1	Layer 1
Tier 2	Layers 1-3
Tier 3	Layers 1-7

An intermediary MUST declare the highest tier it satisfies. An intermediary above Tier 1 MUST also declare its mode set (). A tier names layer coverage only. The mode taxonomy of is a separate axis, declared independently, and the awareness levels of apply only within Transparent mode. The three are not interchangeable, so an intermediary declares a tier, a mode set, and, for Transparent mode, an awareness level. The tiers are named by number rather than reusing mode names, so that a declaration cannot be read as a mode.

Layer Invocation Order A client-to-server message traverses the stack upward, 1 through

1. A server-to-client message, including a reverse request such as

sampling or elicitation, traverses it downward, 7 through 1. The stack is therefore symmetric, and a layer sees both directions. policy applies ^ | in both directions L4 Resilience | ^ | L3 Routing | ^ v L2 Discovery | ^ | +---> L1 Transport -----+---> to backend | from client ]]> A layer that is not implemented is skipped in both directions.

Mode Definitions

Relay Mode A Relay intermediary performs transport adaptation without understanding agent-tool protocol semantics. It operates on raw byte streams or deserialized JSON-RPC envelopes without inspecting their content. Requirements:

• MUST forward all messages bidirectionally without modification.
• MUST NOT perform capability negotiation with either endpoint.
• MUST NOT perform a separate initialization handshake with the backend; client initialization messages are forwarded as-is.
• SHOULD bridge between different transport types (e.g., stdio to Streamable HTTP).
• MAY buffer messages during transport reconnection.

Applicable layers: Layer 1 only. Illustrated by: sparfenyuk/mcp-proxy, Supergateway (Appendix E).

Forward Proxy Mode A Forward proxy is explicitly configured by the client and operates with full protocol awareness. The client sends all agent-tool protocol messages to the proxy, which routes them to the appropriate backend(s). Requirements:

• MUST perform its own initialization handshake with each backend.
• MUST present a unified capability surface to the client.
• MUST resolve namespace collisions when aggregating multiple backends (see ).
• MUST forward bidirectional messages (server-to-client requests such as sampling, elicitation, progress, and logging).
• SHOULD implement Layers 1-3. MAY implement Layers 4-7.
• SHOULD maintain session isolation between concurrent clients by default.
• MAY cache capability lists (tools/list, resources/list, prompts/list) subject to the capability layer requirements in , and MUST invalidate a cached list when the originating backend signals that its capability surface has changed or when that backend is marked unhealthy.

Applicable layers: Layers 1-3 (minimum), all layers (maximum). Illustrated by: FastMCP proxy, MCProxy, plugged.in, MCPJungle (Appendix E).

Reverse Proxy Mode A Reverse proxy is deployed by the server operator and is transparent to clients. The client believes it is communicating directly with a server. Requirements:

• MUST present itself as a standard agent-tool protocol server to clients.
• MUST perform independent initialization handshakes with backend servers.
• MUST support session affinity or session replication when operating in stateful protocol modes.
• SHOULD implement backend health checking (Layer 2).
• SHOULD support dynamic backend addition and removal without client disconnection.
• MAY perform load balancing across multiple instances of the same backend server.

Applicable layers: Layers 1-3 (minimum), all layers (maximum). Illustrated by: Microsoft mcp-gateway, agentgateway (Appendix E).

Transparent Mode A Transparent intermediary intercepts agent-tool protocol traffic at the network layer without client or server configuration. Traffic is redirected to the intermediary via routing rules (e.g., iptables TPROXY/REDIRECT, WCCP, DNS- based interception, policy-based routing). This mode applies ONLY to HTTP-based transports. Non-HTTP transports (e.g., stdio) have no network path to intercept.

Awareness Levels Transparent intermediaries operate at one of two awareness levels. An implementation MUST declare which level it supports. Level 1 (Transport-aware): The intermediary inspects HTTP-layer metadata (headers, URI path) without parsing JSON-RPC request or response bodies. Level 2 (Protocol-aware): The intermediary parses JSON-RPC message bodies and may modify, filter, or compose messages with full protocol understanding. This distinction exists because body inspection is computationally expensive and introduces latency. Level 1 provides useful policy enforcement (rate limiting, access control by method type) at near-zero overhead. Level 2 enables full intermediary functionality at higher cost.

General Requirements Interception is a deployment concern, distinct from the transparent-mode protocol behavior defined here. The requirements of this section apply regardless of how interception is achieved, and the mechanism MAY be supplied by the surrounding network infrastructure rather than by the intermediary itself.

• MUST NOT require client-side configuration changes.
• MUST resolve each intercepted connection to exactly one backend, using either the preserved original destination or an explicit mapping supplied by the deployment.
• Where the intermediary performs its own interception, it MUST support at least one interception mechanism (IP redirect, DNS interception, or policy-based routing), and MUST preserve the original destination address. Implementations using IP-level redirect MUST use SO_ORIGINAL_DST or the platform equivalent to recover it.

Original-destination recovery is platform-specific and is not a protocol requirement. An intermediary that accepts an integration-provided backend selection conforms to this section without implementing any interception mechanism of its own, but MUST document which mechanism it expects and how the original destination reaches it. Without that statement the deployment assumption is unverifiable and the conformance claim cannot be checked.

Level 1 Requirements

• MUST forward all messages (including initialization handshakes) without modification. The client and backend negotiate directly (single-handshake passthrough).
• MUST NOT perform an independent initialization handshake with the backend.
• MUST NOT modify request or response bodies.
• MUST NOT implement namespace management (tools are not aggregated and names are not rewritten).
• MAY inspect transport-layer headers for policy decisions (rate limiting, logging, access control). Header-based routing at this level depends on the binding defining headers that carry method and target; MCP does so in .
• MAY log intercepted traffic to an external telemetry pipeline without injecting data into the message stream.
• MUST forward all bidirectional messages (server-to-client requests) unmodified.
• MUST NOT implement circuit breakers. Transport errors from the backend MUST be forwarded to the client as-is.

Applicable layers: Layer 1 (Transport), Layer 5 (Policy - header-based filtering only).

Level 2 Requirements

• MUST parse JSON-RPC message bodies to make routing, filtering, and policy decisions.
• MAY perform an independent initialization handshake with the backend (dual-handshake). If so, all requirements for Forward mode capability negotiation apply.
• MAY modify messages (inject metadata, filter capability lists, enforce content policies).
• MUST implement namespace management () when routing to multiple backends.
• MAY implement circuit breakers, subject to the constraint that for single-backend deployments the intermediary MUST NOT fabricate JSON-RPC responses (the client believes it is talking directly to the backend).
• MAY filter or block bidirectional messages (sampling, elicitation) per policy configuration.

Applicable layers: Layers 1-5 (typical), optionally Layers 6-7.

TLS Considerations TLS termination MAY be performed by the surrounding infrastructure (for example a TLS-terminating load balancer in front of the intermediary), in which case the intermediary operates on an already-decrypted stream and the requirements below apply to whichever component terminates TLS. Three dispositions are distinguished: Passthrough. The encrypted stream is forwarded without being decrypted. No certificate is presented and no CA trust change is required. Body inspection is impossible, so this disposition is available only to Level 1 intermediaries, and only those whose policy decisions derive from connection-level metadata rather than HTTP headers. Termination and re-origination. The intermediary terminates the client's TLS connection and opens a separate TLS connection to the backend. It MUST present a certificate matching the original destination hostname, requiring either dynamic certificate generation or wildcard certificates, and the client MUST trust the issuing CA (typically distributed via enterprise CA management). This disposition is required for any inspection of HTTP headers or message bodies, and therefore for any Level 2 function and for header-based Level 1 filtering. Plaintext. For unencrypted transports, TLS considerations do not apply. The intermediary SHOULD log a warning when operating on plaintext traffic outside a development environment. An intermediary MUST declare which disposition it implements. The intermediary MUST NOT downgrade TLS (intercepting an encrypted connection and forwarding plaintext) unless explicitly configured within a trusted network boundary.

Authentication Constraints Transparent intermediaries face unique authentication constraints. The client is unaware of the intermediary's existence, so the intermediary MUST NOT initiate authentication flows (e.g., OAuth redirects) with the client. Client identity is limited to:

• Inspecting existing credentials on intercepted requests.
• Network-level identity (source IP, mTLS, VLAN).
• Enterprise identity infrastructure (service mesh, SSO tokens injected by network fabric).

The RECOMMENDED token propagation pattern for Transparent mode is Passthrough (, pattern 2) because the backend expects to authenticate the client directly. This is an exception to the general recommendation of Credential Injection for other modes. Illustrated by: see .

Sidecar Mode A Sidecar intermediary is deployed alongside a single backend server (typically in the same container pod or host) and intercepts all traffic to/from that server. Requirements:

• MUST be transparent to both clients and the co-located server.
• MUST forward all protocol messages, applying configured interceptors at defined extension points (pre-request, post-request, pre-response, post-response).
• SHOULD support pluggable interceptors for validation, mutation, and observation (see Layer 5).
• MUST NOT aggregate capabilities from multiple backends (this distinguishes it from Forward and Reverse modes).

Applicable layers: Layers 1, 4, 5 (typical). Illustrated by: no shipping implementation was identified in the survey; the interceptor model of is the nearest proposal.

Federation Mode A Federation intermediary aggregates other intermediaries (not direct backend servers) into a hierarchical topology. This enables multi-level organizational structures. Requirements:

• MUST support chained namespace resolution across multiple levels of intermediary.
• MUST propagate authentication context across intermediary hops.
• MUST include hop-tracing metadata (see ) to enable end-to-end request tracing.
• SHOULD support heterogeneous protocol versions across federated intermediaries.
• SHOULD define a federation discovery mechanism enabling intermediaries to find and negotiate with each other.

Applicable layers: All layers. Illustrated by: no complete implementation was identified in the survey. MetaMCP provided partial support, one endpoint per namespace (Appendix E).

Conversion Mode A Conversion intermediary translates a non-agent-tool protocol (e.g., REST/OpenAPI, gRPC) into agent-tool protocol semantics, presenting the converted capabilities as native tools. Requirements:

• MUST generate valid tool schemas from the source protocol's schema definitions (e.g., OpenAPI operation -> MCP tool).
• MUST preserve the source protocol's authentication requirements and propagate them appropriately.
• SHOULD generate tool descriptions suitable for LLM consumption from source protocol documentation.
• MAY cache converted schemas with appropriate invalidation.

Applicable layers: Layers 1-3, plus a protocol translation sublayer between Layers 1 and 2. Illustrated by: Kong ai-mcp-proxy, agentgateway, Unla (Appendix E).

Layer Interface Specifications

Layer 1: Transport Interface: Pluggable components:

• Transport adapter (stdio <-> SSE <-> Streamable HTTP <-> WebSocket)
• TLS termination/origination
• Compression/decompression

Requirements:

• MUST support at least one client-facing and one backend-facing transport type.
• SHOULD support multiple transport types simultaneously.
• MUST preserve message boundaries across transport translations.

Layer 2: Discovery Interface: Pluggable components:

• Backend registry (static file, service discovery, API-driven self-registration)
• Health checker (passive failure detection, active probing via JSON-RPC ping, MCP-native capability polling)
• Topology manager (add/remove backends at runtime, hot reload)

Requirements:

• MUST support at least static backend configuration.
• SHOULD support dynamic backend addition and removal without client disconnection.
• SHOULD implement health checking with configurable intervals.
• MUST emit backend status change events to Layer 4 (Resilience).

Layer 3: Routing Interface: Pluggable components:

• Namespace resolver (prefix-based, priority-based, manual mapping, passthrough)
• Fan-out strategy (for list methods: parallel query all backends; for call methods: single-target lookup)
• Response aggregator (for fan-out: merge, deduplicate, order)

Requirements:

• MUST fan out each LIST-METHOD to all healthy backends and aggregate the responses.
• MUST route each INVOKE-METHOD to exactly one backend, resolved per .
• MUST reject a request whose target cannot be resolved.

Layer 4: Resilience Interface: Pluggable components:

• Circuit breaker (state machine per , with configurable failure thresholds and reset timeouts)
• Retry policy (exponential backoff, jitter, max attempts)
• Timeout policy (per-request, per-backend)
• Message buffer ()
• Partial failure strategy ()

Requirements:

• SHOULD implement circuit breakers with per-backend state.
• SHOULD implement request timeouts.
• MUST NOT retry an INVOKE-METHOD that may have side effects unless the target is annotated idempotent.
• MAY retry LIST-METHODs and other read-only methods.
• MUST propagate breaker state to Layer 7, per .

Layer 5: Policy Layer 5 is an interceptor chain: each policy sees the message, and may pass, mutate, or reject it. MCP SEP-1763 describes the same shape for that protocol. Interface: Pluggable components:

• Authentication handler (OAuth 2.1, API key, mTLS, JWT validation)
• Authorization engine (RBAC, ABAC, CEL expressions, OPA policies)
• Token propagation strategy (passthrough, exchange , credential injection, per-upstream credentials)
• Content filter (DLP scanning, PII redaction, tool argument validation)
• Rate limiter (per-client, per-tool, per-backend)

Extension points for interceptors (per SEP-1763 pattern):

• pre-route: Before routing decision, on raw client request.
• post-route: After routing decision, before backend forward.
• pre-response: After backend response, before client delivery.
• post-response: After client delivery, for audit/logging.

Requirements:

• MUST support at least one authentication mechanism.
• SHOULD implement per-tool authorization when aggregating multiple backends.
• MUST NOT forward client credentials to backends unless explicitly configured to do so (credential injection is the RECOMMENDED default).
• MUST log policy decisions for audit purposes.

Layer 6: Session and State Interface: one or more backend sessions) and version mediation decisions. ]]> Pluggable components:

• Session strategy: - Passthrough: Forward session identifiers without modification (Relay mode only). - Multiplex: Map one client session to N backend sessions, encoding the mapping in a composite session token. - Isolate: Create independent backend sessions per client request (default for Forward mode). - Stateless: Operate without sessions; per-request capabilities carried in message metadata.
• Version mediator (negotiate protocol versions independently per backend, present a consistent version to the client)

Requirements:

• MUST support stateless operation per the 2026-07-28 MCP specification when backends support it.
• SHOULD support stateful operation for backwards compatibility with pre-2026-07-28 backends.
• MUST NOT leak backend session identifiers to clients.
• MUST isolate backend sessions from each other to prevent context mixing.

Layer 7: Capability Interface: Pluggable components:

• Capability compositor: - Union: Advertise all capabilities from all backends. - Intersection: Advertise only capabilities supported by all backends. - Curated: Advertise an explicitly configured subset.
• Tool count optimizer (progressive disclosure: expose a subset, provide a search tool for discovery of additional capabilities)
• Bidirectional message forwarder (configure which server-to- client message types are forwarded: sampling, elicitation, progress, logging)

Requirements:

• MUST advertise only capabilities the intermediary can route. This is the governing rule of the layer; the two that follow are its consequences.
• MUST withdraw capabilities of an unhealthy backend within a configurable window.
• SHOULD emit CHANGE-SIGNAL when the surface changes.
• SHOULD support selective forwarding of server-to-client message types.

Capability Negotiation Through Intermediaries

Single-Handshake vs Dual-Handshake For protocol versions that carry an initialization handshake, an intermediary either forwards the client's handshake to the backend (single-handshake passthrough) or performs its own handshake with each backend and composes the results (dual-handshake). The disposition is determined by mode:

Mode	Handshake
Relay	MUST NOT dual-handshake
Transparent, Level 1	MUST NOT dual-handshake
Transparent, Level 2	MAY dual-handshake
All other modes	MUST dual-handshake

In Relay mode and at Transparent Level 1, the client's initialization flows through to the backend unchanged. Injecting an additional handshake at these positions would be observable to a client that believes it is addressing the backend directly, which both dispositions are defined to prevent. At Transparent Level 2 the choice is per connection. An intermediary that dual-handshakes MUST satisfy the composition requirements of ; an intermediary that does not MUST satisfy the Level 1 requirements of for the duration of that connection. The intermediary MUST track which disposition is in effect per connection, because it determines whether namespace resolution () and capability composition apply. For stateless protocol versions that carry no handshake, this section does not apply; see . | | |--init-->| | | |--init-->| | |--init-->| b1 | |<--ok----| | |<--ok----| |<--ok----| | | |--init-->| b2 | | | | |<--ok----| |--ready->| | |<--ok----| | |--ready->| | (composed) | | | | | | I forwards; the capability I terminates the handshake and surface the client sees is advertises a surface it composed the backend's own itself; names are namespaced ]]>

Capability Composition When composing capabilities from multiple backends, the intermediary MUST:

1. Collect capability advertisements from all healthy backends.
2. Apply namespace prefixing () to avoid collisions.
3. Apply policy filters (Layer 5) to remove unauthorized capabilities.
4. Apply progressive disclosure limits (Layer 7) if configured.
5. Return the composed result to the client.

Stateless Capability Declaration For stateless protocol modes (MCP 2026-07-28 and later), the intermediary MUST include its own identity and capabilities in the _meta field of each response, enabling clients to distinguish intermediary-provided metadata from backend-provided metadata.

Namespace Management

Collision Problem When an intermediary aggregates backends that expose identically named tools, resources, or prompts, a collision occurs. The intermediary MUST resolve such collisions deterministically.

Resolution Strategies Intermediaries MUST implement at least one of the following strategies and MUST declare which strategy is in effect:

1. Prefix: Prepend a backend identifier to each capability name using a delimiter. The delimiter MUST be __ (double underscore) for tool names, as / and . are not accepted in LLM tool name parameters. MCP fixes this value in . The backend identifier MUST NOT contain the delimiter sequence, since reverse resolution splits on the first occurrence and an identifier carrying the delimiter would resolve ambiguously.

Example: Backend "github" tool "create_issue" becomes github__create_issue.

1. Priority: When collisions occur, retain the capability from the highest-priority backend and discard duplicates. The intermediary MUST log discarded capabilities.

1. Manual: Require explicit per-capability name overrides in configuration. The intermediary MUST reject startup if unresolved collisions exist.

1. Passthrough: Do not resolve collisions; forward the first match. This strategy is NOT RECOMMENDED for production deployments.

Reverse Resolution Prefixing on the way out and stripping on the way in are one mechanism seen from two directions. An intermediary MUST reverse the resolution on an INVOKE-METHOD, and MUST reject a name that does not resolve to exactly one backend. github__create_issue jira__create_issue INVOKE-METHOD (single target, prefix stripped) github__create_issue | +-- split on first NAME-DELIMITER | +-- "github" ---> routing table ---> backend | +-- "create_issue" -------------> sent as the original name Result returns unmodified. Results are not namespaced. ]]> The split takes the first occurrence of NAME-DELIMITER, which is why a backend identifier MUST NOT contain it ().

Authentication and Token Propagation

Token Propagation Patterns Intermediaries MUST implement at least one of the following token propagation patterns:

1. Credential Injection: The intermediary holds backend credentials and injects them into backend requests. The client never sees backend credentials. This is the RECOMMENDED default.

1. Token Passthrough: The intermediary forwards the client's token to the backend unchanged. This pattern is NOT RECOMMENDED due to confused deputy risks (see Security Considerations).

1. Token Exchange: The intermediary exchanges the client's token for a backend-specific token using RFC 8693 Token Exchange. This provides audit trails and scope restriction.

1. Per-Upstream Credentials: The intermediary maintains its own credential set per backend, refreshing tokens independently. If authentication fails for a backend, the intermediary SHOULD skip that backend and log a warning rather than failing the entire request.

Client Authentication Intermediaries operating in Forward or Reverse mode SHOULD implement OAuth 2.1 with PKCE for client authentication, consistent with the MCP Authorization specification.

Session Semantics

Stateful Protocol Versions For stateful protocol versions (MCP pre-2026-07-28), the intermediary MUST maintain a mapping between client sessions and backend sessions. The intermediary MUST NOT expose backend session identifiers to clients.

Stateless Protocol Versions For stateless protocol versions (MCP 2026-07-28 and later), the intermediary operates without session state. Per-request metadata (_meta) carries client identity and capabilities. The intermediary MUST forward _meta fields to backends and MAY augment them with intermediary-specific metadata.

Mixed-Version Deployments When an intermediary connects to backends running different protocol versions, it MUST:

• Negotiate the appropriate protocol version independently with each backend.
• Present a consistent protocol version to the client (RECOMMENDED: the highest version supported by all backends, or the highest version supported by the intermediary itself).
• Translate protocol-level differences transparently.

Resilience and Failure Handling

Circuit Breaker States Intermediaries implementing circuit breakers SHOULD follow the standard three-state model: OPEN ]]> A state change is not private to Layer 4. On entering OPEN the intermediary MUST withdraw that backend's capabilities from the advertised surface and emit CHANGE-SIGNAL; on returning to CLOSED it MUST restore them and emit CHANGE-SIGNAL again. An intermediary that breaks the circuit while continuing to advertise the backend's capabilities presents a surface it cannot serve, which forbids.

Partial Failure Semantics For fan-out operations (tools/list, resources/list):

• The intermediary SHOULD return partial results from healthy backends rather than failing the entire request.
• The intermediary MUST indicate which backends were unavailable in the response metadata.

For single-target operations (tools/call):

• The intermediary MUST return an error if the target backend is unavailable.
• The intermediary MUST NOT silently redirect to a different backend unless explicitly configured for failover.

Message Buffering During backend restarts or reconnections, intermediaries MAY buffer incoming messages and replay them upon recovery. The intermediary MUST:

• Bound the buffer size to prevent resource exhaustion.
• Discard buffered messages after a configurable timeout.
• Emit notifications/tools/list_changed after replay if the backend's capability surface changed during the restart.

Observability

Distributed Tracing Intermediaries MUST propagate W3C Trace Context fields (traceparent, tracestate) through the extension metadata of JSON-RPC messages. An intermediary MUST NOT alter a propagated value in place; where a value must be transformed, the intermediary carries the transformed value separately and leaves the original verbatim. If no trace context is present on an incoming request, the intermediary SHOULD generate a traceparent. In MCP this propagation is carried in _meta per the conventions of MCP SEP-414 .

Hop Tracing Intermediaries SHOULD record hop metadata in METADATA-FIELD under HOP-KEY, so that clients and operators can trace the path a request took. This serves the purpose for agent-tool protocols that the Forwarded header serves for HTTP. Each entry SHOULD carry the intermediary's name, its mode (), its version, and a timestamp. An intermediary MUST append; the order of the sequence is the path. | | | | |--------------->| | | | |-------------->| | | HOP-KEY = [ ] [ gateway ] [ gateway, ] [ team-proxy ] An intermediary that overwrote instead of appending would erase every hop upstream of itself. ]]> gives HOP-KEY for two protocols.

Metrics Intermediaries SHOULD expose the following metrics per backend, per tool, and per client:

• Request count (total, success, failure)
• Latency (p50, p95, p99)
• Circuit breaker state transitions
• Cache hit/miss ratio (for capability list caching)
• Active connection count

Security Considerations

Confused Deputy An intermediary that forwards client tokens to backends without audience validation may act as a confused deputy, granting the client access to resources it is not authorized for. Intermediaries MUST validate token audiences before forwarding. Credential Injection (, pattern 1) avoids this class of attack entirely.

Tool Poisoning A compromised backend may return malicious tool schemas designed to manipulate LLM behavior. Intermediaries SHOULD validate tool definitions against a schema allowlist before exposing them to clients.

Capability Surface Expansion Aggregating multiple backends increases the attack surface proportionally. Intermediaries MUST apply least-privilege principles: only expose capabilities that are explicitly authorized for the requesting client.

Namespace Squatting In prefix-based namespace resolution, a malicious backend could register tool names designed to shadow tools from other backends. Intermediaries MUST ensure that backend identifiers used as prefixes are assigned by the intermediary operator, not self-declared by backends.

Session Fixation Intermediaries that maintain session mappings MUST generate their own session identifiers for client-facing sessions and MUST NOT reuse backend session identifiers.

IANA Considerations This document has no IANA actions. [Note to RFC Editor: This section may be updated if the document defines any registries or media types.]

Normative References Informative References Anthropic W3C Sambhav

Mode Selection Guide

Relationship to the MCP SEP This Internet-Draft defines the protocol-agnostic architecture and taxonomy. A companion MCP SEP, "Proxy and Gateway Behavioral Specification for MCP", carries the MCP binding. The two documents are normatively independent in one direction only. The SEP is self-contained: it restates every requirement it imposes and does not rely on this document for the force of any requirement, so an implementer can conform to it without reading this draft. This document, in turn, imposes nothing on MCP (). The relationship is that the SEP is one binding of the model described here, and this appendix is informative. The SEP provides MCP-specific normative requirements, including:

• MCP-specific namespace delimiter conventions
• _meta field schemas for hop tracing
• Capability composition rules for MCP primitives (tools, resources, prompts, sampling, elicitation)
• Integration with MCP authorization specification
• Conformance test requirements per SEP-2484

---

Implementation Status This section records the status of known implementations of the protocol defined by this specification, per . Its purpose is to record the experience of implementers and to inform the working group's judgment of running code. It is not a catalog of features, and inclusion is neither an endorsement nor a statement of production readiness. This section is to be removed before publication as an RFC.

yamp

• Organization: independent
• Name and URL: yamp (Yet Another MCP Proxy)
• Description: A forward and transparent proxy for the Model Context Protocol, implemented twice from this specification, once in Rust and once in Python. The two arms are pinned to identical behavior by a shared golden corpus rather than by inspection: a differential corpus fixes the output of every pure function, a golden-flow corpus fixes the exact client-facing message sequence of whole exchanges, and a clause-to-test traceability matrix maps normative statements to the tests that evidence them in both arms.
• Level of maturity: research and reference implementation, not a production deployment.
• Coverage: The modes of are covered as follows. Relay, Forward, and Transparent (Level 1 and Level 2) are implemented. Reverse is partial, providing backend pools with connect-time failover but neither request-level load balancing nor session replication. Federation is partial, in that proxies chain, with no federation discovery mechanism. Conversion is partial, covering REST to MCP with no gRPC and no full OpenAPI import. Sidecar is not implemented. Of the layers in , transport, routing, resilience, and capability are implemented; discovery, policy, and session are partial.
• Conformance tier: Tier 3 (), with the layer gaps noted above.
• Interception: the transparent modes take an integration-provided backend selection and do not perform their own interception, as permitted by .
• Version compatibility: implements this draft, revision 00.
• Licensing: Apache License 2.0.
• Implementation experience: Implementing the specification twice surfaced two defects in the specification itself, both now corrected. A backend identifier must not contain the namespace delimiter, because reverse resolution splits on the first delimiter (). Original-destination recovery for the transparent modes (SO_ORIGINAL_DST) proved to be a platform-specific hook rather than a protocol concern, and was rewritten to separate interception as a deployment concern from the transparent-mode protocol behavior. A third question is recorded as unresolved rather than fixed. The conformance model of is expressed per tier and per mode, but implementation coverage did not fall on those boundaries: Reverse mode was implemented with backend pools and connect-time failover but without session replication, and the model provides no way to declare that precisely. An intermediary must either overclaim Reverse or omit working functionality. Sub-mode capability declaration is a candidate for a future revision.
• Contact: Madhava Gaikwad, gaikwad.madhav@gmail.com

---

Example Bindings Informative. This appendix instantiates the seven parameters of for two protocols, to show that the requirements of this document are separable from any one of them. Neither entry is a binding; a binding is produced by the protocol's own process. The MCP column reflects the companion SEP of . The A2A column is the author's reading of a protocol this document has not been implemented against, and is offered to locate the seams, not as a specification. Three seams are visible in the second column, and they are the useful output of the exercise. CHANGE-SIGNAL may not exist. A protocol whose capability surface is discovered by fetching a document, rather than announced by a notification, gives an intermediary no push signal. 's SHOULD is then satisfiable only by re-publishing the document. 's MUST, which requires emitting CHANGE-SIGNAL on breaker transitions, is not satisfiable at all. A binding for such a protocol MUST state what replaces it, and the likely answer is a bounded staleness window. Namespacing may be unnecessary. Where capability identifiers are already globally scoped, collisions cannot occur and has nothing to resolve. NAME-DELIMITER is then unused. The requirement to implement a collision strategy should be read as conditional on the binding declaring that collisions are possible. The unit of invocation may not be a call. A protocol whose invocation is a long-running task with its own lifecycle does not map cleanly onto the single request/response assumed by Sections 6.3 and 11.2. Partial-failure semantics for fan-out are defined here in terms of responses that arrive or fail; a task that is accepted and later abandoned is neither. A revision of this document should either resolve these three cases in the body or state that its scope is protocols with push change notification, scoped-per-backend names, and request/response invocation. The second is the honest reading of the current text.

Surveyed Implementations Informative. These are the twelve implementations referred to in , surveyed in Q1 2026 from public documentation and source. The mode column records which mode of each best illustrates, as assessed by the author from published behavior at that date. It is not a conformance statement, and none of these implementations claims conformance to this document. Two observations follow from the table and support . No surveyed implementation covered more than two of the seven modes, and none declared which mode it implemented. The vocabulary for such a declaration did not exist. Sidecar mode is absent. The author identified no implementation that binds an intermediary to a single co-located backend and mediates all of its traffic, which is why cites a proposal rather than a shipping implementation.