Managing Model Context Protocol in iRules - Part 1

The Model Context Protocol (MCP) was introduced by Anthropic in November of 2024, and has taken the industry by storm since. MCP provides a standardized way for AI applications to connect with external data sources and tools through a single protocol, eliminating the need for custom integrations for each service and enabling AI systems to dynamically discover and use available capabilities. It's gained rapid industry adoption because major model providers and numerous IDE and tool makers have embraced it as an open standard, with tens of thousands of MCP servers built and widespread recognition that it mostly solves the fragmented integration challenge that previously plagued AI development. In this article, we'll take a look at the MCP components, how MCP works, and how you can use the JSON iRules events and commands introduced in version 21 to control the messsaging between MCP clients and servers.

MCP components

Host

The host is the AI application where the LLM logic resides, such as Claude Desktop, AI-powered IDEs like Cursor, Open WebUI with the mcpo proxy like in our AI Step-by-Step labs, or via custom agentic systems that receive user requests and orchestrate the overall interaction.

Client

The client exists within the host application and maintains a one-to-one connection with each MCP server, converting user requests into the structured format that the protocol can process and managing session details like timeouts and reconnects.

Server

Servers are lightweight programs that expose data and functionality from external systems, whether internal databases or external APIs, allowing connections to both local and remote resources. Multiple clients can exist within a host, but each client has a dedicated (or perceived in the case of using a proxy) 1:1 relationship with an MCP server. MCP servers expose three main types of capabilities:

• Resources - information retrieval without executing actions
• Tools - performing side effects like calculations or API requests
• Prompts - reusable templates and workflows for LLM-server communication

Message format (JSON-RPC)

The transport layer between clients and servers uses JSON-RPC format for two-way message conversion, allowing the transport of various data structures and their processing rules. This enforces a consistent request/response format across all tools, so applications don't have to handle different response types for different services.

Transport options

MCP supports three standard transport mechanisms: stdio (standard input/output for local connections), Server-Sent Events (SSE for remote connections with separate endpoints for requests and responses), and Streamable HTTP (a newer method introduced in March 2025 that uses a single HTTP endpoint for bidirectional messaging). 

NOTE: SSE transport has been deprecated as of protocol version 2024-11-05 and replaced by Streamable HTTP, which addresses limitations like lack of resumable streams and the need to maintain long-lived connections, though SSE is still supported for backward compatibility.

MCP workflow

Pictures tell a compelling story. First, the diagram.

The steps in the diagram above are as follows:

1. The MCP client requests capabilities from the MCP server
2. The MCP server provides a list of available tools and services
3. the MCP client sends the question and the retrieved MCP server tools and services to the LLM
4. The LLM specifies which tools and services to use.
5. The MCP client calls the specific tool or service
6. The MCP server returns the result/context to the MCP client
7. The MCP client passes the result/context to the LLM
8. The LLM uses the result/context to prepare the answer

iRules MCP-based use cases

There are a bunch of use cases for MCP handling, such as:

• Load-balancing of MCP traffic across MCP Servers
• High availability of the MCP Servers
• MCP message validation on behalf of MCP servers
• MCP protocol inspection and payload modification
• Monitoring the MCP Servers' health and their transport protocol status.
• In case of any error in MCP request and response, BIG-IP should be able to detect and report to the user
• Optimization Profiles Support 
  • Use OneConnect Profile
  • Use Compression Profile
• Security support for MCP servers. There are no native features for this yet, but you can build your own secure business logic into the iRules logic for now.

LTM profiles

Configuring MCP involves creating two profiles - an SSE profile and a JSON profile - and then attaching them to a virtual server. The SSE profile is for backwards compatibility should you need it in your MCP client/server environment. The defaults for these profiles are shown below.

[root@ltm21a:Active:Standalone] config # tmsh list ltm profile sse all-properties
ltm profile sse sse {
    app-service none
    defaults-from none
    description none
    max-buffered-msg-bytes 65536
    max-field-name-size 1024
    partition Common
}
[root@ltm21a:Active:Standalone] config # tmsh list ltm profile json all-properties
ltm profile json json {
    app-service none
    defaults-from none
    description none
    maximum-bytes 65536
    maximum-entries 2048
    maximum-non-json-bytes 32768
    partition Common
}

These can be tuned down from these maximums by creating custom profiles that will meet the needs of your environment, for example (without all properties like above):

[root@ltm21a:Active:Standalone] config # tmsh create ltm profile sse sse_test_env max-buffered-msg-bytes 1000 max-field-name-size 500
[root@ltm21a:Active:Standalone] config # tmsh create ltm profile json json_test_env maximum-bytes 3000 maximum-entries 1000 maximum-non-json-bytes 2000
[root@ltm21a:Active:Standalone] config # tmsh list ltm profile sse sse_test_env
ltm profile sse sse_test_env {
    app-service none
    max-buffered-msg-bytes 1000
    max-field-name-size 500
}
[root@ltm21a:Active:Standalone] config # tmsh list ltm profile json json_test_env
ltm profile json json_test_env {
    app-service none
    maximum-bytes 3000
    maximum-entries 1000
    maximum-non-json-bytes 2000
}

NOTE: Both profiles have database keys that can be temporarily enabled for troubleshooting purposes. The keys are log.sse.level and log.json.level. You can set the value for one or both to debug. Do not leave them in debug mode!

Conclusion

Now that we have the laid the foundation, continue on to part 2 where we'll look at the first two use cases.

NOTE: This series is ghostwritten. Awaiting permission from original author to credit.