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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, BCP 14, 2017, . [RFC9110] Fielding, R., "HTTP Semantics", RFC 9110, 2022, . [RFC8693] Jones, M., "OAuth 2.0 Token Exchange", RFC 8693, 2020, . [RFC9207] Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, 2022, . 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, . [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", RFC 7239, 2014, . [TRACE-CONTEXT] W3C, "Trace Context", 2021, . [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, . [YAMP] Gaikwad, M., "yamp: a forward and transparent MCP proxy", 2026, . 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]