- Abstract
Enterprises are increasingly exploring how AI agents can interact with existing APIs. However, directly exposing backend services to AI systems can compromise governance, security, and architectural boundaries.
This paper presents a practical implementation demonstrating how IBM webMethods Integration Server and API Gateway can expose enterprise REST APIs as AI-discoverable tools using the Model Context Protocol (MCP). The solution reuses existing OpenAPI 3.x specifications and requires no changes to backend business services.
Using the WxMCPServer package on IBM webMethods Integration Server and Claude Desktop as the MCP client, we validate a governed execution flow from tool discovery to business API invocation while preserving API Gateway authentication, subscription control, and policy enforcement.
The implementation demonstrates that enterprise AI integration can be achieved using standard IBM webMethods components without bypassing established middleware controls. IBM webMethods remains the system of record for execution, while MCP provides a controlled enablement layer for AI-driven interactions. The approach described in this paper represents one possible architecture for integrating AI agents with enterprise APIs, and enterprises may adopt alternative deployment models depending on their security architecture, identity infrastructure, and governance requirements.
- Introduction
Enterprise organizations today manage a large portfolio of REST APIs that expose critical business capabilities such as customer management, subscriptions, service orders, billing operations, and more. These APIs are typically governed through middleware platforms such as IBM webMethods Integration Server and API Gateway, which enforce authentication, authorization, routing, throttling, and auditing.
At the same time, AI agents are emerging as a new class of consumers of enterprise systems. Unlike traditional applications, AI agents operate based on user intent. They dynamically decide which capabilities to invoke rather than following predefined orchestration flows.
This shift introduces an important architectural question: How can AI agents interact with enterprise APIs without bypassing established governance, security controls, and middleware boundaries?
Direct exposure of backend services to AI systems is not acceptable in enterprise environments. AI enablement must operate within the same governance model as any other consumer application.
The Model Context Protocol (MCP) provides a structured mechanism for exposing APIs as “tools” that AI agents can discover and invoke. When combined with IBM webMethods, MCP can act as a controlled abstraction layer enabling AI-driven interaction while preserving API Gateway enforcement and Integration Server execution ownership.
This paper presents a practical implementation that demonstrates how IBM webMethods can be positioned as a forward-looking AI integration platform, enabling governed AI interactions without modifying existing backend services.
In this emerging model, integration platforms no longer serve only as orchestration engines. They evolve into governed capability providers that enable AI systems to safely interact with enterprise services.
- AI-Driven API Interaction: Why It Matters Now
Enterprise APIs were originally designed for deterministic consumers like mobile applications, web portals, partner integrations, and batch systems. These consumers follow predefined flows and rely on explicitly coded orchestration.
AI agents introduce a different interaction model.
Instead of following a fixed process, AI agents interpret user intent and dynamically decide which capabilities to invoke.
For example, a single user request such as:
“Suspend this customer’s broadband service and raise a high-priority ticket.”
may result in multiple API invocations, selected at runtime.
This does not replace traditional orchestration engines. Instead, it introduces a new interaction layer where intent-based execution complements deterministic middleware flows.
For middleware platforms such as IBM webMethods, this shift presents both an opportunity and a responsibility:
- The opportunity to expose enterprise capabilities in a more discoverable and reusable manner.
- The responsibility to ensure that AI-driven execution remains governed, auditable, and secure.
AI enablement must not bypass API Gateway, modify backend services, or weaken existing authorization models. It must integrate with them.
The approach demonstrated in this paper shows how IBM webMethods can support this evolution, positioning middleware as the controlled capability backbone for AI-driven systems.
- Enterprise Proof of Concept – Implementing MCP on webMethods
To validate the architecture and concepts discussed in this article, we implemented a working Proof of Concept using IBM webMethods Integration Server, IBM webMethods API Gateway, and the WxMCPServer package.
The objective of this POC was to demonstrate how enterprise APIs can be exposed as AI-discoverable tools, allowing AI agents to dynamically discover and invoke business capabilities through the Model Context Protocol (MCP).
The implementation followed a layered architecture commonly used in enterprise integration platforms.
4.1 Enterprise Architecture
The POC architecture consists of four primary layers
- Business APIs implemented in IBM webMethods Integration Server
- API governance and security enforced by IBM webMethods API Gateway
- MCP capability exposure through the WxMCPServer package
- AI interaction through an MCP client (Claude Desktop)
The MCP Server acts as a translation layer that exposes enterprise APIs as AI-consumable tools.
4.2 Enterprise Business APIs on Integration Server
To simulate a telecom service environment, multiple REST APIs were implemented on Integration Server representing common telecom capabilities such as:
- Customer Account Management
- Subscription Management
- Service Orders
- Trouble Tickets
- Reference Data
Each capability was implemented as a stateless REST resource backed by webMethods Flow services, encapsulating validation and business logic.
Fig 1 – Business API’s implemented on IBM webMethods Integration Server
4.3 API Governance Using webMethods API Gateway
All APIs were onboarded into IBM webMethods API Gateway, which acts as the single governed entry point for enterprise APIs.
The Gateway provides:
- OAuth token validation
- Scope-based authorization
- API access governance
- Centralized API monitoring and policy enforcement
This ensures that AI-driven access to enterprise APIs follows the same governance and security model used for traditional enterprise integrations.
Fig 2 – API’s published and secured through IBM weMethods API Gateway
4.4 MCP Server Deployment
The WxMCPServer package was deployed on Integration Server to expose enterprise APIs as MCP tools.
The MCP server exposes a standard endpoint that enables AI agents to:
- Discover available tools
- Understand tool schemas
- Invoke business capabilities dynamically
The MCP server performs protocol mediation between MCP JSON-RPC requests and REST API invocations, while relying on API Gateway for authentication and authorization.
Fig 3 – WxMCPServer package deployed on IBM webMethods Integration Server
Fig 4 – MCP endpoint exposed through Integration Server URL Alias
4.5 AI Client Interaction
To validate the end-to-end integration, Claude Desktop was configured as an MCP client.
The client connects to the MCP server using a configuration file that specifies the following details:
- MCP server endpoint
- Authentication details
- Tool discovery configuration
Once connected, the AI client was able to dynamically discover enterprise capabilities exposed through the MCP server.
The available tools presented to the AI client are determined by the authorization scopes contained in the OAuth token. This ensures that AI agents only see and invoke capabilities they are permitted to access.
Fig 6 – MCP tool discovery with Write Authorization Scope
This demonstrates how scope-based authorization governs which enterprise capabilities are exposed to AI agents through MCP.
4.6 Security Model Used in the POC
The POC implements a hybrid authentication model combining API Key validation with OAuth-based authorization.
When an MCP client attempts to access the MCP endpoint, the request is routed through IBM webMethods API Gateway, which validates the API key and enforces OAuth-based scope authorization.
The OAuth token carries scopes derived from the user’s role or authorization policy, which determine which APIs are accessible. These scopes are then propagated to the business APIs, ensuring consistent authorization across the platform.
This model ensures that AI-driven API access follows the same enterprise security and governance policies as traditional integrations.
- End-to-End Execution Flow
The architecture described in the previous sections comes together during runtime when an AI client interacts with enterprise capabilities through MCP. The following diagram illustrates the end-to-end execution flow for invoking enterprise APIs using IBM webMethods and the Model Context Protocol.
When the AI client interprets a user request, it discovers the available enterprise capabilities exposed as MCP tools. Once the appropriate tool is selected, the MCP server translates the MCP JSON-RPC invocation into a REST API request and routes it through IBM webMethods API Gateway.
The API Gateway acts as the governance boundary, validating the API key, verifying the OAuth access token, and enforcing scope-based authorization before forwarding the request to IBM webMethods Integration Server. Integration Server then executes the corresponding Flow services and invokes the underlying enterprise business capabilities.
After execution, the response flows back through the same governed path from Integration Server to API Gateway and the MCP server, before being returned to the AI client.
This approach enables AI agents to dynamically invoke enterprise capabilities while preserving the existing governance, security, and integration controls provided by the enterprise middleware platform.
Fig 7 – End-to-end execution flow for AI-Driven API invocation
- Architectural Principles Behind the Design
This Proof of Concept was not built as a feature demonstration. It was designed around a set of architectural principles intended to preserve enterprise governance while enabling AI-driven interaction.
6.1 Middleware Remains the Execution Backbone
Business logic continues to reside in IBM webMethods Integration Server. AI does not execute business processes directly. It invokes governed capabilities exposed through the middleware layer. This preserves existing investment and operational controls.
6.2 API Gateway as the Security Boundary
All authentication and authorization enforcement occurs at IBM webMethods API Gateway. In this implementation, the MCP Server does not validate tokens or apply security policy. It mediates the MCP protocol and routes requests, while all authentication and authorization enforcement is handled by IBM webMethods API Gateway. This ensures that AI access does not bypass existing enterprise security controls.
6.3 Authorization-Aligned Tool Discovery
Tool visibility is derived from authorization policy. Operations are exposed only if permitted by OAuth scopes. Discovery and execution are aligned, eliminating situations where a tool is visible but not executable.
6.4 No Backend Modification
Existing business APIs were reused without modification. No AI-specific logic was introduced into backend services. The integration layer absorbs protocol translation and tool mediation responsibilities.
6.5 User-Context Propagation
The OAuth access token is propagated end-to-end. Business APIs execute under the same user authorization context that governs tool discovery. This prevents privilege escalation and preserves audit integrity.
6.6 Deterministic Capability Exposure
Tools represent atomic business capabilities, not workflows. Orchestration decisions remain external to the middleware layer, allowing AI agents to compose capabilities dynamically while keeping execution deterministic.
- Security and Governance Model
AI enablement in enterprise environments cannot be treated as an experimental extension. It must operate within established governance, identity, and policy frameworks.
The model implemented in this Proof of Concept reinforces that principle.
7.1 Centralized Enforcement at API Gateway
IBM webMethods API Gateway remains the single security boundary. All inbound MCP traffic is subject to:
- API Key validation at the application level
- OAuth token validation at the user level
- Scope-based operation authorization
- Standard Gateway policies such as rate limiting and auditing
The MCP Server does not introduce a parallel security model. It operates strictly behind Gateway enforcement.
7.2 Scope-Propagating Authorization
Authorization is enforced consistently across both discovery and execution.
The OAuth token acquired by the MCP client contains scopes derived from the user’s role. Those scopes determine:
- Which operations are exposed as tools
- Which operations are executable
- Which backend APIs can be invoked
There is no privilege translation, service account substitution, or internal credential mapping. The same user authorization context is preserved throughout the interaction.
This prevents privilege amplification and maintains audit traceability.
7.3 Operation-Level Governance
Governance is not applied only at API level. Individual operations are filtered based on scopes.
This enables:
- Partial exposure of APIs
- Role-based capability restriction
- Fine-grained control over AI-driven execution
Tool visibility is therefore governed, not inferred.
7.4 Isolation Through Scope-Sensitive Caching
Tool definitions are cached in a manner that incorporates scope context.
This prevents:
- Cross-role leakage
- Unauthorized tool reuse
- Incorrect capability exposure
Caching respects authorization boundaries.
7.5 Alignment with Zero-Trust Principles
Every request is validated at the Gateway layer. No implicit trust is assumed between MCP Server and backend services.
Security is enforced at the perimeter, not delegated to internal components.
The outcome is a model where AI-driven interactions are not treated as exceptions to enterprise governance. Instead, they are integrated into the existing identity and authorization fabric of the organization.
- What This Means for Enterprise Integration
The emergence of the Model Context Protocol introduces a new way for enterprise systems to expose capabilities to AI-driven applications.
Traditionally, middleware platforms orchestrated service interactions through predefined workflows. With AI agents entering enterprise environments, the interaction model is evolving toward dynamic capability discovery and invocation.
Instead of building rigid orchestration layers, enterprises can expose well-governed APIs as capabilities that AI systems can discover and use at runtime.
Integration platforms such as IBM webMethods are well positioned for this shift. Their strengths in API management, governance, security, and service orchestration make them a natural foundation for building AI-ready integration architectures.\
The POC described in this article demonstrates how existing enterprise APIs can be safely exposed to AI agents through MCP while continuing to enforce enterprise-grade governance through API gateways and authorization models.
As AI agents become more capable, integration platforms will increasingly act as capability providers, enabling AI systems to interact with enterprise services in a controlled and secure manner.
- Conclusion
This paper presented a practical implementation demonstrating how enterprise APIs implemented on IBM webMethods Integration Server can be exposed as AI-discoverable tools using the Model Context Protocol (MCP), while maintaining governance through IBM webMethods API Gateway.
The Proof of Concept validated that AI agents can dynamically discover and invoke enterprise capabilities without bypassing established middleware controls, authentication mechanisms, or authorization policies.
This approach allows organizations to leverage their existing integration investments while preparing their platforms for the emerging AI-driven interaction model.
As AI adoption accelerates, enterprise integration platforms will play an increasingly important role in exposing enterprise capabilities as secure, governed services that can be safely consumed by intelligent agents.
If you have any queries or of you’d like a demo and possibly help doing your own solution, do get in touch with us on our page Rootware Technologies or on our website.