Proxy Modes for Agent-Tool Protocols
draft-gaikwad-agent-proxy-modes-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Madhava Gaikwad | ||
| Last updated | 2026-08-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gaikwad-agent-proxy-modes-00
Independent Submission M. Gaikwad
Internet-Draft Independent
Intended status: Standards Track 13 August 2026
Expires: 14 February 2027
Proxy Modes for Agent-Tool Protocols
draft-gaikwad-agent-proxy-modes-00
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gaikwad Expires 14 February 2027 [Page 1]
Internet-Draft Agent-Tool Proxy Modes August 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Relationship to Other Specifications . . . . . . . . . . 5
1.4. Relationship to Agent-Tool Protocol Governance . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Binding-Defined Parameters . . . . . . . . . . . . . . . 6
3. Proxy Mode Taxonomy . . . . . . . . . . . . . . . . . . . . . 7
3.1. Mode Classification Axes . . . . . . . . . . . . . . . . 7
3.2. Mode Summary . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Mode Topologies . . . . . . . . . . . . . . . . . . . . . 8
4. Layered Proxy Architecture . . . . . . . . . . . . . . . . . 9
4.1. Layer Stack . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Layer Independence and Conformance Tiers . . . . . . . . 10
4.3. Layer Invocation Order . . . . . . . . . . . . . . . . . 11
5. Mode Definitions . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Relay Mode . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Forward Proxy Mode . . . . . . . . . . . . . . . . . . . 13
5.3. Reverse Proxy Mode . . . . . . . . . . . . . . . . . . . 13
5.4. Transparent Mode . . . . . . . . . . . . . . . . . . . . 14
5.4.1. Awareness Levels . . . . . . . . . . . . . . . . . . 14
5.4.2. General Requirements . . . . . . . . . . . . . . . . 15
5.4.3. Level 1 Requirements . . . . . . . . . . . . . . . . 15
5.4.4. Level 2 Requirements . . . . . . . . . . . . . . . . 16
5.4.5. TLS Considerations . . . . . . . . . . . . . . . . . 16
5.4.6. Authentication Constraints . . . . . . . . . . . . . 17
5.5. Sidecar Mode . . . . . . . . . . . . . . . . . . . . . . 18
5.6. Federation Mode . . . . . . . . . . . . . . . . . . . . . 18
5.7. Conversion Mode . . . . . . . . . . . . . . . . . . . . . 19
6. Layer Interface Specifications . . . . . . . . . . . . . . . 19
6.1. Layer 1: Transport . . . . . . . . . . . . . . . . . . . 19
6.2. Layer 2: Discovery . . . . . . . . . . . . . . . . . . . 20
6.3. Layer 3: Routing . . . . . . . . . . . . . . . . . . . . 20
6.4. Layer 4: Resilience . . . . . . . . . . . . . . . . . . . 21
6.5. Layer 5: Policy . . . . . . . . . . . . . . . . . . . . . 22
6.6. Layer 6: Session and State . . . . . . . . . . . . . . . 23
Gaikwad Expires 14 February 2027 [Page 2]
Internet-Draft Agent-Tool Proxy Modes August 2026
6.7. Layer 7: Capability . . . . . . . . . . . . . . . . . . . 23
7. Capability Negotiation Through Intermediaries . . . . . . . . 24
7.1. Single-Handshake vs Dual-Handshake . . . . . . . . . . . 24
7.2. Capability Composition . . . . . . . . . . . . . . . . . 26
7.3. Stateless Capability Declaration . . . . . . . . . . . . 26
8. Namespace Management . . . . . . . . . . . . . . . . . . . . 26
8.1. Collision Problem . . . . . . . . . . . . . . . . . . . . 26
8.2. Resolution Strategies . . . . . . . . . . . . . . . . . . 26
8.3. Reverse Resolution . . . . . . . . . . . . . . . . . . . 27
9. Authentication and Token Propagation . . . . . . . . . . . . 27
9.1. Token Propagation Patterns . . . . . . . . . . . . . . . 27
9.2. Client Authentication . . . . . . . . . . . . . . . . . . 28
10. Session Semantics . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Stateful Protocol Versions . . . . . . . . . . . . . . . 28
10.2. Stateless Protocol Versions . . . . . . . . . . . . . . 28
10.3. Mixed-Version Deployments . . . . . . . . . . . . . . . 28
11. Resilience and Failure Handling . . . . . . . . . . . . . . . 29
11.1. Circuit Breaker States . . . . . . . . . . . . . . . . . 29
11.2. Partial Failure Semantics . . . . . . . . . . . . . . . 29
11.3. Message Buffering . . . . . . . . . . . . . . . . . . . 30
12. Observability . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Distributed Tracing . . . . . . . . . . . . . . . . . . 30
12.2. Hop Tracing . . . . . . . . . . . . . . . . . . . . . . 30
12.3. Metrics . . . . . . . . . . . . . . . . . . . . . . . . 31
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
13.1. Confused Deputy . . . . . . . . . . . . . . . . . . . . 31
13.2. Tool Poisoning . . . . . . . . . . . . . . . . . . . . . 31
13.3. Capability Surface Expansion . . . . . . . . . . . . . . 32
13.4. Namespace Squatting . . . . . . . . . . . . . . . . . . 32
13.5. Session Fixation . . . . . . . . . . . . . . . . . . . . 32
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
15. Normative References . . . . . . . . . . . . . . . . . . . . 32
16. Informative References . . . . . . . . . . . . . . . . . . . 33
Appendix A. Mode Selection Guide . . . . . . . . . . . . . . . . 33
Appendix B. Relationship to the MCP SEP . . . . . . . . . . . . 34
Appendix C. Implementation Status . . . . . . . . . . . . . . . 35
C.1. yamp . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix D. Example Bindings . . . . . . . . . . . . . . . . . . 37
Appendix E. Surveyed Implementations . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction
Gaikwad Expires 14 February 2027 [Page 3]
Internet-Draft Agent-Tool Proxy Modes August 2026
1.1. Problem Statement
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.
1.2. 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
Gaikwad Expires 14 February 2027 [Page 4]
Internet-Draft Agent-Tool Proxy Modes August 2026
This document does not define:
* The agent-tool protocol itself (see [MCP])
* Transport-layer specifications, which are defined by each agent-
tool protocol
* Specific authentication protocols (see [RFC9207])
1.3. Relationship to Other Specifications
This document references and builds upon:
* Model Context Protocol [MCP] for protocol-specific semantics
* [RFC9110] for HTTP proxy terminology
* [RFC8693] for token propagation patterns
* [RFC9207] for authorization server identification
* [RFC7239] for proxy hop tracing precedent
* W3C Trace Context [TRACE-CONTEXT] for distributed tracing
1.4. 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 (Appendix B).
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Gaikwad Expires 14 February 2027 [Page 5]
Internet-Draft Agent-Tool Proxy Modes August 2026
2.1. 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.
2.2. 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.
Gaikwad Expires 14 February 2027 [Page 6]
Internet-Draft Agent-Tool Proxy Modes August 2026
+---+------------------------+------------------------------+
| # | 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.
3. Proxy Mode Taxonomy
This document defines seven proxy modes. Modes are not mutually
exclusive; a single intermediary MAY implement multiple modes
simultaneously.
3.1. 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).
Gaikwad Expires 14 February 2027 [Page 7]
Internet-Draft Agent-Tool Proxy Modes August 2026
1. *Client visibility:* Whether the client is configured to address
the intermediary explicitly or is unaware of its presence.
3.2. Mode Summary
+===============+============+=============+=============+
| 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 |
+---------------+------------+-------------+-------------+
3.3. 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.
Gaikwad Expires 14 February 2027 [Page 8]
Internet-Draft Agent-Tool Proxy Modes August 2026
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.
4. 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. Section 4.2 names the conformance classes
that group these layers.
4.1. Layer Stack
Gaikwad Expires 14 February 2027 [Page 9]
Internet-Draft Agent-Tool Proxy Modes August 2026
+----------------------------------------------------------+
| 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)
4.2. 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:
Gaikwad Expires 14 February 2027 [Page 10]
Internet-Draft Agent-Tool Proxy Modes August 2026
+========+============+
| Tier | Layers |
+========+============+
| Tier 1 | Layer 1 |
+--------+------------+
| Tier 2 | Layers 1-3 |
+--------+------------+
| Tier 3 | Layers 1-7 |
+--------+------------+
Table 1
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.
4.3. 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.
Gaikwad Expires 14 February 2027 [Page 11]
Internet-Draft Agent-Tool Proxy Modes August 2026
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.
5. Mode Definitions
5.1. 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).
Gaikwad Expires 14 February 2027 [Page 12]
Internet-Draft Agent-Tool Proxy Modes August 2026
5.2. 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 Section 8).
* 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 Section 6.7,
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).
5.3. 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.
Gaikwad Expires 14 February 2027 [Page 13]
Internet-Draft Agent-Tool Proxy Modes August 2026
* 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).
5.4. 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.
5.4.1. 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.
Gaikwad Expires 14 February 2027 [Page 14]
Internet-Draft Agent-Tool Proxy Modes August 2026
5.4.2. 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.
5.4.3. 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 [MCP-SEP-2243].
Gaikwad Expires 14 February 2027 [Page 15]
Internet-Draft Agent-Tool Proxy Modes August 2026
* 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).
5.4.4. 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 (Section 8) 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.
5.4.5. 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:
Gaikwad Expires 14 February 2027 [Page 16]
Internet-Draft Agent-Tool Proxy Modes August 2026
*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.
5.4.6. 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 (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.
Gaikwad Expires 14 February 2027 [Page 17]
Internet-Draft Agent-Tool Proxy Modes August 2026
5.5. 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 [MCP-SEP-1763] is the nearest
proposal.
5.6. 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 Section 12.2) 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.
Gaikwad Expires 14 February 2027 [Page 18]
Internet-Draft Agent-Tool Proxy Modes August 2026
Applicable layers: All layers.
Illustrated by: no complete implementation was identified in the
survey. MetaMCP provided partial support, one endpoint per namespace
(Appendix E).
5.7. 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).
6. Layer Interface Specifications
6.1. Layer 1: Transport
*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:*
* Transport adapter (stdio <-> SSE <-> Streamable HTTP <->
WebSocket)
* TLS termination/origination
Gaikwad Expires 14 February 2027 [Page 19]
Internet-Draft Agent-Tool Proxy Modes August 2026
* 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.
6.2. Layer 2: Discovery
*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:*
* 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).
6.3. Layer 3: Routing
*Interface:*
Input: A deserialized JSON-RPC message (method name, params).
Output: One or more (backend, transformed_message) pairs.
Gaikwad Expires 14 February 2027 [Page 20]
Internet-Draft Agent-Tool Proxy Modes August 2026
*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
Section 8.3.
* MUST reject a request whose target cannot be resolved.
6.4. Layer 4: Resilience
*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:*
* Circuit breaker (state machine per Section 11.1, with configurable
failure thresholds and reset timeouts)
* Retry policy (exponential backoff, jitter, max attempts)
* Timeout policy (per-request, per-backend)
* Message buffer (Section 11.3)
* Partial failure strategy (Section 11.2)
*Requirements:*
* SHOULD implement circuit breakers with per-backend state.
* SHOULD implement request timeouts.
Gaikwad Expires 14 February 2027 [Page 21]
Internet-Draft Agent-Tool Proxy Modes August 2026
* 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 Section 11.1.
6.5. Layer 5: Policy
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:*
* Authentication handler (OAuth 2.1, API key, mTLS, JWT validation)
* Authorization engine (RBAC, ABAC, CEL expressions, OPA policies)
* Token propagation strategy (passthrough, exchange [RFC8693],
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.
Gaikwad Expires 14 February 2027 [Page 22]
Internet-Draft Agent-Tool Proxy Modes August 2026
* 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.
6.6. Layer 6: Session and State
*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:*
* 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.
6.7. Layer 7: Capability
*Interface:*
Gaikwad Expires 14 February 2027 [Page 23]
Internet-Draft Agent-Tool Proxy Modes August 2026
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:*
* 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.
7. Capability Negotiation Through Intermediaries
7.1. 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:
Gaikwad Expires 14 February 2027 [Page 24]
Internet-Draft Agent-Tool Proxy Modes August 2026
+======================+=========================+
| 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 |
+----------------------+-------------------------+
Table 2
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
Gaikwad Expires 14 February 2027 [Page 25]
Internet-Draft Agent-Tool Proxy Modes August 2026
7.2. Capability Composition
When composing capabilities from multiple backends, the intermediary
MUST:
1. Collect capability advertisements from all healthy backends.
2. Apply namespace prefixing (Section 8) 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.
7.3. 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.
8. Namespace Management
8.1. 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.
8.2. 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 [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.
Gaikwad Expires 14 February 2027 [Page 26]
Internet-Draft Agent-Tool Proxy Modes August 2026
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.
8.3. 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.
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).
9. Authentication and Token Propagation
9.1. Token Propagation Patterns
Intermediaries MUST implement at least one of the following token
propagation patterns:
Gaikwad Expires 14 February 2027 [Page 27]
Internet-Draft Agent-Tool Proxy Modes August 2026
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.
9.2. 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.
10. Session Semantics
10.1. 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.
10.2. 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.
10.3. Mixed-Version Deployments
When an intermediary connects to backends running different protocol
versions, it MUST:
* Negotiate the appropriate protocol version independently with each
backend.
Gaikwad Expires 14 February 2027 [Page 28]
Internet-Draft Agent-Tool Proxy Modes August 2026
* 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.
11. Resilience and Failure Handling
11.1. Circuit Breaker States
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.
11.2. 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.
Gaikwad Expires 14 February 2027 [Page 29]
Internet-Draft Agent-Tool Proxy Modes August 2026
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.
11.3. 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.
12. Observability
12.1. Distributed Tracing
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].
12.2. 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 [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.
Gaikwad Expires 14 February 2027 [Page 30]
Internet-Draft Agent-Tool Proxy Modes August 2026
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.
12.3. 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
13. Security Considerations
13.1. 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
(Section 9.1, pattern 1) avoids this class of attack entirely.
13.2. 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.
Gaikwad Expires 14 February 2027 [Page 31]
Internet-Draft Agent-Tool Proxy Modes August 2026
13.3. 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.
13.4. 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.
13.5. Session Fixation
Intermediaries that maintain session mappings MUST generate their own
session identifiers for client-facing sessions and MUST NOT reuse
backend session identifiers.
14. 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.]
15. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, BCP 14, 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9110] Fielding, R., "HTTP Semantics", RFC 9110, 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC8693] Jones, M., "OAuth 2.0 Token Exchange", RFC 8693, 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9207] Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0
Authorization Server Issuer Identification", RFC 9207,
2022, <https://www.rfc-editor.org/rfc/rfc9207>.
Gaikwad Expires 14 February 2027 [Page 32]
Internet-Draft Agent-Tool Proxy Modes August 2026
16. Informative References
[MCP] Anthropic, "Model Context Protocol Specification", 2026,
<https://modelcontextprotocol.io/specification/>.
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, 2014, <https://www.rfc-editor.org/rfc/rfc7239>.
[TRACE-CONTEXT]
W3C, "Trace Context", 2021,
<https://www.w3.org/TR/trace-context/>.
[MCP-SEP-993]
White, P., "Namespaces", 2025.
[MCP-SEP-1763]
Sambhav, "Interceptors for Model Context Protocol", 2025.
[MCP-SEP-2243]
Kistler, M., "HTTP Standardization", 2026.
[MCP-SEP-414]
"W3C Trace Context propagation in _meta", 2025.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 7942,
BCP 205, 2016, <https://www.rfc-editor.org/rfc/rfc7942>.
[YAMP] Gaikwad, M., "yamp: a forward and transparent MCP proxy",
2026, <https://github.com/mcpx-project>.
Appendix A. Mode Selection Guide
Gaikwad Expires 14 February 2027 [Page 33]
Internet-Draft Agent-Tool Proxy Modes August 2026
+===============================+====================+
| 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 | |
+-------------------------------+--------------------+
Appendix B. 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 (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:
* MCP-specific namespace delimiter conventions
Gaikwad Expires 14 February 2027 [Page 34]
Internet-Draft Agent-Tool Proxy Modes August 2026
* _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
---
Appendix C. Implementation Status
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.
C.1. yamp
* *Organization:* independent
* *Name and URL:* yamp (Yet Another MCP Proxy) [YAMP]
* *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.
Gaikwad Expires 14 February 2027 [Page 35]
Internet-Draft Agent-Tool Proxy Modes August 2026
* *Coverage:* The modes of Section 5 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 Section 6,
transport, routing, resilience, and capability are implemented;
discovery, policy, and session are partial.
* *Conformance tier:* Tier 3 (Section 4.2), 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 Section 5.4.2.
* *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 (Section 8.2). Original-destination recovery for the
transparent modes (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.
* *Contact:* Madhava Gaikwad, gaikwad.madhav@gmail.com
---
Gaikwad Expires 14 February 2027 [Page 36]
Internet-Draft Agent-Tool Proxy Modes August 2026
Appendix D. Example Bindings
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
Gaikwad Expires 14 February 2027 [Page 37]
Internet-Draft Agent-Tool Proxy Modes August 2026
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.
Appendix E. Surveyed Implementations
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.
Gaikwad Expires 14 February 2027 [Page 38]
Internet-Draft Agent-Tool Proxy Modes August 2026
+----+----------------------+--------------------------------+
| | 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.
Author's Address
Madhava Gaikwad
Independent
Email: gaikwad.madhav@gmail.com
URI: https://github.com/mcpx-project
Gaikwad Expires 14 February 2027 [Page 39]