MuleSoft MCP and A2A in Production: What 17 Recipes Reveal

I searched Stack Overflow for MuleSoft MCP implementation questions last week. Zero results. Searched Reddit r/mulesoft for A2A discussions. Zero threads. Checked the Salesforce Trailblazer community, the MuleSoft help forum, and Salesforce Stack Exchange. Nothing. Across seven community sources where MuleSoft practitioners ask for help, MCP and A2A implementation questions don't exist yet.

Meanwhile, MuleSoft shipped MCP Connector GA in 2025. The A2A Connector hit general availability shortly after. Agentforce 3 is built on MCP interoperability. Every enterprise integration team I work with is evaluating agentic AI. The vendor announcements are loud. The practitioner content is empty.

I maintain the mulesoft-cookbook — 588 production-grade MuleSoft recipes, 17 of which cover MCP and A2A. The complexity distribution across those 17 tells you where teams will struggle before they start.

The Implementation Ladder Nobody Talks About

Those 17 recipes aren't 17 variations of the same thing. They form a three-tier implementation ladder, and every existing tutorial stops at the bottom rung.

Tier 1: Connectivity (4 Recipes)

MCP IDE setup, MCP server basics, MCP client, URL-based servers. This is where the Medium tutorials live. Stand up an MCP server, expose a tool, call it from an AI agent. The MuleSoft documentation covers this well:

<!-- MCP Server Config (Streamable HTTP) -->
<mcp:server-config name="mcp-server-config"
    serverName="My MCP Server" serverVersion="1.0.0">
    <mcp:streamable-http-server-connection
        listenerConfig="http-listener-config" />
</mcp:server-config>
<!-- Expose a tool via mcp:tool-listener -->
<flow name="getWeatherFlow">
    <mcp:tool-listener config-ref="mcp-server-config" name="get-weather">
        <mcp:description>Get current weather for a city</mcp:description>
        <mcp:parameters-schema><![CDATA[{
            "$schema": "http://json-schema.org/draft-07/schema#",
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "City name"}
            },
            "required": ["city"]
        }]]></mcp:parameters-schema>
    </mcp:tool-listener>
    <http:request method="GET" url="https://api.open-meteo.com/v1/forecast" />
</flow>

From mcp-server-basics. Three XML blocks and your Mule app is an MCP server. This is the part everybody writes about.

Tier 2: Production Hardening (7 Recipes)

OAuth security, streaming responses, resource subscriptions, distributed tracing, load-balanced servers, tool discovery exchange, URL-based server management. This is where tutorials vanish, and production failures begin.

Take distributed tracing. An AI agent calls your MCP tool. Your tool calls a CRM API. The CRM API calls a database. Something is slow. Without tracing, you're guessing which hop is the bottleneck. With W3C Trace Context propagated through the MCP layer:

<flow name="mcp-traced-tool">
    <http:listener config-ref="HTTP_Listener" path="/mcp/tools/get-customer"/>
    <!-- Extract trace context from MCP request -->
    <set-variable variableName="traceId"
                  value="#[attributes.headers.traceparent default correlationId]"/>
    <logger message="MCP tool call started | traceId=#[vars.traceId] | tool=get-customer"/>
    <!-- Propagate trace to downstream -->
    <http:request config-ref="CRM_API" path="/customers/#[payload.params.customerId]">
        <http:headers>#[{"traceparent": vars.traceId}]</http:headers>
    </http:request>
    <logger message="MCP tool call completed | traceId=#[vars.traceId]"/>
</flow>

From distributed-tracing. The MCP protocol does not mandate tracing — you implement it as a convention. Skip this, and your first production debugging session for a slow agent call takes hours instead of minutes.

OAuth security is the other Tier 2 essential. The MCP protocol does not natively define authentication. Every MCP endpoint exposed without OAuth is an open door. I've seen teams deploy MCP servers to CloudHub with no auth because the getting-started tutorial didn't include it. The oauth-security recipe adds token introspection at the MCP entry point — validate before any tool executes.

Tier 3: Multi-Agent Orchestration (6 Recipes)

A2A protocol fundamentals, agent card registry, push notifications, streaming artifacts, error recovery, and multi-agent orchestration. No existing practitioner content covers this tier at all.

The orchestration pattern is where the architecture shifts. Instead of one agent calling one MCP server, you have an orchestrator decomposing tasks across specialized agents via A2A:

<flow name="orchestrator-flow">
    <http:listener config-ref="HTTP_Listener" path="/orchestrate" method="POST"/>
    <!-- Step 1: Research agent gathers data -->
    <http:request config-ref="Research_Agent" path="/a2a/tasks/send" method="POST">
        <http:body>#[output application/json --- {
            jsonrpc: "2.0", method: "tasks/send",
            params: {task: {message: {role: "user",
                parts: [{type: "text", text: payload.query}]}}}
        }]</http:body>
    </http:request>
    <set-variable variableName="researchResult"
                  value="#[payload.result.task.message.parts[0].text]"/>
    <!-- Step 2: Analysis agent processes research -->
    <http:request config-ref="Analysis_Agent" path="/a2a/tasks/send" method="POST">
        <http:body>#[output application/json --- {
            jsonrpc: "2.0", method: "tasks/send",
            params: {task: {message: {role: "user",
                parts: [{type: "text", text: vars.researchResult}]}}}
        }]</http:body>
    </http:request>
