Of the 588 production-grade recipes in the MuleSoft Cookbook, exactly 17 address MCP and A2A. Only 3 of those 17 are foundational or moderate in complexity. The remaining 14 — 82% — land somewhere between moderately hard and very complex. Meanwhile, searches on Stack Overflow, Reddit, and Salesforce community forums for MCP and A2A implementation questions return nothing.
Zero results. Not sparse results. Zero.
That gap between what's shipped and what's documented should concern any integration architect planning to move agent-based patterns past a proof of concept. The protocols are available. The governance controls exist in Anypoint Platform. But the practitioner knowledge needed to operate these capabilities in a regulated, observable, production-grade environment? It hasn't been written yet.
The Three-Tier Reality
Balachandra Shakar Bisetty's analysis of the MuleSoft Cookbook's 17 MCP/A2A recipes reveals a three-tier implementation ladder that maps cleanly to how enterprise teams actually fail. Tier 1 — connectivity — covers the basics: MCP IDE setup, server configuration, client wiring, URL-based servers. Four recipes. This is the part that works in a demo and breaks in production.
Tier 2 — production hardening — is where the real work begins. Seven recipes address OAuth security, streaming responses, resource subscriptions, distributed tracing, load balancing, tool discovery, and server lifecycle management. These aren't optional add-ons. They're the difference between a working prototype and a supportable system. The MCP protocol lacks built-in authentication, which means every endpoint requires externally enforced OAuth and token introspection. Skip this step and you've deployed an unsecured, unobservable agent interaction surface into your enterprise.
Tier 3 — multi-agent orchestration — adds six more recipes covering A2A fundamentals, agent card registries, push notifications, error recovery, and orchestration patterns for sequential and parallel agent execution. This tier introduces non-deterministic response times, partial results, and the kind of failure modes that don't appear in synchronous API contracts.
Why This Echoes 2017
Integration architects with long memories will recognize this pattern. When MuleSoft introduced API-led connectivity in 2017, the initial vendor documentation covered the happy path. Production incidents — and eventually community-driven solutions — filled in the rest. Schema drift, error propagation across experience-process-system layers, retry storms in async flows: none of that appeared in the launch materials.
MCP and A2A are following the same trajectory, but faster. MuleSoft's 2025 announcements positioned Anypoint Platform as the control plane for agent-to-system and agent-to-agent interactions, with governance features including rate limiting, access control, and audit logging. The platform's Flex Gateway supports policy enforcement — PII detection, attribute-based access control — across agent interactions discovered through the Agent Registry. The machinery exists.
But machinery without operational knowledge produces incidents, not outcomes.
Three Controls That Can't Wait
For teams moving MCP/A2A past pilot, three controls deserve immediate attention — not because they're sophisticated, but because skipping them creates failure modes that are expensive to fix retroactively.
OAuth on every MCP endpoint. The protocol doesn't authenticate. Your gateway must. Token introspection at the Flex Gateway layer prevents unauthorized agent invocations from reaching backend systems. This isn't a hardening task for later — it's a prerequisite for any environment where data classification matters.
Distributed tracing from day one. Agent interactions span multiple services, and latency attribution without W3C Trace Context propagation is guesswork. When an agent-to-agent orchestration takes 14 seconds instead of 2, you need to know whether the bottleneck is in tool discovery, downstream API response time, or the orchestration layer itself. Instrument before you scale.
A2A error recovery with idempotency. Agents produce non-deterministic outputs. Retries are inevitable. Without idempotency keys on task execution, a retry can duplicate a purchase order, trigger a redundant approval, or double-post a journal entry. Fallback mechanisms — graceful degradation when an agent returns partial results — belong in the initial design, not in the post-incident runbook.
The Evidence Gap Is the Honest Starting Point
A candid assessment: publicly available production case studies for MCP and A2A don't exist yet in meaningful numbers. MuleSoft's own materials are largely demo-driven — Agent Registry discovery, Flex Gateway deployment, natural-language Mule application generation. These are useful for understanding platform direction. They aren't substitutes for production telemetry, SLO definitions, or incident post-mortems from real deployments.
Third-party framing from analysts like Tyk notes that MuleSoft's MCP approach is packaged within Anypoint Platform entitlements and oriented toward governance-heavy enterprise deployment rather than open experimentation. That's a trade-off, not a flaw — but it means the community knowledge base will build more slowly than it did for open-source MCP implementations.
For integration architects evaluating MCP and A2A today, the practical question isn't whether the protocols work. The question is whether your team can operate them — with OAuth enforcement, trace propagation, idempotent error recovery, and lifecycle governance — at the tier where 82% of the actual complexity lives. The four tutorial-level recipes are the easy part. The thirteen above them are where production reliability gets decided.
In 2017, the teams that shipped production API-led connectivity earliest weren't the ones with the best demos. They were the ones that documented their failure modes and shared them. The same pattern applies here — and the forums are still empty.