| Internet-Draft | Agent-Tool Proxy Modes | August 2026 |
| Gaikwad | Expires 14 February 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 14 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Agent-tool protocols define how AI clients discover and invoke capabilities exposed by servers. The Model Context Protocol [MCP] 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 (Appendix C); 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.¶
This document defines:¶
This document does not define:¶
This document references and builds upon:¶
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 (Appendix B).¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
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.¶
+---+------------------------+------------------------------+ | # | Parameter | What the binding fixes | +===+========================+==============================+ | 1 | METADATA-FIELD | Where per-message extension | | | | metadata is carried | +---+------------------------+------------------------------+ | 2 | HOP-KEY | Key under which the hop | | | | sequence is stored | +---+------------------------+------------------------------+ | 3 | NAME-DELIMITER | Separator for namespaced | | | | capability names | +---+------------------------+------------------------------+ | 4 | NAME-CHARSET | Characters legal in a | | | | capability name | +---+------------------------+------------------------------+ | 5 | LIST-METHODS | Methods that enumerate the | | | | capability surface | +---+------------------------+------------------------------+ | 6 | INVOKE-METHODS | Methods that target exactly | | | | one backend | +---+------------------------+------------------------------+ | 7 | CHANGE-SIGNAL | Notification that the | | | | capability surface changed | +---+------------------------+------------------------------+¶
A binding MUST additionally state whether the protocol carries an initialization handshake, which selects between the dispositions of Section 7.1.¶
Appendix D gives these values for two protocols.¶
This document defines seven proxy modes. Modes are not mutually exclusive; a single intermediary MAY implement multiple modes simultaneously.¶
Modes are classified along three axes:¶
+===============+============+=============+=============+ | Mode | Protocol | Deployment | Client | | | Awareness | Position | Visibility | +===============+============+=============+=============+ | Relay | None | Client-side | Explicit | +---------------+------------+-------------+-------------+ | Forward | Full | Client-side | Explicit | +---------------+------------+-------------+-------------+ | Reverse | Full | Server-side | Transparent | +---------------+------------+-------------+-------------+ | Transparent | Level 1: | Network- | Transparent | | | Transport | side | | | | Level 2: | | | | | Full | | | +---------------+------------+-------------+-------------+ | Sidecar | Full | Server-side | Transparent | +---------------+------------+-------------+-------------+ | Federation | Full | Any | Explicit | +---------------+------------+-------------+-------------+ | Conversion | Full | Server-side | Transparent | +---------------+------------+-------------+-------------+¶
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.¶
Relay, Forward client ==> 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.¶
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. Section 4.2 names the conformance classes that group these layers.¶
+----------------------------------------------------------+ | Layer 7: Capability negotiation, composition, | | progressive disclosure | +----------------------------------------------------------+ | Layer 6: Session/State multiplex, isolate, stateless | | passthrough, version mediation | +----------------------------------------------------------+ | Layer 5: Policy auth, RBAC, filtering, DLP, | | rate limiting (interceptors) | +----------------------------------------------------------+ | Layer 4: Resilience circuit breakers, retries, | | timeouts, partial failure | +----------------------------------------------------------+ | Layer 3: Routing namespace resolution, | | capability mapping, fan-out | +----------------------------------------------------------+ | Layer 2: Discovery backend registration, health | | checks, hot reload, topology | +----------------------------------------------------------+ | Layer 1: Transport wire protocol adaptation, | | serialization/deserialization | +----------------------------------------------------------+ Cross-cutting: Observability (tracing, metrics, audit) Cross-cutting: Configuration (portable schema)¶
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:¶
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 (Section 3).¶
A tier names layer coverage only. The mode taxonomy of Section 3 is a separate axis, declared independently, and the awareness levels of Section 5.4.1 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.¶
A client-to-server message traverses the stack upward, 1 through¶
sampling or elicitation, traverses it downward, 7 through 1. The stack is therefore symmetric, and a layer sees both directions.¶
client-to-server server-to-client
L7 Capability <--+
^ |
L6 Session |
^ v
L5 Policy <-------> 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.¶
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:¶
Applicable layers: Layer 1 only.¶
Illustrated by: sparfenyuk/mcp-proxy, Supergateway (Appendix E).¶
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:¶
Applicable layers: Layers 1-3 (minimum), all layers (maximum).¶
Illustrated by: FastMCP proxy, MCProxy, plugged.in, MCPJungle (Appendix E).¶
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:¶
Applicable layers: Layers 1-3 (minimum), all layers (maximum).¶
Illustrated by: Microsoft mcp-gateway, agentgateway (Appendix E).¶
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.¶
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.¶
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.¶
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.¶
Applicable layers: Layer 1 (Transport), Layer 5 (Policy - header-based filtering only).¶
Applicable layers: Layers 1-5 (typical), optionally Layers 6-7.¶
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.¶
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:¶
The RECOMMENDED token propagation pattern for Transparent mode is Passthrough (Section 9.1, 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 Appendix C.¶
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:¶
Applicable layers: Layers 1, 4, 5 (typical).¶
Illustrated by: no shipping implementation was identified in the survey; the interceptor model of [MCP-SEP-1763] is the nearest proposal.¶
A Federation intermediary aggregates other intermediaries (not direct backend servers) into a hierarchical topology. This enables multi-level organizational structures.¶
Requirements:¶
Applicable layers: All layers.¶
Illustrated by: no complete implementation was identified in the survey. MetaMCP provided partial support, one endpoint per namespace (Appendix E).¶
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:¶
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).¶
Interface:¶
Input: Raw bytes or transport-specific frames from the
upstream (client-facing) connection.
Output: Raw bytes or transport-specific frames to the
downstream (backend-facing) connection.
¶
Pluggable components:¶
Requirements:¶
Interface:¶
Input: Backend configuration (static, service discovery, or
self-registration).
Output: A registry of available backends with their health
status, capabilities, and connection parameters.
¶
Pluggable components:¶
ping, MCP-native capability polling)¶
Requirements:¶
Interface:¶
Input: A deserialized JSON-RPC message (method name, params). Output: One or more (backend, transformed_message) pairs.¶
Pluggable components:¶
Requirements:¶
Interface:¶
Input: A routed request (from Layer 3) and backend health
status (from Layer 2).
Output: A request to forward, a cached/buffered response,
or an error to return to the client.
¶
Pluggable components:¶
Requirements:¶
Layer 5 is an interceptor chain: each policy sees the message, and may pass, mutate, or reject it. MCP SEP-1763 [MCP-SEP-1763] describes the same shape for that protocol.¶
Interface:¶
Input: A request or response message, authentication context,
and policy configuration.
Output: The message (unmodified, mutated, or rejected) plus
an audit record.
¶
Pluggable components:¶
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:¶
Interface:¶
Input: Client session context and backend session contexts.
Output: Session mapping (client session -> one or more
backend sessions) and version mediation decisions.
¶
Pluggable components:¶
Requirements:¶
Interface:¶
Input: Capability advertisements from all healthy backends,
circuit breaker states, and policy filter results.
Output: A composed capability surface to advertise to clients.
¶
Pluggable components:¶
Requirements:¶
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 Section 7.2; an intermediary that does not MUST satisfy the Level 1 requirements of Section 5.4.3 for the duration of that connection. The intermediary MUST track which disposition is in effect per connection, because it determines whether namespace resolution (Section 8) and capability composition apply.¶
For stateless protocol versions that carry no handshake, this section does not apply; see Section 7.3.¶
Single-handshake passthrough Dual-handshake client I backend client I backend | | | | | | |--init-->| | |--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¶
When composing capabilities from multiple backends, the intermediary MUST:¶
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.¶
When an intermediary aggregates backends that expose identically named tools, resources, or prompts, a collision occurs. The intermediary MUST resolve such collisions deterministically.¶
Intermediaries MUST implement at least one of the following strategies and MUST declare which strategy is in effect:¶
__ (double underscore) for tool names, as / and . are not accepted in LLM tool name parameters. MCP fixes this value in [MCP-SEP-993]. 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.¶
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.¶
LIST-METHOD (fan-out, prefix applied)
backend "github" create_issue --+
backend "jira" create_issue --+--> 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 (Section 8.2).¶
Intermediaries MUST implement at least one of the following token propagation patterns:¶
Intermediaries operating in Forward or Reverse mode SHOULD implement OAuth 2.1 with PKCE for client authentication, consistent with the MCP Authorization specification.¶
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.¶
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.¶
When an intermediary connects to backends running different protocol versions, it MUST:¶
Intermediaries implementing circuit breakers SHOULD follow the standard three-state model:¶
failures exceed threshold
+-------------------------------------------+
| v
+----------+ +----------+
| CLOSED | | OPEN |
| forward | | reject |
+----------+ +----------+
^ |
| |
| trial succeeds | reset
| | timeout
| +-------------+ |
+------------| HALF-OPEN |<---------------+
| one trial |
+-------------+
|
+--- trial fails ---> 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 Section 6.7 forbids.¶
For fan-out operations (tools/list, resources/list):¶
For single-target operations (tools/call):¶
During backend restarts or reconnections, intermediaries MAY buffer incoming messages and replay them upon recovery. The intermediary MUST:¶
Intermediaries MUST propagate W3C Trace Context [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 [MCP-SEP-414].¶
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 [RFC7239] serves for HTTP.¶
Each entry SHOULD carry the intermediary's name, its mode (Section 3), its version, and a timestamp. An intermediary MUST append; the order of the sequence is the path.¶
client gateway team-proxy backend
| | | |
|------------->| | |
| |--------------->| |
| | |-------------->|
| |
HOP-KEY = [ ] [ gateway ] [ gateway, ]
[ team-proxy ]
An intermediary that overwrote instead of appending would
erase every hop upstream of itself.
¶
Appendix D gives HOP-KEY for two protocols.¶
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 (Section 9.1, pattern 1) avoids this class of attack entirely.¶
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.¶
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.¶
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.¶
Intermediaries that maintain session mappings MUST generate their own session identifiers for client-facing sessions and MUST NOT reuse backend session identifiers.¶
This document has no IANA actions.¶
[Note to RFC Editor: This section may be updated if the document defines any registries or media types.]¶
+===============================+====================+ | Deployment Scenario | Recommended Mode | +===============================+====================+ | Bridge stdio to HTTP for a | Relay | | single backend | | +-------------------------------+--------------------+ | Aggregate 3-5 backends for | Forward | | a development team | | +-------------------------------+--------------------+ | Production server behind a | Reverse | | load balancer | | +-------------------------------+--------------------+ | Audit/log all MCP traffic | Transparent | | without touching clients or | (Level 1) | | servers | | +-------------------------------+--------------------+ | Network-level tool filtering | Transparent | | and DLP for MCP traffic | (Level 2) | +-------------------------------+--------------------+ | Enterprise-wide tool | Forward + | | governance with multiple | Federation | | teams | | +-------------------------------+--------------------+ | Per-server security policy | Sidecar | | without modifying server code | | +-------------------------------+--------------------+ | Exposing REST APIs as | Conversion | | agent-tool capabilities | | +-------------------------------+--------------------+¶
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 (Section 1.4). 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:¶
_meta field schemas for hop tracing¶
---¶
This section records the status of known implementations of the protocol defined by this specification, per [RFC7942]. 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.¶
SO_ORIGINAL_DST) proved to be a platform-specific hook rather than a protocol concern, and Section 5.4.2 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 Section 4.2 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.¶
---¶
Informative. This appendix instantiates the seven parameters of Section 2.2 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 Appendix B. 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.¶
+------------------+---------------------+---------------------+ | Parameter | MCP | A2A | +==================+=====================+=====================+ | METADATA-FIELD | _meta | message metadata | +------------------+---------------------+---------------------+ | HOP-KEY | io.modelcontext | binding-defined | | | protocol/proxy-hops | | +------------------+---------------------+---------------------+ | NAME-DELIMITER | __ | binding-defined; | | | | skill ids are URI- | | | | shaped, so a URI- | | | | safe separator fits | +------------------+---------------------+---------------------+ | NAME-CHARSET | [a-zA-Z0-9_-] | wider; see below | +------------------+---------------------+---------------------+ | LIST-METHODS | tools/list | agent card fetch | | | resources/list | | | | prompts/list | | +------------------+---------------------+---------------------+ | INVOKE-METHODS | tools/call | task submission | | | resources/read | | | | prompts/get | | +------------------+---------------------+---------------------+ | CHANGE-SIGNAL | notifications/ | agent card re-fetch | | | tools/list_changed | (poll, not push) | +------------------+---------------------+---------------------+ | Handshake? | yes before | no | | | 2026-07-28; no | | | | after | | +------------------+---------------------+---------------------+¶
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. Section 6.7's SHOULD is then satisfiable only by re-publishing the document. Section 11.1'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 Section 8 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.¶
Informative. These are the twelve implementations referred to in Section 1.1, surveyed in Q1 2026 from public documentation and source. The mode column records which mode of Section 5 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.¶
+----+----------------------+--------------------------------+ | | Implementation | Mode illustrated | +====+======================+================================+ | 1 | sparfenyuk/mcp-proxy | Relay | +----+----------------------+--------------------------------+ | 2 | Supergateway | Relay | +----+----------------------+--------------------------------+ | 3 | FastMCP proxy | Forward | +----+----------------------+--------------------------------+ | 4 | MCProxy | Forward | +----+----------------------+--------------------------------+ | 5 | plugged.in | Forward | +----+----------------------+--------------------------------+ | 6 | MCPJungle | Forward | +----+----------------------+--------------------------------+ | 7 | Microsoft | Reverse | | | mcp-gateway | | +----+----------------------+--------------------------------+ | 8 | agentgateway (AAIF) | Reverse; also Conversion | +----+----------------------+--------------------------------+ | 9 | Kong ai-mcp-proxy | Conversion | +----+----------------------+--------------------------------+ | 10 | Unla | Conversion | +----+----------------------+--------------------------------+ | 11 | MetaMCP | Federation, partial | +----+----------------------+--------------------------------+ | 12 | Stacklok ToolHive | surveyed; not attributed to | | | | a single mode | +----+----------------------+--------------------------------+¶
Two observations follow from the table and support Section 1.1.¶
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 Section 5.5 cites a proposal rather than a shipping implementation.¶