--- schema_version: "1" id: da285914ca117234f993a657b9fcbdfc96ae429823ec9f74af8a5f72c7e9b464 title: Making Your APIs Agent-Ready collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/general/af-use-case-mcp-bridge.md canonical_url: https://docs.mulesoft.com/general/af-use-case-mcp-bridge source_site: docs.mulesoft.com content_type: documentation content_hash: 4f1ecaf2a0139ea4fce36d69d4e5884d5ff0ac39b7b13551f6eeac6197369296 description: MuleSoft Documentation Site latest: true --- --- product: Getting Started --- # Making Your APIs Agent-Ready > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You’ve invested heavily in API infrastructure, but you didn’t design your APIs for agents to consume. For agents to act on the systems behind those APIs, you need to make each operation callable. You must decide which operations are safe to expose and figure out how to keep access consistent across every agent platform, all of which usually leads to a bunch of custom integrations. Agent Fabric removes all this work. In Agent Fabric, you expose an existing API as a Model Context Protocol (MCP) server through configuration alone. You choose which operations become agent-ready tools, and you apply your governance pattern, without touching the underlying API. ## The Problem Adapting existing APIs for agentic workflows presents several challenges. - API complexity: Existing APIs aren’t designed for agent consumption. - Security concerns: APIs often include write and delete operations that are too risky for agents. - Integration overhead: Building custom integrations for each agent platform is time-consuming. - Inconsistent access: Different agents access the same APIs in different ways. - Governance gaps: It’s hard to track and control how agents use existing APIs. You need a way to make this API infrastructure available to agents safely and efficiently, without rebuilding it. ## The Solution Agent Fabric exposes your existing APIs as MCP servers. Agents then get safe, efficient API access: - Rapid integration: Connects existing API instances to agents through configuration alone, without rewriting the API or building a custom integration for each agent platform. - Selective exposure: Exposes only the operations you explicitly map as discrete MCP tools that agents can discover and call. Write and delete operations stay off-limits unless you choose to expose them, without modifying the underlying API. - Centralized management: Provides a single point of control so that all agents reach your APIs the same way. Access, policy, and monitoring stay unified as you add agents, with governance policies applied from the same portfolio. - Agent-facing abstraction: Presents existing REST API operations as MCP tools so that agents can call them without needing API-specific details. - Asset reuse: Works with your MuleSoft API infrastructure without rebuilding assets for agentic use. ## How It Works Omni Gateway is the runtime enforcement point for Agent Fabric. This single gateway sits in front of your agents, APIs, and MCP servers so that authentication, monitoring, and policy enforcement apply to every request. When you expose an API as an MCP server, you create the server from the API and choose which operations to publish as tools. You then deploy the MCP server on Omni Gateway. A required MCP support policy makes the server callable, and you apply additional policies to govern every request. The server runs on the same gateway infrastructure you use to manage your API traffic. Each agent request follows this path: 1. The AI agent makes an MCP request. 2. The request flows through Omni Gateway, where the MCP server’s policies execute. 3. The MCP server maps the request to the underlying API operation that you’ve exposed as an MCP tool. 4. The call reaches the backend API. 5. Responses flow back through the gateway to the agent. ## Who This Is For Exposing APIs as MCP servers is ideal for: - Companies with existing API infrastructure - Security teams concerned about agent access to sensitive operations - Integration teams who enable agents quickly without custom development - Architects who design safe agent access to enterprise systems - Teams who want to build on investments in API management and governance ## Example Scenarios Different companies expose APIs as MCP servers to solve specific agent access challenges. ### Scenario 1: Customer Service Agent with Read-Only Access **Challenge:** Customer service agents answer questions about customer accounts and orders but can’t modify data. Without an MCP server in front of the API, you must build custom integrations for each agent platform. This approach risks exposing write operations and creates inconsistent behavior across platforms. By exposing the API as an MCP server, you deploy rapidly with built-in safety. Here’s how you do it: 1. Create an MCP server from your customer API, publishing only its read (GET) operations as tools. 2. Deploy the server on Omni Gateway and apply the required MCP support policy. 3. Connect all agent platforms to the MCP server endpoint. **Result:** Agents answer account and order questions with no write access exposed, from a single configuration. You don’t build or maintain a per-platform integration, and no path exists for an agent to modify customer data. ### Scenario 2: Inventory Check Agent **Challenge:** Your inventory API includes operations to check stock levels, reserve items, adjust quantities, and process transfers. Sales agents, warehouse agents, and customer service agents all check current stock, but only warehouse systems adjust it. Without an MCP server in front of the API, you either expose the full API (risking accidental adjustments) or build filtered endpoints for each agent type. By exposing the API as an MCP server, you give all agents read-only inventory access from a single configuration. Here’s how you do it: 1. Create an MCP server from the inventory API, publishing only the read (GET) operations for stock queries as tools. 2. Deploy the server on Omni Gateway. 3. Connect all agent types to the MCP server endpoint. 4. Monitor agent usage alongside your existing services. **Result:** Sales, warehouse, and customer service agents all read live stock levels from one read-only tool surface. Stock adjustments stay restricted to warehouse systems, without a filtered endpoint for each agent type. ### Scenario 3: Financial Data Agent with Layered Tool Selection **Challenge:** Different agents need different levels of access to financial APIs. Without a controlled tool surface, you build separate custom integrations for each agent access level. This duplication increases the risk that a high-privilege operation reaches the wrong agent. By exposing the API as multiple MCP servers with layered tool selection, you get fine-grained access control with safety guarantees. Here’s how you do it: 1. Create multiple MCP servers from your financial API, each publishing a different set of tools: the Basic server with GET operations for account balances, the Analytics server with GET operations for transaction history and reports, and the Approval server with GET operations plus the POST operation for creating approval requests. 2. Deploy each server on Omni Gateway, and connect each agent to the appropriate endpoint based on access requirements. 3. Apply policies to each MCP server to govern runtime access. **Result:** Each agent gets exactly the access its role requires. Agents access balances, analytics, or approval requests from one financial API, with no duplicated integrations and no path for a high-privilege operation to reach the wrong agent. ### Scenario 4: Mule Integration Platform **Challenge:** Your company has extensive Mule infrastructure and wants agentic access without rebuilding integrations. Without a configuration-based approach, you need to build agent-specific adapters on top of each Mule API. Those adapters duplicate logic and bypass the governance that protects those APIs. By exposing your Mule APIs as MCP servers, you extend your existing Mule investment to agentic use cases. Here’s how you do it: 1. Create MCP servers from key Mule APIs, publishing the operations you want to expose as tools. 2. Deploy the servers on your existing Omni Gateway infrastructure. 3. Monitor usage and apply policies the same way you do for your existing APIs. **Result:** Existing Mule APIs become agent-callable without new adapters or duplicated logic, and agent traffic inherits the same governance already protecting those APIs. ## Implementation Steps ### Step 1: Identify APIs for Agent Access 1. List APIs that agents access. 2. Document the current API operations (GET, POST, PUT, DELETE). 3. Identify which operations are safe for agents. 4. Prioritize APIs by business value and risk. ### Step 2: Select Tools for Each API Instance For each API instance: - Identify which operations agents can access. - Decide whether read-only operations are sufficient. - If agents require write access, identify which write operations they use. - Identify which Omni Gateway policies apply to the resulting MCP server. ### Step 3: Create and Deploy an MCP Server 1. Create an MCP server from your target API, and select which operations to publish as tools. Apply read-only filtering to expose only the operations that are safe for agents. 2. Deploy the server on Omni Gateway, configuring the server label, base path, protocol, and port, and the upstream connection. 3. Apply the required MCP support policy so the server is callable. 4. Test the MCP server endpoint with sample requests. For the steps to create an MCP server from an existing API, see [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server). For the steps to deploy it on Omni Gateway, see [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add). ### Step 4: Apply Omni Gateway Policies The MCP server controls which API operations are available as tools. Omni Gateway policies control how agents can use those tools at runtime. After deploying the MCP server, apply policies to the MCP server to enforce authentication, rate limiting, logging, and alerting. For the steps to apply policies, see [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage). ### Step 5: Connect Agents 1. Update agents to use the MCP server. 2. Test with realistic scenarios. 3. Verify that agents can call only the operations you expose. 4. Monitor initial usage. ### Step 6: Monitor and Refine 1. Review latency, error rates, and request volume for your MCP server. 2. Analyze which tools agents call and identify missing operations. 3. Check gateway logs for attempts to call unexposed operations. 4. To change which operations agents can call, update the MCP server’s tool selection and redeploy. To monitor MCP servers alongside other services in your portfolio, see [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring). ## Tool Selection Strategies Choose which API operations to expose as discrete MCP tools that agents can discover and call. When you create the MCP server, you select which operations to publish as tools. Expose all operations, only read operations, or any subset you choose, without modifying the underlying API. Consider a Customer API with both read and write operations: ```text Customer API: - GET /customers/{id} (read) - POST /customers (create) - PUT /customers/{id} (update) - DELETE /customers/{id} (delete) - GET /customers/{id}/orders (read) - POST /customers/{id}/orders (create) ``` After you configure the MCP server to expose only read operations, agents see a reduced tool surface: ```text Customer API (Agent Tool Surface): - GET /customers/{id} (read - exposed as an MCP tool) - GET /customers/{id}/orders (read - exposed as an MCP tool) ``` The agent can read customer and order data but can’t create, modify, or delete anything. The write operations exist in the underlying API but aren’t exposed as MCP tools. ### Read-Only Operation Mapping Map only GET operations to tools first. Explicitly map write operations only when a use case requires them. ### Operation Allowlisting Select specific operations to expose rather than trying to identify operations to block. Allowlisting is safer and easier to maintain. ## Common Tool Selection Patterns Choose an approach based on your security requirements and use cases. ### Read-Only Tool Surface Use this pattern when agents only retrieve data. Expose all GET operations as tools and exclude all write (POST, PUT, DELETE) operations. ```text (exposed) GET /resource/{id} (exposed) GET /resource (not exposed) POST /resource (not exposed) PUT /resource/{id} (not exposed) DELETE /resource/{id} ``` ### Read and Create Tool Surface Use this pattern when agents look up records and create new ones but don’t modify or delete existing data. ```text (exposed) GET /resource/{id} (exposed) POST /resource (not exposed) PUT /resource/{id} (not exposed) DELETE /resource/{id} ``` ### Read and Request-Only Tool Surface Use this pattern when agents initiate a workflow (for example, submitting an approval request) without directly modifying records. ```text (exposed) GET /resource/{id} (exposed) POST /resource/request (not exposed) PUT /resource/{id} (not exposed) DELETE /resource/{id} ``` ### Granular Tool Surface Use this pattern for fine-grained control. Expose specific safe operations and block others based on assessments of business risk. For example, expose `GET /orders/{id}` so agents can view order details, but block `PUT /orders/{id}/status` to prevent agents from changing order status. This pattern gives agents access to the information they need while protecting sensitive operations. ```text (exposed) GET /orders/{id} (exposed) POST /orders/{id}/notes (add note - safe) (not exposed) PUT /orders/{id}/status (change status - risky) (not exposed) DELETE /orders/{id} (delete order - risky) ``` ## Security Considerations When you expose APIs as MCP servers, follow these security practices to minimize risk and maintain control over agent access to your APIs. ### Default Deny Start with no access and grant only the operations that agents use. Apply Omni Gateway policies to turn on logging and monitor MCP server usage. ### Regular Reviews Periodically review: - Which operations are in use - Whether your tool selection is still appropriate - Whether to remove additional operations from the agent tool list ## Integration with Existing Tools MCP servers integrate with your MuleSoft infrastructure, identity systems, and gateway deployment to build on investments you’ve made. ### Mule Integration Expose Mule API instances you manage as MCP servers without rebuilding them. - Expose existing Mule APIs as MCP servers. - Reuse your existing governance. - Extend Mule monitoring to agent access. - Reuse existing API policies. ### Omni Gateway Integration MCP servers run on Omni Gateway infrastructure. They’re managed through API Manager and protected by Omni Gateway policies, like API instances. - Create and deploy MCP servers on the same Omni Gateway that manages your APIs. - Apply policies to MCP servers the same way you apply them to APIs. - Use unified monitoring and alerting across APIs and MCP servers. ### Identity Systems MCP servers work with existing identity infrastructure so that agent access to APIs respects the same authentication and authorization rules you already have in place. - Integrate with existing authentication. - Use existing authorization rules where applicable. - Extend identity-based access control to agents. ## Related Documentation - [Agent Fabric Use Cases](https://docs.mulesoft.com/general/agent-fabric-use-cases) - [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server) - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring)