The Capability
Anypoint Platform can convert any Mule application or API into an MCP server. You write the API once; Anypoint exposes it both as traditional REST (for your apps) and MCP (for agents).
The Anypoint MCP Generator (GA in Q1 2026) reads RAML or OpenAPI specs and emits an MCP server with tools derived from operations, resources derived from GETs, and authentication mapped from the original security schemes. The resulting server runs on Anypoint Runtime Fabric or CloudHub 2.0 alongside the original API. Hot-reload picks up spec changes; one-click promotes through dev/test/prod. Salesforce acquired Anypoint expressly for this kind of agent-era leverage; expect tighter Agentforce integration through 2026.
Why It Matters
Enterprises have massive API estates. Re-exposing them for agents via MCP without rewriting is huge. The API team owns it once; agent teams consume via MCP; integration team governs both.
A typical large enterprise has 500-3,000 internal APIs across MuleSoft, Apigee, Kong, and homegrown gateways. Manually building MCP servers for each would consume entire engineering quarters. Auto-conversion compresses that to days. The architectural payoff: API specs become the single source of truth used by humans (REST), services (gRPC where supported), and agents (MCP). Ownership stays with the API team rather than fragmenting to individual agent-development teams.
Governance
Anypoint’s policy layer applies — rate limiting, auth, logging. MCP agents hit the same governance boundary as any other API consumer. No new security surface, mostly — with the catch that agent calls can be noisier and less predictable than traditional consumers.
Reuse Anypoint policies on the MCP-exposed surface: client-ID enforcement, OAuth 2.0 token validation, JSON-schema validation, rate limiting per client, IP allowlisting, response masking for PII. New policies to add for agent traffic: prompt-injection inspection on input parameters, output filtering for accidentally returned secrets, per-agent-identity throttling distinct from per-application limits, anomaly detection for sudden tool-call frequency spikes characteristic of runaway agents.
Patterns
Start with read-only APIs exposed to MCP — product catalog, knowledge base, pricing tables. Writes require more caution — agents can cause more damage faster than traditional consumers. Phase carefully.
Phased deployment sequence. Phase 1: read-only catalog APIs (products, articles, contacts) with no PII. Phase 2: read APIs with PII behind dynamic masking. Phase 3: low-risk writes (case creation, log entries) with idempotency keys and per-call confirmation. Phase 4: higher-risk writes (account updates, opportunity changes) with human-in-loop approval workflows triggered by the agent. Phase 5: orchestrated multi-step writes — only after the prior phases have produced clean operational telemetry for 90+ days.
Common Failure Modes
Five recurring patterns. Auto-converted servers exposing every API operation including admin endpoints — strip those before promotion. Authentication mapped to the API’s service account, which loses end-user context once the agent calls it. Lack of input-schema constraints on free-text fields, accepting prompt-injected payloads. Rate limits set at the application level not the agent level, allowing one agent to exhaust the budget for all others. No drift detection between the API spec and the deployed MCP server.
What to Do This Week
Pick three read-only APIs from your Anypoint catalog and run them through the MCP Generator into a sandbox for an agent team to experiment with.
