The marquee theme of the BIG-IP 21.x line is that TMOS now treats AI traffic as a first-class protocol rather than as opaque HTTP. The protocol in question is , the Model Context Protocol: the JSON-RPC 2.0 convention that lets an client discover and call tools on MCP servers, carried over Streamable HTTP or, for compatibility, HTTP with Server-Sent Events. That combination, long-lived sessions, streaming responses, and tool calls with real side effects, is exactly the kind of traffic a naive load balancer mishandles and a naive (web application firewall) cannot read. The 21.x releases attack the problem in two steps.

21.0: BIG-IP learns to speak MCP

BIG-IP 21.0.0 introduced MCP support at the profile layer. Per F5's LTM profiles reference, handling MCP properly takes an HTTP profile plus JSON and (server-sent events) profiles on the virtual server: together they let TMM parse the JSON-RPC message structure, handle the two transports, and apply protocol-level inspection and optimization instead of blindly proxying bytes. The profiles expose size limits for the message parts, and JSON and SSE each bring their own iRules events and commands, so 21.0 already allowed parsing, manipulation, and traffic management of MCP flows.

Persistence, however, was still manual. MCP sessions are stateful when the server issues an Mcp-Session-Id, and from that moment the client must present it on every request; a stateful MCP server that receives a mid-session request on the wrong pool member has lost the dialog's context. F5's own 21.0 documentation and its published OpenShift walkthrough solved this with an iRule doing Universal (UIE) persistence keyed on the Mcp-Session-Id header: detect the MCP endpoints, read the token, pin the session. It worked, and it was exactly the kind of glue code a platform feature should eventually replace.

Alongside the protocol work, 21.0 added S3 data-storage integrations aimed at AI workloads, the side of (retrieval-augmented generation) pipelines, embeddings, fine-tuning, batch inference, and model-artifact distribution, so the same box that fronts the MCP endpoints can also sit in the storage path with controlled egress.

21.1: native persistence, the aimcp profile

BIG-IP 21.1.0 replaces the iRule with a real persistence type. LTM gains an MCP persistence profile, shipping as aimcp, and F5's release notes describe the mechanism precisely: TMM provides the client with a wrapped and encrypted Mcp-Session-ID value, ensuring both session continuity and security. F5's launch material describes the behavior as working much like cookie persistence: once the MCP server issues a session ID, subsequent traffic carrying that ID is routed to the same pool member. The wrapping detail is worth pausing on. The value the client holds is not the backend's raw session identifier; TMM encrypts and wraps it, so the token that transits the client cannot be trivially replayed against a different member or leak the backend's naming. If you know how BIG-IP cookie persistence encodes and optionally encrypts the pool-member cookie, this is the same philosophy applied to an AI protocol. The persistence-method explainer puts aimcp in context next to the classic methods.

21.1 also adds experimental support for A2A, the Agent2Agent protocol, with load balancing for A2A traffic and iRules-based logging and visibility, a signal of where this track goes next: not just clients talking to tool servers, but agents talking to agents through the same data plane.

21.1: the WAF learns the threat model

The second half of the release is protective. Advanced WAF in 21.1 gains MCP protocol inspection with a dedicated security policy template, the MCP Protection Policy, aimed at the attack classes the MCP Top 10 catalogs: tool poisoning, secret exposure, prompt and tool injection, and their relatives. The feature set reads like a WAF that has actually met MCP traffic: prompt and tool-injection detection in the JSON-RPC payloads, (server-side request forgery) protection for the outbound calls a tool invocation can trigger, Data Guard masking so secrets and sensitive patterns do not leave in responses, and (JSON Web Token) validation for the tokens that authenticate MCP clients. The template adds its own blocking page response type, and enforcement surfaces the MCP session ID in response headers and the MCP request ID in the response body, which makes correlating a block back to a specific tool call practical. Since it is a policy template, everything about how it enforces is readable the way any ASM policy is; the declarative-policy explainer applies unchanged.

One caveat belongs in bold in your design notes, straight from the release documentation: SSE streaming responses bypass response-side inspection. Request-side protections, the injection detection, SSRF checks, and JWT validation, see everything; but a response streamed as Server-Sent Events is not held for Data Guard style response scrubbing. If your threat model includes secret exfiltration in model output, the streaming path needs a compensating control, because the WAF is honest about not being one there.

