From 80b3bf33943c708f9f526366c3355161a740d941 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Wed, 15 Jul 2026 13:05:38 -0700 Subject: [PATCH 01/10] W-23450489 Agent Fabric Use Case: MCP Bridge --- .../ROOT/pages/af-use-case-mcp-bridge.adoc | 327 ++++++++++++++++++ 1 file changed, 327 insertions(+) create mode 100644 modules/ROOT/pages/af-use-case-mcp-bridge.adoc diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc new file mode 100644 index 00000000..47885808 --- /dev/null +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -0,0 +1,327 @@ += Make APIs Agent-Ready with MCP Bridge + +Agent Fabric's MCP Bridge converts your existing API instances into MCP servers through configuration, exposing their operations as MCP tools that agents can discover and call without modifying the underlying API. +Choose which operations to expose and apply optional read-only filtering to limit what agents can do, giving you control over agent access without rewriting anything. +Use this approach to make your existing Mule or API management investment immediately available to agents, with governance policies applied from the same portfolio. + +== The Problem + +You have invested heavily in API infrastructure, but adapting these APIs for agentic use is challenging: + +* **API complexity**: Existing APIs weren'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. + +Bridge your existing API infrastructure to agents safely and efficiently with MCP Bridge. + +== The Solution + +Agent Fabric's Model Context Protocol (MCP) Bridge enables safe, efficient API integration for agents: + +* **Rapid integration**: Connects existing API instances to agents through simple configuration, with no rewriting required. +* **Selective exposure**: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. +* **Optional read-only filtering**: Limits agent access to read-only operations when needed, without modifying the underlying API. +* **Centralized management**: Provides a single point of control for API access, with governance policies applied from the same portfolio. +* **Agent-facing abstraction**: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. +* **Existing tool compatibility**: Integrates with Mule and other API management platforms without rebuilding existing assets. + +== Who This Is For + +MCP Bridge is ideal for: + +* **Organizations with existing API infrastructure** (especially Mule users) +* **Security teams** who are concerned about agent access to sensitive operations +* **Integration teams** looking to enable agents quickly without custom development +* **Architects** who are designing safe agent access to enterprise systems +* **Teams** who want to leverage existing investments in API management + +== Selecting Operations to Expose as Tools + +MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. Expose all operations, a subset, or apply optional read-only filtering — without modifying the underlying API. + +=== Full API (All Operations Available) + +[source,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) +---- + +=== Configured Tool Surface (Read Operations Only) + +When you configure MCP Bridge to expose only read operations, agents see a reduced tool surface drawn from the same Customer API. + +[source,text] +---- +Customer API (Agent Tool Surface): +- GET /customers/{id} (read - exposed as tool) +- GET /customers/{id}/orders (read - exposed as 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 are not exposed as MCP tools. + +== How MCP Bridge Works + +[source,text] +---- +Agent → MCP Bridge → Tool Selection Layer → Backend API +---- + +Each agent request follows this path: + +. The AI agent makes a request using the Model Context Protocol. +. MCP Bridge receives the request and maps it to the underlying API. +. Only operations you exposed as MCP tools are reachable. +. The call reaches the backend API. +. Responses flow back through the bridge to the agent. + +== Example Scenarios + +=== Scenario 1: Customer Service Agent with Read-Only Access + +*Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. + +*Without MCP Bridge:* + +* Custom integration for each agent platform +* Risk of exposing write operations +* Inconsistent behavior across agent platforms + +*With MCP Bridge:* + +. Configure MCP Bridge to connect to the customer API instance +. Select only GET operations to expose as MCP tools +. Give agents safe, read-only access +. Serve all agent platforms from a single MCP server + +*Result:* Rapid deployment with built-in safety. + +=== Scenario 2: Inventory Check Agent + +*Challenge:* Multiple agents across different applications need to check inventory levels but can't adjust inventory. + +*Without MCP Bridge:* + +* Separate inventory API integration for each agent +* Risk of accidentally exposing inventory write operations +* Inconsistent data access patterns + +*With MCP Bridge:* + +. Create an MCP server from the inventory API instance +. Select only inventory query operations to expose as tools +. Connect all agents to the same configured tool surface +. Monitor all agent access centrally + +*Result:* Consistent, safe inventory access across all agents. + +=== Scenario 3: Financial Data Agent with Layered Tool Selection + +*Challenge:* Different agents need different levels of access to financial APIs. + +*Solution with MCP Bridge:* + +. Create multiple MCP servers from the financial API, each with a different tool selection: + * **Basic server**: Read-only tools for account balances + * **Analytics server**: Read-only tools for transaction history and reports + * **Approval server**: Read-only tools, plus a tool to create approval requests (but no direct change operations) +. Connect agents to the appropriate MCP server based on their access needs +. Apply governance policies from the same portfolio + +*Result:* Fine-grained access control with safety guarantees. + +=== Scenario 4: Mule Integration Platform + +*Challenge:* Organization has extensive Mule infrastructure and wants to enable agentic access without rebuilding integrations. + +*Solution:* + +. Deploy MCP Bridge for key Mule APIs. +. Use Mule's existing API management capabilities. +. Select which Mule API operations to expose as tools for agent access. +. Use existing monitoring and governance. + +*Result:* Extend existing Mule investment to agentic use cases. + +== Implementation Steps + +=== Step 1: Identify APIs for Agent Access + +. List APIs that agents access. +. Document current operations (GET, POST, PUT, DELETE). +. Identify which operations are safe for agents. +. Prioritize APIs by business value and risk. + +=== Step 2: Plan Your Tool Selection + +For each API instance, decide: + +* Which operations can agents access? +* Are read-only operations sufficient? +* If agents require write access, which specific write operations do they use? +* What Omni Gateway policies apply to the resulting MCP server? + +=== Step 3: Deploy MCP Bridge + +. Configure MCP Bridge for your target API instances. +. Select which operations to expose as MCP tools and apply optional read-only filtering. +. Test with sample requests. + +=== Step 4: Apply Omni Gateway Policies + +MCP Bridge controls which API operations are available as tools. Omni Gateway controls how agents are allowed to use them at runtime. After deploying MCP Bridge, apply Omni Gateway policies to the resulting MCP server to enforce authentication, rate limiting, audit logging, and alerting. + +See xref:use-case-policy-enforcement.adoc[Policy Enforcement] for implementation steps. + +=== Step 5: Connect Agents + +. Update agents to use MCP Bridge. +. Test with realistic scenarios. +. Verify that tool selection is working (agents can only call the operations you exposed). +. Monitor initial usage. + +=== Step 6: Monitor and Refine + +. Identify any operations that were not exposed but that agents need. +. Watch for attempts to call unexposed operations. +. Refine your tool selection based on real usage. + +== Key Benefits + +* **Rapid enablement**: Gets agents connected to APIs quickly, without custom development. +* **Security by default**: Exposes only the operations agents use, with optional read-only filtering. +* **Consistency**: Gives all agents access to APIs through the same controlled interface. +* **Leverage existing investments**: Works with Mule and other API platforms. +* **Centralized governance**: Provides a single point of control for agent API access. + +== Tool Selection Strategies + +=== Read-Only Filtering + +Start by exposing only GET/read operations as tools. Explicitly add 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. + +=== Data Scoping + +Combine tool selection with data filters (for example, expose only operations that access certain data categories). + +For runtime controls such as rate limiting and time-based access restrictions, see xref:use-case-policy-enforcement.adoc[Policy Enforcement]. + +== Common Tool Selection Patterns + +=== Read-Only Tool Surface + +Use this pattern when agents only retrieve data. Expose all GET/read operations as tools; exclude all write operations. + +[source,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 do not modify or delete existing data. + +[source,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. + +[source,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 — exposing specific safe operations and blocking others based on individual business risk assessments. + +[source,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 + +=== Default Deny + +Start with no access and explicitly enable only what agents use. + +Omni Gateway provides audit logging and anomaly monitoring for the resulting MCP server. See xref:use-case-policy-enforcement.adoc[Policy Enforcement]. + +=== Regular Reviews + +Periodically review: + +* Which operations are actually being used +* Whether your tool selection is still appropriate +* Whether additional operations should be removed from the agent tool list + +== Integration with Existing Tools + +=== Mule Integration + +MCP Bridge works directly with Mule APIs managed in Anypoint Platform, so you can expose existing Mule API instances as MCP servers without rebuilding them. + +* Use MCP Bridge with existing Mule APIs. +* Leverage Anypoint Platform governance. +* Extend Mule monitoring to agent access. +* Reuse existing API policies. + +=== API Gateways + +MCP Bridge can run alongside existing API gateways. Omni Gateway policies apply to the resulting MCP server in the same way they apply to other agent traffic. + +* Deploy MCP Bridge alongside existing gateways. +* Coordinate policies between gateway and bridge. +* Use unified monitoring and alerting across gateways and MCP servers. + +=== Identity Systems + +MCP Bridge can work with existing identity infrastructure so that agent access to APIs respects the same authentication and authorization rules already in place. + +* Integrate with existing authentication. +* Use existing authorization rules where applicable. +* Extend identity-based access control to agents. + +== Related Documentation + +// TODO: Update these links when Agent Fabric documentation is published. +* link:https://docs.mulesoft.com/agent-fabric/mcp-bridge[MCP Bridge Documentation] +* link:https://docs.mulesoft.com/agent-fabric/api-pruning[Selecting Operations to Expose as Tools] +* link:https://docs.mulesoft.com/agent-fabric/mule-integration[Integrating with Mule] + +== Next Steps + +With MCP Bridge providing safe API access, you're ready to: + +* xref:use-case-policy-enforcement.adoc[Add additional policy enforcement] +* xref:use-case-identity.adoc[Implement user-scoped API access] +* xref:use-case-orchestration.adoc[Build workflows using bridged APIs] From 7d8ec6215524b79c705ed14e28c9f746d2f56509 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Wed, 15 Jul 2026 14:27:42 -0700 Subject: [PATCH 02/10] Updated short description --- modules/ROOT/pages/af-use-case-mcp-bridge.adoc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 47885808..51e0365f 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -1,8 +1,6 @@ = Make APIs Agent-Ready with MCP Bridge -Agent Fabric's MCP Bridge converts your existing API instances into MCP servers through configuration, exposing their operations as MCP tools that agents can discover and call without modifying the underlying API. -Choose which operations to expose and apply optional read-only filtering to limit what agents can do, giving you control over agent access without rewriting anything. -Use this approach to make your existing Mule or API management investment immediately available to agents, with governance policies applied from the same portfolio. +Agent Fabric's MCP Bridge transforms your existing API instances into agent-ready tools without touching code. Choose which operations to expose, apply read-only filtering where needed, and make your Mule or API management investment immediately available to agents with the same governance policies you already use. == The Problem From de86eb387e48c2cde3dc7e352fc9e8952719f0d3 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Wed, 15 Jul 2026 16:48:12 -0700 Subject: [PATCH 03/10] Reorg --- .../ROOT/pages/af-use-case-mcp-bridge.adoc | 82 +++++++++---------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 51e0365f..d6d9d133 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -23,47 +23,7 @@ Agent Fabric's Model Context Protocol (MCP) Bridge enables safe, efficient API i * **Optional read-only filtering**: Limits agent access to read-only operations when needed, without modifying the underlying API. * **Centralized management**: Provides a single point of control for API access, with governance policies applied from the same portfolio. * **Agent-facing abstraction**: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. -* **Existing tool compatibility**: Integrates with Mule and other API management platforms without rebuilding existing assets. - -== Who This Is For - -MCP Bridge is ideal for: - -* **Organizations with existing API infrastructure** (especially Mule users) -* **Security teams** who are concerned about agent access to sensitive operations -* **Integration teams** looking to enable agents quickly without custom development -* **Architects** who are designing safe agent access to enterprise systems -* **Teams** who want to leverage existing investments in API management - -== Selecting Operations to Expose as Tools - -MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. Expose all operations, a subset, or apply optional read-only filtering — without modifying the underlying API. - -=== Full API (All Operations Available) - -[source,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) ----- - -=== Configured Tool Surface (Read Operations Only) - -When you configure MCP Bridge to expose only read operations, agents see a reduced tool surface drawn from the same Customer API. - -[source,text] ----- -Customer API (Agent Tool Surface): -- GET /customers/{id} (read - exposed as tool) -- GET /customers/{id}/orders (read - exposed as 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 are not exposed as MCP tools. +* **Existing tool compatibility**: Integrates with MuleSoft and other API management platforms without rebuilding existing assets. == How MCP Bridge Works @@ -80,6 +40,16 @@ Each agent request follows this path: . The call reaches the backend API. . Responses flow back through the bridge to the agent. +== Who This Is For + +MCP Bridge is ideal for: + +* Organizations with existing API infrastructure +* Security teams who are concerned about agent access to sensitive operations +* Integration teams looking to enable agents quickly without custom development +* Architects who are designing safe agent access to enterprise systems +* Teams who want to leverage existing investments in API management and governance + == Example Scenarios === Scenario 1: Customer Service Agent with Read-Only Access @@ -148,6 +118,36 @@ Each agent request follows this path: *Result:* Extend existing Mule investment to agentic use cases. +== Selecting Operations to Expose as Tools + +MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. Expose all operations, a subset, or apply optional read-only filtering, without modifying the underlying API. + +=== Example: Limiting Agent Access to Read Operations + +Consider a Customer API with both read and write operations: + +[source,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 MCP Bridge to expose only read operations, agents see a reduced tool surface: + +[source,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. + == Implementation Steps === Step 1: Identify APIs for Agent Access From 4681bd0ac508cfaf8afa0daa2d02debbaf463624 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Thu, 16 Jul 2026 11:16:16 -0700 Subject: [PATCH 04/10] Adding use case overview --- modules/ROOT/nav.adoc | 2 + .../ROOT/pages/agent-fabric-use-cases.adoc | 104 ++++++++++++++++++ 2 files changed, 106 insertions(+) create mode 100644 modules/ROOT/pages/agent-fabric-use-cases.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 96f9abae..12e42ca0 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -32,6 +32,8 @@ * xref:learning-map-mulesoft-ai.adoc[] * xref:agent-fabric-overview.adoc[Agent Fabric] ** xref:learning-map-agent-fabric.adoc[Get Started with Agent Fabric] + ** xref:agent-fabric-use-cases.adoc[] + *** xref:af-use-case-mcp-bridge.adoc[] ** xref:agent-fabric-release-notes.adoc[] ** xref:agent-networks-get-started.adoc[] * xref:learning-map-api-management.adoc[API Management] diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc new file mode 100644 index 00000000..7d9cb0e1 --- /dev/null +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -0,0 +1,104 @@ += Agent Fabric Use Cases + +Agent Fabric helps you design and orchestrate a network of agents, brokers, and MCP servers across your enterprise. Use Agent Fabric to manage agents across multiple platforms, enforce consistent policies, control costs, and build workflows. + +Solve common challenges when you deploy agentic systems at scale. + +== Find your use case + +[cols="1,2,1"] +|=== +|If you want to... |Use Case |Go to + +|Catalog and manage agents across multiple platforms +|Registry and Visibility +|xref:use-case-registry.adoc[Registry and Visibility] + +|Apply consistent business rules and guardrails across all agents +|Policy Enforcement +|xref:use-case-policy-enforcement.adoc[Policy Enforcement] + +|Control token usage and optimize model selection +|Cost Control and Semantic Routing +|xref:use-case-cost-control.adoc[Cost Control] + +|Move agents from proof-of-concept to production with proper identity management +|Identity and Production Readiness +|xref:use-case-identity.adoc[Identity and Production Readiness] + +|Build complex, deterministic workflows with error handling +|Workflow Orchestration +|xref:use-case-orchestration.adoc[Workflow Orchestration] + +|Make existing APIs agent-ready without modifying code +|MCP Bridge +|xref:af-use-case-mcp-bridge.adoc[MCP Bridge] +|=== + + +== Registry and Visibility + +If you have multiplatform agent deployments, use a centralized way to discover, catalog, and manage your agent estate. Know what exists and where before you apply governance. + +*Best for:* BPOs, holding companies, large system integrators, and enterprises with agents across multiple platforms + +xref:use-case-registry.adoc[Learn more →] + +== Policy Enforcement + +Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies once through a gateway rather than reimplementing them for each platform. + +*Best for:* Enterprises that require uniform compliance, security, and governance across different agent environments + +xref:use-case-policy-enforcement.adoc[Learn more →] + +== Cost Control and Semantic Routing + +Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. + +*Best for:* Organizations that manage large-scale agent deployments with budget constraints and efficiency requirements + +xref:use-case-cost-control.adoc[Learn more →] + +== Identity and Production Readiness + +Move from proof-of-concept to production by implementing proper identity verification and data scoping. Make sure agents operate in user context, not system context. + +*Best for:* Teams that are ready to move from POC to production deployments with proper access controls + +xref:use-case-identity.adoc[Learn more →] + +== Workflow Orchestration + +Build multi-step workflows with deterministic outcomes. Handle complex business logic, error scenarios, and unhappy paths that simple agent loops cannot address. + +*Best for:* Advanced use cases that require reliable, predictable multi-agent workflows + +xref:use-case-orchestration.adoc[Learn more →] + +== MCP Bridge + +Transform your existing API instances into agent-ready tools without touching code. Choose which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. + +*Best for:* Organizations with existing API infrastructure (like Mule) that want to enable agentic access safely + +xref:use-case-mcp-bridge.adoc[Learn more →] + +== Get started + +New to Agent Fabric? Start with the learning map to understand the fundamentals: + +* https://help.mulesoft.com/s/article/Get-Started-with-Agent-Fabric[Get Started with Agent Fabric] +* Watch a video to learn about Agent Fabric. +* Watch an interactive demo of Agent Fabric. + +After you understand the basics, return to this guide to implement your use cases. + +== See also + +* xref:use-case-cost-control.adoc[] +* xref:use-case-identity.adoc[] +* xref:use-case-mcp-bridge.adoc[] +* xref:use-case-orchestration.adoc[] +* xref:use-case-policy-enforcement.adoc[] +* xref:use-case-registry.adoc[] From fbb42a06a2f42be1e1490005640b4e3527fccbe3 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Thu, 16 Jul 2026 11:37:30 -0700 Subject: [PATCH 05/10] Human edits --- .../ROOT/pages/agent-fabric-use-cases.adoc | 68 ++++++++----------- 1 file changed, 27 insertions(+), 41 deletions(-) diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc index 7d9cb0e1..4179958d 100644 --- a/modules/ROOT/pages/agent-fabric-use-cases.adoc +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -1,18 +1,20 @@ = Agent Fabric Use Cases -Agent Fabric helps you design and orchestrate a network of agents, brokers, and MCP servers across your enterprise. Use Agent Fabric to manage agents across multiple platforms, enforce consistent policies, control costs, and build workflows. +Use Agent Fabric to design and orchestrate a network of agents, brokers, and MCP servers. Manage agents across multiple platforms, enforce consistent policies, control costs, and build workflows. -Solve common challenges when you deploy agentic systems at scale. - -== Find your use case +== Find Your Use Case [cols="1,2,1"] |=== -|If you want to... |Use Case |Go to +|If you want to... |Use case |Go to |Catalog and manage agents across multiple platforms |Registry and Visibility -|xref:use-case-registry.adoc[Registry and Visibility] +|xref:use-case-registry.adoc[] + +|Make existing APIs agent-ready without modifying code +|MCP Bridge +|xref:af-use-case-mcp-bridge.adoc[] |Apply consistent business rules and guardrails across all agents |Policy Enforcement @@ -22,79 +24,63 @@ Solve common challenges when you deploy agentic systems at scale. |Cost Control and Semantic Routing |xref:use-case-cost-control.adoc[Cost Control] -|Move agents from proof-of-concept to production with proper identity management -|Identity and Production Readiness -|xref:use-case-identity.adoc[Identity and Production Readiness] - |Build complex, deterministic workflows with error handling |Workflow Orchestration |xref:use-case-orchestration.adoc[Workflow Orchestration] -|Make existing APIs agent-ready without modifying code -|MCP Bridge -|xref:af-use-case-mcp-bridge.adoc[MCP Bridge] |=== - == Registry and Visibility If you have multiplatform agent deployments, use a centralized way to discover, catalog, and manage your agent estate. Know what exists and where before you apply governance. -*Best for:* BPOs, holding companies, large system integrators, and enterprises with agents across multiple platforms +*Best for:* BPOs, holding companies, large system integrators, and enterprises with agents across multiple platforms. -xref:use-case-registry.adoc[Learn more →] +xref:use-case-registry.adoc[Registry and Visibility] -== Policy Enforcement +== MCP Bridge -Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies once through a gateway rather than reimplementing them for each platform. +Transform your existing API instances into agent-ready tools without modifying code. Select which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. -*Best for:* Enterprises that require uniform compliance, security, and governance across different agent environments +*Best for:* Organizations with existing API infrastructure (like Mule) that want to enable agentic access safely. -xref:use-case-policy-enforcement.adoc[Learn more →] +xref:af-use-case-mcp-bridge.adoc[] -== Cost Control and Semantic Routing +== Policy Enforcement -Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. +Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies one time through a gateway rather than reimplementing them for each platform. -*Best for:* Organizations that manage large-scale agent deployments with budget constraints and efficiency requirements +*Best for:* Enterprises that require uniform compliance, security, and governance across different agent environments. -xref:use-case-cost-control.adoc[Learn more →] +xref:use-case-policy-enforcement.adoc[Policy Enforcement] -== Identity and Production Readiness +== Cost Control and Semantic Routing -Move from proof-of-concept to production by implementing proper identity verification and data scoping. Make sure agents operate in user context, not system context. +Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. -*Best for:* Teams that are ready to move from POC to production deployments with proper access controls +*Best for:* Organizations that manage large-scale agent deployments with budget constraints and efficiency requirements. -xref:use-case-identity.adoc[Learn more →] +xref:use-case-cost-control.adoc[Cost Control] == Workflow Orchestration Build multi-step workflows with deterministic outcomes. Handle complex business logic, error scenarios, and unhappy paths that simple agent loops cannot address. -*Best for:* Advanced use cases that require reliable, predictable multi-agent workflows - -xref:use-case-orchestration.adoc[Learn more →] - -== MCP Bridge +*Best for:* Advanced use cases that require reliable, predictable multi-agent workflows. -Transform your existing API instances into agent-ready tools without touching code. Choose which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. +xref:use-case-orchestration.adoc[Workflow Orchestration] -*Best for:* Organizations with existing API infrastructure (like Mule) that want to enable agentic access safely -xref:use-case-mcp-bridge.adoc[Learn more →] -== Get started +== Get Started New to Agent Fabric? Start with the learning map to understand the fundamentals: * https://help.mulesoft.com/s/article/Get-Started-with-Agent-Fabric[Get Started with Agent Fabric] -* Watch a video to learn about Agent Fabric. -* Watch an interactive demo of Agent Fabric. -After you understand the basics, return to this guide to implement your use cases. +After you understand the basics, choose a use case to implement. -== See also +== See Also * xref:use-case-cost-control.adoc[] * xref:use-case-identity.adoc[] From eb8e5437775fa5b109015e965ebed76d2f5f96c6 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Thu, 16 Jul 2026 15:21:10 -0700 Subject: [PATCH 06/10] Human in the loop edits --- .../ROOT/pages/af-use-case-mcp-bridge.adoc | 206 +++++++++--------- 1 file changed, 97 insertions(+), 109 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index d6d9d133..3ffec166 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -1,6 +1,14 @@ = Make APIs Agent-Ready with MCP Bridge -Agent Fabric's MCP Bridge transforms your existing API instances into agent-ready tools without touching code. Choose which operations to expose, apply read-only filtering where needed, and make your Mule or API management investment immediately available to agents with the same governance policies you already use. +Agent Fabric's MCP Bridge transforms your existing API instances into agent-ready tools without touching code. Choose which operations to expose as tools, limit agents to read operations where needed, and make your Mule or API management investment immediately available to agents with the same governance policies you already use. + +Key benefits of MCP Bridge include: + +* **Rapid enablement**: Gets agents connected to APIs quickly, without custom development. +* **Security by default**: Exposes only the operations you explicitly map as tools. +* **Consistency**: Gives all agents access to APIs through the same controlled interface. +* **Leverage existing investments**: Works with APIs managed through Anypoint Platform. +* **Centralized governance**: Provides a single point of control for agent API access. == The Problem @@ -20,32 +28,30 @@ Agent Fabric's Model Context Protocol (MCP) Bridge enables safe, efficient API i * **Rapid integration**: Connects existing API instances to agents through simple configuration, with no rewriting required. * **Selective exposure**: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. -* **Optional read-only filtering**: Limits agent access to read-only operations when needed, without modifying the underlying API. +* **Selective operation mapping**: Map only the operations you choose as tools. Limit agent access to read-only operations when needed, without modifying the underlying API. * **Centralized management**: Provides a single point of control for API access, with governance policies applied from the same portfolio. * **Agent-facing abstraction**: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. -* **Existing tool compatibility**: Integrates with MuleSoft and other API management platforms without rebuilding existing assets. +* **Leverage existing assets**: Works with your existing MuleSoft API infrastructure without rebuilding assets. == How MCP Bridge Works -[source,text] ----- -Agent → MCP Bridge → Tool Selection Layer → Backend API ----- +MCP Bridge operates at the Omni Gateway layer as a set of automated policies. You configure it through API Manager, and it deploys to the same gateway infrastructure you already use to manage API traffic. Each agent request follows this path: -. The AI agent makes a request using the Model Context Protocol. -. MCP Bridge receives the request and maps it to the underlying API. +. The AI agent makes a request using MCP. +. The request flows through Omni Gateway, where MCP Bridge policies execute. +. MCP Bridge maps the request to the underlying API operation. . Only operations you exposed as MCP tools are reachable. . The call reaches the backend API. -. Responses flow back through the bridge to the agent. +. Responses flow back through the gateway to the agent. == Who This Is For MCP Bridge is ideal for: * Organizations with existing API infrastructure -* Security teams who are concerned about agent access to sensitive operations +* Security teams concerned about agent access to sensitive operations * Integration teams looking to enable agents quickly without custom development * Architects who are designing safe agent access to enterprise systems * Teams who want to leverage existing investments in API management and governance @@ -54,106 +60,62 @@ MCP Bridge is ideal for: === Scenario 1: Customer Service Agent with Read-Only Access -*Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. - -*Without MCP Bridge:* +*Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. Without MCP Bridge, you would need to build custom integrations for each agent platform. This risks exposure of write operations and creates inconsistent behavior across platforms. -* Custom integration for each agent platform -* Risk of exposing write operations -* Inconsistent behavior across agent platforms +With MCP Bridge you get rapid deployment with built-in safety: -*With MCP Bridge:* - -. Configure MCP Bridge to connect to the customer API instance -. Select only GET operations to expose as MCP tools -. Give agents safe, read-only access -. Serve all agent platforms from a single MCP server - -*Result:* Rapid deployment with built-in safety. +. In API Manager, create an MCP Bridge instance for your customer API. +. Map only GET operations to MCP tools. +. Deploy the instance (policies execute on Omni Gateway). +. Connect all agent platforms to the MCP server endpoint. === Scenario 2: Inventory Check Agent -*Challenge:* Multiple agents across different applications need to check inventory levels but can't adjust inventory. - -*Without MCP Bridge:* +*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 need to check current stock, but only warehouse systems should adjust it. -* Separate inventory API integration for each agent -* Risk of accidentally exposing inventory write operations -* Inconsistent data access patterns +Without MCP Bridge, you would either expose the full API (risking accidental adjustments) or build filtered endpoints for each agent type. -*With MCP Bridge:* +With MCP Bridge you give all agents read-only inventory access from a single configuration: -. Create an MCP server from the inventory API instance -. Select only inventory query operations to expose as tools -. Connect all agents to the same configured tool surface -. Monitor all agent access centrally - -*Result:* Consistent, safe inventory access across all agents. +. In API Manager, create an MCP Bridge instance from the inventory API. +. Map only GET operations for stock queries to MCP tools. +. Connect all agent types to the MCP server endpoint. +. Monitor agent usage in the enhanced MuleSoft experience. === Scenario 3: Financial Data Agent with Layered Tool Selection -*Challenge:* Different agents need different levels of access to financial APIs. +*Challenge:* Different agents need different levels of access to financial APIs. -*Solution with MCP Bridge:* +Without MCP Bridge, you would need to build separate custom integrations for each agent access level, creating duplication and increasing the risk that a high-privilege operation gets exposed to the wrong agent. -. Create multiple MCP servers from the financial API, each with a different tool selection: - * **Basic server**: Read-only tools for account balances - * **Analytics server**: Read-only tools for transaction history and reports - * **Approval server**: Read-only tools, plus a tool to create approval requests (but no direct change operations) -. Connect agents to the appropriate MCP server based on their access needs -. Apply governance policies from the same portfolio +With MCP Bridge you get fine-grained access control with safety guarantees: -*Result:* Fine-grained access control with safety guarantees. +. In API Manager, create multiple MCP Bridge instances from your financial API, each with different operation mappings: + * **Basic server**: Map only GET operations for account balances. + * **Analytics server**: Map GET operations for transaction history and reports. + * **Approval server**: Map GET operations plus POST for creating approval requests. +. Connect each agent to the appropriate MCP server endpoint based on access requirements. +. In API Manager, apply policies to each MCP server instance. === Scenario 4: Mule Integration Platform -*Challenge:* Organization has extensive Mule infrastructure and wants to enable agentic access without rebuilding integrations. - -*Solution:* +*Challenge:* Your organization has extensive Mule infrastructure and wants to enable agentic access without rebuilding integrations. -. Deploy MCP Bridge for key Mule APIs. -. Use Mule's existing API management capabilities. -. Select which Mule API operations to expose as tools for agent access. -. Use existing monitoring and governance. +Without MCP Bridge, you would need to build agent-specific adapters on top of each Mule API, duplicating logic and bypassing existing Anypoint Platform governance. -*Result:* Extend existing Mule investment to agentic use cases. +With MCP Bridge you extend your existing Mule investment to agentic use cases: -== Selecting Operations to Expose as Tools - -MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. Expose all operations, a subset, or apply optional read-only filtering, without modifying the underlying API. - -=== Example: Limiting Agent Access to Read Operations - -Consider a Customer API with both read and write operations: - -[source,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 MCP Bridge to expose only read operations, agents see a reduced tool surface: - -[source,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. +. In API Manager, create MCP Bridge instances for key Mule APIs. +. Map the API operations you want to expose to MCP tools. +. Deploy the instances (policies execute on your existing Omni Gateway infrastructure). +. Monitor through the enhanced MuleSoft experience and apply policies in API Manager. == Implementation Steps === Step 1: Identify APIs for Agent Access . List APIs that agents access. -. Document current operations (GET, POST, PUT, DELETE). +. Document the current API operations (GET, POST, PUT, DELETE). . Identify which operations are safe for agents. . Prioritize APIs by business value and risk. @@ -168,13 +130,17 @@ For each API instance, decide: === Step 3: Deploy MCP Bridge -. Configure MCP Bridge for your target API instances. -. Select which operations to expose as MCP tools and apply optional read-only filtering. -. Test with sample requests. +. In API Manager, create an MCP Bridge instance for your target API. +. Configure downstream settings (base path, protocol, port) and upstream settings (route label, upstream URL). +. Map specific API operations to MCP tools by selecting the HTTP method and resource for each tool. +. Define tool names, descriptions, and input schemas for each mapped operation. +. Test the MCP server endpoint with sample requests. + +For more information, see xref:api-manager::create-instance-task-mcp-bridge.adoc[]. === Step 4: Apply Omni Gateway Policies -MCP Bridge controls which API operations are available as tools. Omni Gateway controls how agents are allowed to use them at runtime. After deploying MCP Bridge, apply Omni Gateway policies to the resulting MCP server to enforce authentication, rate limiting, audit logging, and alerting. +MCP Bridge controls which API operations are available as tools. Omni Gateway policies control how agents are allowed to use them at runtime. After deploying MCP Bridge, apply policies in API Manager to the MCP server instance to enforce authentication, rate limiting, audit logging, and alerting. See xref:use-case-policy-enforcement.adoc[Policy Enforcement] for implementation steps. @@ -187,23 +153,45 @@ See xref:use-case-policy-enforcement.adoc[Policy Enforcement] for implementation === Step 6: Monitor and Refine -. Identify any operations that were not exposed but that agents need. -. Watch for attempts to call unexposed operations. -. Refine your tool selection based on real usage. +. In the enhanced MuleSoft experience, review latency, error rates, and request volume for your MCP server. +. Analyze which tools agents are calling and identify missing operations. +. Check gateway logs for attempts to call unexposed operations. +. If you need to change tool mappings, create a new MCP Bridge instance with the updated configuration in API Manager. MCP Bridge instances are immutable after deployment. -== Key Benefits +For information about monitoring MCP servers and other services, see xref:exp-services-monitoring.adoc[]. -* **Rapid enablement**: Gets agents connected to APIs quickly, without custom development. -* **Security by default**: Exposes only the operations agents use, with optional read-only filtering. -* **Consistency**: Gives all agents access to APIs through the same controlled interface. -* **Leverage existing investments**: Works with Mule and other API platforms. -* **Centralized governance**: Provides a single point of control for agent API access. == Tool Selection Strategies -=== Read-Only Filtering +MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. During configuration, you map specific operations (HTTP method and resource) to 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: + +[source,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 MCP Bridge to expose only read operations, agents see a reduced tool surface: + +[source,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 -Start by exposing only GET/read operations as tools. Explicitly add write operations only when a use case requires them. +Start by mapping only GET/read operations to tools. Explicitly map write operations only when a use case requires them. === Operation Allowlisting @@ -219,7 +207,7 @@ For runtime controls such as rate limiting and time-based access restrictions, s === Read-Only Tool Surface -Use this pattern when agents only retrieve data. Expose all GET/read operations as tools; exclude all write operations. +Use this pattern when agents only retrieve data. Expose all GET/read operations as tools and exclude all write (POST, PUT, DELETE) operations. [source,text] ---- @@ -232,7 +220,7 @@ Use this pattern when agents only retrieve data. Expose all GET/read operations === Read and Create Tool Surface -Use this pattern when agents look up records and create new ones but do not modify or delete existing data. +Use this pattern when agents look up records and create new ones but don't modify or delete existing data. [source,text] ---- @@ -256,7 +244,7 @@ Use this pattern when agents initiate a workflow (for example, submitting an app === Granular Tool Surface -Use this pattern for fine-grained control — exposing specific safe operations and blocking others based on individual business risk assessments. +Use this pattern for fine-grained control, exposing specific safe operations and blocking others based on individual business risk assessments. For example, expose GET /orders/{id} to allow agents to view order details, but block PUT /orders/{id}/status to prevent agents from changing order status. This gives agents access to the information they need while protecting sensitive operations. [source,text] ---- @@ -272,7 +260,7 @@ Use this pattern for fine-grained control — exposing specific safe operations Start with no access and explicitly enable only what agents use. -Omni Gateway provides audit logging and anomaly monitoring for the resulting MCP server. See xref:use-case-policy-enforcement.adoc[Policy Enforcement]. +Apply Omni Gateway policies to enable audit logging and monitor MCP server usage through Anypoint Monitoring. See xref:use-case-policy-enforcement.adoc[Policy Enforcement]. === Regular Reviews @@ -293,13 +281,13 @@ MCP Bridge works directly with Mule APIs managed in Anypoint Platform, so you ca * Extend Mule monitoring to agent access. * Reuse existing API policies. -=== API Gateways +=== Omni Gateway Integration -MCP Bridge can run alongside existing API gateways. Omni Gateway policies apply to the resulting MCP server in the same way they apply to other agent traffic. +MCP Bridge runs on Omni Gateway infrastructure. MCP server instances are managed through API Manager and protected by Omni Gateway policies, just like API instances. -* Deploy MCP Bridge alongside existing gateways. -* Coordinate policies between gateway and bridge. -* Use unified monitoring and alerting across gateways and MCP servers. +* Deploy MCP Bridge instances 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 From 6e5c51f29749cc01317c969de0485915667f57fa Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Fri, 17 Jul 2026 11:38:45 -0700 Subject: [PATCH 07/10] Adding short descriptions to sections --- modules/ROOT/pages/af-use-case-mcp-bridge.adoc | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 3ffec166..fb5de7b0 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -58,6 +58,8 @@ MCP Bridge is ideal for: == Example Scenarios +These scenarios demonstrate how different organizations use MCP Bridge to solve specific agent access challenges. + === Scenario 1: Customer Service Agent with Read-Only Access *Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. Without MCP Bridge, you would need to build custom integrations for each agent platform. This risks exposure of write operations and creates inconsistent behavior across platforms. @@ -112,6 +114,8 @@ With MCP Bridge you extend your existing Mule investment to agentic use cases: == Implementation Steps +Follow these steps to deploy MCP Bridge and make your APIs available to agents. + === Step 1: Identify APIs for Agent Access . List APIs that agents access. @@ -128,7 +132,7 @@ For each API instance, decide: * If agents require write access, which specific write operations do they use? * What Omni Gateway policies apply to the resulting MCP server? -=== Step 3: Deploy MCP Bridge +=== Step 3: Create and Deploy MCP Bridge Instance . In API Manager, create an MCP Bridge instance for your target API. . Configure downstream settings (base path, protocol, port) and upstream settings (route label, upstream URL). @@ -205,6 +209,8 @@ For runtime controls such as rate limiting and time-based access restrictions, s == Common Tool Selection Patterns +These patterns represent typical approaches to selecting which operations to expose as tools based on your security requirements and use cases. + === Read-Only Tool Surface Use this pattern when agents only retrieve data. Expose all GET/read operations as tools and exclude all write (POST, PUT, DELETE) operations. @@ -256,6 +262,8 @@ Use this pattern for fine-grained control, exposing specific safe operations and == Security Considerations +When deploying MCP Bridge, follow security best practices to minimize risk and maintain control over agent access to your APIs. + === Default Deny Start with no access and explicitly enable only what agents use. @@ -272,6 +280,8 @@ Periodically review: == Integration with Existing Tools +MCP Bridge integrates with your existing MuleSoft infrastructure, identity systems, and gateway deployment to leverage investments you have already made. + === Mule Integration MCP Bridge works directly with Mule APIs managed in Anypoint Platform, so you can expose existing Mule API instances as MCP servers without rebuilding them. @@ -285,7 +295,7 @@ MCP Bridge works directly with Mule APIs managed in Anypoint Platform, so you ca MCP Bridge runs on Omni Gateway infrastructure. MCP server instances are managed through API Manager and protected by Omni Gateway policies, just like API instances. -* Deploy MCP Bridge instances on the same Omni Gateway that manages your APIs. +* Create and deploy MCP Bridge instances 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. From 9cde3846967f0975e2a4469bfc5f485b60c3e194 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Mon, 20 Jul 2026 12:16:17 -0700 Subject: [PATCH 08/10] wording tweak --- modules/ROOT/pages/af-use-case-mcp-bridge.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index fb5de7b0..6aad626d 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -114,7 +114,7 @@ With MCP Bridge you extend your existing Mule investment to agentic use cases: == Implementation Steps -Follow these steps to deploy MCP Bridge and make your APIs available to agents. +Follow these steps to create MCP Bridge instances and make your APIs available to agents. === Step 1: Identify APIs for Agent Access From c63d279c876ecd2571652b6cd2ff5670bb17fe01 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Tue, 21 Jul 2026 14:08:58 -0700 Subject: [PATCH 09/10] Adding content --- .../ROOT/pages/agent-fabric-use-cases.adoc | 48 ++++++++----------- 1 file changed, 19 insertions(+), 29 deletions(-) diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc index 4179958d..f61ded5d 100644 --- a/modules/ROOT/pages/agent-fabric-use-cases.adoc +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -1,6 +1,6 @@ = Agent Fabric Use Cases -Use Agent Fabric to design and orchestrate a network of agents, brokers, and MCP servers. Manage agents across multiple platforms, enforce consistent policies, control costs, and build workflows. +Agent Fabric addresses the most common challenges in enterprise AI agent management, from discovering and governing agents across platforms, to making existing APIs agent-ready without custom development, and keeping token costs under control. Each use case maps a specific business problem to a set of Agent Fabric capabilities so you can identify where to start and build incrementally. Use the quick-reference table to match your immediate goal to the right capability. == Find Your Use Case @@ -9,66 +9,56 @@ Use Agent Fabric to design and orchestrate a network of agents, brokers, and MCP |If you want to... |Use case |Go to |Catalog and manage agents across multiple platforms -|Registry and Visibility +|Discover and register agents from a centralized catalog. Know what exists and where before you apply governance. |xref:use-case-registry.adoc[] |Make existing APIs agent-ready without modifying code -|MCP Bridge +|Select which API operations to expose as MCP tools, apply read-only filtering, and control agent access to your APIs. |xref:af-use-case-mcp-bridge.adoc[] |Apply consistent business rules and guardrails across all agents -|Policy Enforcement +|Enforce PII policies, rate limits, and compliance rules across all agents through a single gateway rather than reimplementing them per platform. |xref:use-case-policy-enforcement.adoc[Policy Enforcement] |Control token usage and optimize model selection -|Cost Control and Semantic Routing +|Monitor token usage across agents and applications, then route queries to cost-effective models based on complexity. |xref:use-case-cost-control.adoc[Cost Control] |Build complex, deterministic workflows with error handling -|Workflow Orchestration -|xref:use-case-orchestration.adoc[Workflow Orchestration] +|Handle multi-step business logic, error scenarios, and unhappy paths that simple agent loops can't reliably address. +|xref:use-case-orchestration.adoc[Agentic Orchestration] |=== -== Registry and Visibility +== Discover and Govern Agents Across Your Organization -If you have multiplatform agent deployments, use a centralized way to discover, catalog, and manage your agent estate. Know what exists and where before you apply governance. +Use a centralized registry and automated scanners to discover, catalog, and manage agents across your organization. Know what exists and where before you apply governance. For example, a business process outsourcer managing agents across multiple client platforms, or an enterprise security team asked to audit every agent in production, can use Registry and Scanners to get a complete, current picture without manually tracking deployments. -*Best for:* BPOs, holding companies, large system integrators, and enterprises with agents across multiple platforms. +xref:use-case-registry.adoc[Centralizing Agent Discovery with Agent Registry and Scanners] -xref:use-case-registry.adoc[Registry and Visibility] +== Make APIs Agent-Ready with MCP Bridge -== MCP Bridge - -Transform your existing API instances into agent-ready tools without modifying code. Select which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. - -*Best for:* Organizations with existing API infrastructure (like Mule) that want to enable agentic access safely. +Transform your existing API instances into agent-ready tools without modifying code. Select which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. For example, an organization with hundreds of existing Mule APIs can make them callable by agents in minutes through configuration alone, without touching the underlying implementations. xref:af-use-case-mcp-bridge.adoc[] -== Policy Enforcement - -Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies one time through a gateway rather than reimplementing them for each platform. +== Enforce Consistent Policies Across Agent Platforms -*Best for:* Enterprises that require uniform compliance, security, and governance across different agent environments. +Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies one time through a gateway rather than reimplementing them for each platform. For example, a regulated industry deploying agents across Agentforce, Bedrock, and custom Mule implementations can enforce the same data privacy and rate limiting rules everywhere through a single Omni Gateway policy. xref:use-case-policy-enforcement.adoc[Policy Enforcement] -== Cost Control and Semantic Routing +== Monitor Costs and Optimizing Model Selection -Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. - -*Best for:* Organizations that manage large-scale agent deployments with budget constraints and efficiency requirements. +Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. For example, a team running hundreds of daily agent interactions can route routine lookups to a smaller, cheaper model and reserve a frontier model only for tasks that require complex reasoning. xref:use-case-cost-control.adoc[Cost Control] -== Workflow Orchestration - -Build multi-step workflows with deterministic outcomes. Handle complex business logic, error scenarios, and unhappy paths that simple agent loops cannot address. +== Coordinate Multi-Agent Processes with Brokers -*Best for:* Advanced use cases that require reliable, predictable multi-agent workflows. +Use agent brokers and agent networks to coordinate task delegation across A2A-compliant agents with guided determinism. Define broker routing logic in Agent Script to handle complex business processes, error scenarios, and unhappy paths that require multiple specialized agents working in sequence. For example, an order management process that involves a research agent, a pricing agent, and an approval agent can be wired together in a single agent network with a broker that routes each step to the right specialist. -xref:use-case-orchestration.adoc[Workflow Orchestration] +xref:use-case-orchestration.adoc[Agent Orchestration] From bfdc418579934e0dd9e72ee117477f96d4d24739 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Tue, 21 Jul 2026 17:30:14 -0700 Subject: [PATCH 10/10] Removed excessive bold --- .../ROOT/pages/af-use-case-mcp-bridge.adoc | 38 +++++++++---------- .../ROOT/pages/agent-fabric-use-cases.adoc | 2 +- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 6aad626d..2004b453 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -4,21 +4,21 @@ Agent Fabric's MCP Bridge transforms your existing API instances into agent-read Key benefits of MCP Bridge include: -* **Rapid enablement**: Gets agents connected to APIs quickly, without custom development. -* **Security by default**: Exposes only the operations you explicitly map as tools. -* **Consistency**: Gives all agents access to APIs through the same controlled interface. -* **Leverage existing investments**: Works with APIs managed through Anypoint Platform. -* **Centralized governance**: Provides a single point of control for agent API access. +* Rapid enablement: Gets agents connected to APIs quickly, without custom development. +* Security by default: Exposes only the operations you explicitly map as tools. +* Consistency: Gives all agents access to APIs through the same controlled interface. +* Leverage existing investments: Works with APIs managed through Anypoint Platform. +* Centralized governance: Provides a single point of control for agent API access. == The Problem You have invested heavily in API infrastructure, but adapting these APIs for agentic use is challenging: -* **API complexity**: Existing APIs weren'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. +* API complexity: Existing APIs weren'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. Bridge your existing API infrastructure to agents safely and efficiently with MCP Bridge. @@ -26,12 +26,12 @@ Bridge your existing API infrastructure to agents safely and efficiently with MC Agent Fabric's Model Context Protocol (MCP) Bridge enables safe, efficient API integration for agents: -* **Rapid integration**: Connects existing API instances to agents through simple configuration, with no rewriting required. -* **Selective exposure**: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. -* **Selective operation mapping**: Map only the operations you choose as tools. Limit agent access to read-only operations when needed, without modifying the underlying API. -* **Centralized management**: Provides a single point of control for API access, with governance policies applied from the same portfolio. -* **Agent-facing abstraction**: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. -* **Leverage existing assets**: Works with your existing MuleSoft API infrastructure without rebuilding assets. +* Rapid integration: Connects existing API instances to agents through simple configuration, with no rewriting required. +* Selective exposure: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. +* Selective operation mapping: Map only the operations you choose as tools. Limit agent access to read-only operations when needed, without modifying the underlying API. +* Centralized management: Provides a single point of control for API access, with governance policies applied from the same portfolio. +* Agent-facing abstraction: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. +* Leverage existing assets: Works with your existing MuleSoft API infrastructure without rebuilding assets. == How MCP Bridge Works @@ -93,9 +93,9 @@ Without MCP Bridge, you would need to build separate custom integrations for eac With MCP Bridge you get fine-grained access control with safety guarantees: . In API Manager, create multiple MCP Bridge instances from your financial API, each with different operation mappings: - * **Basic server**: Map only GET operations for account balances. - * **Analytics server**: Map GET operations for transaction history and reports. - * **Approval server**: Map GET operations plus POST for creating approval requests. + * Basic server: Map only GET operations for account balances. + * Analytics server: Map GET operations for transaction history and reports. + * Approval server: Map GET operations plus POST for creating approval requests. . Connect each agent to the appropriate MCP server endpoint based on access requirements. . In API Manager, apply policies to each MCP server instance. diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc index f61ded5d..ca0bbd9c 100644 --- a/modules/ROOT/pages/agent-fabric-use-cases.adoc +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -74,7 +74,7 @@ After you understand the basics, choose a use case to implement. * xref:use-case-cost-control.adoc[] * xref:use-case-identity.adoc[] -* xref:use-case-mcp-bridge.adoc[] +* xref:af-use-case-mcp-bridge.adoc[] * xref:use-case-orchestration.adoc[] * xref:use-case-policy-enforcement.adoc[] * xref:use-case-registry.adoc[]