</flow>

From multi-agent-orchestration. Two agent calls, sequential. It looks simple. It isn't. Circular agent calls cause infinite loops — you need call depth limits. Latency compounds with sequential calls — parallelize where the task graph allows. Agent failures need fallback handling because agents fail differently than APIs: partial results, non-deterministic timeouts, and cascading retries.

The Production Gap

The complexity distribution across these 17 recipes reveals the problem. Only 3 are foundational or moderate — the level where current tutorials operate. Fourteen are moderately_hard, hard, complex, or very_complex. That means 82% of the implementation work lives above the tutorial line.

Compare this with the DataWeave pattern ecosystem in the same cookbook: 102 recipes, hundreds of Stack Overflow questions, dozens of practitioner-authored articles across DZone, Medium, and Hashnode. The community content ecosystem around DataWeave took years to form. MCP and A2A are in their first year of GA availability. The content hasn't formed yet.

This gap matters because teams are making architectural decisions right now about agentic integration. They're standing up MCP servers from the getting-started guide and calling it done. The questions they should be asking — how do I secure this? How do I trace agent calls? What happens when an agent in my orchestration fails? — have no community answers yet. Not on Stack Overflow. Not on Reddit. Not in any forum I could find.

I've seen this pattern before. When MuleSoft introduced API-led connectivity in 2017, the getting-started guides covered Experience, Process, and System layers. What they didn't cover was what happens when your Process layer calls three System APIs and one of them is slow. Teams deployed and learned about circuit breakers, bulkheads, and caching through production incidents. The error-handling section of the cookbook has 51 recipes — most exist because somebody's integration failed at 2 AM.

MCP and A2A are following the same trajectory. The difference is speed. API-led connectivity had years to build a community knowledge base before most enterprises adopted it. MCP went from announcement to GA to Agentforce integration in under a year. Teams are deploying before the community has had time to document what goes wrong.

The danger isn't that teams will fail to build MCP servers. Tier 1 is straightforward. The danger is that they'll deploy unsecured, unobservable MCP endpoints to production and discover the Tier 2 problems through incidents rather than preparation.

Three Things to Implement Before Going Multi-Agent

If you're evaluating MCP and A2A for your MuleSoft environment, these three patterns determine whether your implementation scales or stalls.

1. OAuth on every MCP endpoint. The MCP protocol has no built-in authentication. Your MCP server is an HTTP listener with tool-specific routes. Without OAuth token validation at the entry point, any client that discovers your server URL can invoke your tools. Add introspection-based validation before any tool executes. Cache validation results to manage the latency overhead. See the oauth-security recipe for the full pattern — token extraction, introspection call, scope-to-tool mapping.

2. Distributed tracing from agent to data source. When an AI agent calls your MCP tool and the response takes 8 seconds, you need to know whether the latency is in the agent reasoning, the MCP transport, your Mule flow, or the backend API. Propagate W3C Trace Context through every hop. Most teams skip this because tracing feels optional until the first 8-second agent response hits production with no visibility into which hop caused it. The distributed-tracing recipe shows the extraction and propagation pattern. Without this, your first agent-related production incident is a guessing game.

3. A2A error recovery with fallback agents. Agents are not APIs. They have non-deterministic response times, they can return partial results, and LLM rate limits create transient failures that look permanent. The retry-then-fallback pattern in the error-recovery recipe uses until-successful with a secondary agent fallback. The critical detail: every retried task must be idempotent. Teams that skip this discover the problem when an agent triggers a duplicate Salesforce record update on retry — at 2 am with a production incident open. If your agent creates a record on each invocation, three retries mean three duplicate records. Design for idempotency first, retry second.

What Comes Next

The MCP/A2A ecosystem will develop the same way DataWeave patterns did — through practitioner implementation experience shared across communities, not through vendor documentation alone. Right now, the community is silent because most teams are still in evaluation or proof-of-concept. The production questions will come.

The 17 recipes in the cookbook are a starting point — the implementation ladder from basic connectivity through production hardening to multi-agent orchestration. Each recipe links to a working configuration that you can deploy, test, and extend. What the ecosystem needs now is more practitioners sharing what they learn at Tier 2 and Tier 3: what breaks, what scales, what they wish they'd known before deploying their first MCP server to production.

What I'd like to see from the community: implementations of MCP server patterns in non-standard environments — MCP behind API gateways with rate limiting per agent, A2A orchestration with more than two agents in the chain, tracing patterns for async agent workflows where the response comes minutes after the request. The patterns in the cookbook assume synchronous request-response. Real-world agent workflows are often asynchronous, event-driven, and unpredictable in latency. Those patterns need to be written from production experience, not from documentation.

The full MCP and A2A recipe collection — including OAuth security, distributed tracing, and multi-agent orchestration — is in the mulesoft-cookbook on GitHub.