MCP 2026-07-28 took the session away

Added 2026-10-03. Everything above describes MCP as it stood when BIG-IP 21.0 and 21.1 shipped: a server could issue an Mcp-Session-Id, and the client had to present it on every request. The protocol has moved. The Model Context Protocol's current revision is 2026-07-28, and its changelog opens by removing protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport: "Servers that need cross-call state use explicit, server-minted handles passed as ordinary tool arguments." The same revision removes the initialize handshake (every request now carries its protocol version in _meta), adds a server/discover call, removes ping and logging/setLevel, drops SSE stream resumability, and reclassifies the old HTTP+SSE transport as Deprecated. JSON-RPC batching had already gone in 2025-06-18.

For a load balancer the consequence is direct. The transport page is explicit about what a 2026-07-28-only server does with the old mechanics: an Mcp-Session-Id header on a request is ignored, "and do not mint or echo session IDs"; HTTP GET or DELETE to the MCP endpoint gets 405 Method Not Allowed. So the aimcp persistence profile, which F5's 21.1 profiles reference (updated 2026-07-07) describes as "appending persistence information to the value of the mcp-session-id cookie as it passes through the BIG-IP system", has a session identifier to work with only while the servers behind it speak the revisions that had one: 2025-03-26 through 2025-11-25, which the spec itself lists as the Streamable HTTP revisions that "could assign a session via the Mcp-Session-Id header". Against a server that has moved to 2026-07-28 there is no identifier for the profile to wrap, and session continuity becomes the server's problem, carried in its own handles.

What the new revision gives an intermediary instead is better than a session cookie. Streamable HTTP now mirrors selected body fields into HTTP headers "so that intermediaries (load balancers, gateways, observability tooling) can route and inspect requests without parsing the body": MCP-Protocol-Version on every POST, Mcp-Method on all requests, Mcp-Name on tools/call, resources/read and prompts/get (the tool name or resource URI, -wrapped as =?base64?...?= when it is not header-safe), and Mcp-Param-{Name} for any tool parameter the server marks with x-mcp-header in its input schema. A server that processes the body must reject a request whose headers do not match it, with HTTP 400 and the JSON-RPC error -32020 HeaderMismatch, precisely because of "a load balancer routing on the header value while the MCP server executes based on the body value". An LTM policy or iRule can therefore steer or refuse on the method and the tool name without a JSON profile at all. The spec adds one rule for anyone doing that: an intermediary that routes or rate-limits on these headers "SHOULD verify that the MCP-Protocol-Version header indicates a version that requires" headers to be validated against the body, and should reject rather than trust the headers when the version is older or the header is absent.

Two further transport notes belong in a BIG-IP design. The spec asks servers to send X-Accel-Buffering: no on SSE responses so that reverse proxies do not buffer the stream, and encourages a periodic SSE comment line as a keep-alive on long-lived streams; both are about intermediaries, and a full proxy sits squarely in that category. None of this changes the WAF caveat above: a response streamed as Server-Sent Events still bypasses response-side inspection.

Before you turn it on

Three checks, in order. First, platform: 21.x runs on rSeries, VELOS, and Virtual Edition only, so an iSeries estate stays on 17.x and out of this feature set entirely. Second, profiles: the MCP persistence profile and the WAF template both presuppose the virtual server already speaks MCP, HTTP plus JSON plus SSE profiles, so retrofit those first and confirm the size limits fit your payloads. Third, sessions: if you carried the 21.0-era persistence iRule forward, retire it when you attach aimcp rather than running both, one owner per session token. Fourth, since 2026-10-03: ask which MCP revision the servers speak. Servers on 2025-03-26 through 2025-11-25 issue the session identifier that aimcp wraps; a server on 2026-07-28 ignores it and never mints one, so plan persistence, if the backend still needs it, around the Mcp-Param-* headers the server chooses to expose, and verify MCP-Protocol-Version before trusting any mirrored header. The flagship 21.x overview places all of this in the wider release story.

Sources

MCP Protocol Protection, MCP session persistence and the profile settings above are documented by F5 across two sets of release notes and the profiles reference for the feature itself. The 2026-07-28 section quotes the Model Context Protocol specification's own versioning page, changelog and Streamable HTTP transport page, all read on 2026-10-03.