Enabling Agent Interoperability: A Practical Path from API to MCP Server

[Yarloy_Wang]

The future of enterprise AI will be driven by the deep and seamless integration of LLMs into existing enterprise products and workflows. To stay competitive, companies must make their vast landscape of existing capabilities directly accessible and usable by AI, empowering a new generation of intelligent ecosystems. This requires a clear strategy for enabling agent interoperability.

In this article, we will establish that the journey to agent interoperability begins with a foundational pillar: enabling agents to reliably connect with tools (Agent-to-Tool). We'll start by defining the foundational challenge that prevents agents and tools from communicating effectively. We will then introduce the Model Context Protocol (MCP) as a standardized solution and walk through a step-by-step tutorial on how to transform a standard REST API into a fully compliant MCP Server using a cloud-native gateway.

What is Agent Interoperability and Why Does It Matter?

Agent Interoperability is a comprehensive framework for a complete AI ecosystem, which relies on two fundamental pillars: Agent-to-Agent (A2A) interaction and Agent-to-Tool (A2T) interaction.

While A2A interaction—how agents collaborate and delegate tasks—represents a sophisticated, multi-agent system's goal, A2T interaction is the foundational prerequisite. The ability of agents to collaborate is contingent upon their individual capacity to connect to tools.

Therefore, solving the Agent-to-Tool challenge is the most critical first step towards the broader goal of agent interoperability. While not an Agent-to-Agent protocol itself, solving the Agent-to-Tool challenge is the most critical first step towards the broader goal of agent interoperability: how to let any agent discover and use any external capability in a standardized way.

Foundational Challenge: Connecting Agents to Enterprise Tools

In an enterprise environment like SAP, this challenge presents distinct engineering considerations on both sides of the connection:

• On the agent side: The challenge is building agents with the autonomy to dynamically discover and utilize a diverse set of capabilities, moving beyond static tool integrations.
• On the capability side: The engineering task is to adapt SAP's vast landscape of powerful APIs for a new type of consumer: the autonomous AI agent. The goal is to create AI-consumable interfaces for these existing capabilities, which involves adding the necessary semantic context and standardized formats that agents require for dynamic interaction.

This difference in design paradigms creates a natural "Interoperability Gap”. Bridging this gap requires a foundational layer for communication: a standardized protocol that enables dynamic discovery and standardized interaction between agents and established enterprise APIs.

The Solution: MCP as a Standardized Protocol Bridge

So, how do we bridge this "Interoperability Gap"? The solution lies in a shared standard—a common language that both agents and tools can speak. This is where the Model Context Protocol (MCP)  comes in.

MCP is an open protocol that standardizes how applications provide context to large language models (LLMs). MCP provides a standardized way to connect AI models to different data sources and tools.

We use MCP to build agents and complex workflows on top of LLMs. The key participants in the MCP architecture are:

• MCP Host: The AI application that coordinates and manages one or multiple MCP clients
• MCP Client: A component that maintains a connection to an MCP server and obtains context from an MCP server for the MCP host to use
• MCP Server: A program that provides context to MCP clients

As for enterprise like SAP, the best practice will be:

However, a protocol is only useful if capabilities adopt it. The enterprise landscape is filled with valuable, pre-existing REST APIs that were not built for this new paradigm. Therefore, a critical first step toward achieving agent interoperability is to bridge these legacy APIs to the MCP standard.

The act of transforming a standard API into a discoverable MCP Server is the foundational process for unlocking existing enterprise value for AI agents. 

MCP Adoption Strategy in Enterprise Ecosystems

When adopting a new standard like MCP within a large enterprise ecosystem like SAP, there are typically two primary strategic paths to consider for implementation:

1. The Standard Path: Platform-Managed Solutions

For most common use cases, the standard approach is to leverage platform-integrated, centrally managed solutions. This path involves using automated services, often provided by the enterprise platform (e.g., SAP BTP), to convert existing APIs into standardized tools. By using unified method for transformation, this approach ensures consistency and manageability across the entire ecosystem.

2. The Flexible Path: Custom or "Native" Implementations

For scenario demanding greater flexibility or more complex business logic, a more custom approach is required. This involves building what can be considered "native" MCP servers. This approach allows teams to build custom implementations using a variety of technologies, such as open-source libraries or different programming languages, giving them full control over the implementation.

This Guide's Focus: A Hands-on Example of the Flexible Path

In the following guide, we will focus on the flexible, native server approach.  We will demonstrate a powerful and practical pattern for this by using a cloud-native gateway, Higress, to wrap an existing API. This method is ideal for teams who require full control over the transformation logic and deployment environment, providing a valuable, hands-on example of building a native-style MCP server.

Step-by-Step Guide: Transforming API into MCP Server

To see how this concept works in the real world, let's take a standard REST API and use a gateway to transform it into a fully-compliant MCP server.

Our Goal: Wrap a simple HTTP API as an MCP Server and invoke it from an agent.

Our Tools:

• A Simple API: A REST API that returns real-time currency exchange data.
• The Gateway: Higress, an open-source, cloud-native gateway with a powerful plugin architecture.
• The Standard: The Model Context Protocol (MCP), which we'll implement using the Higress MCP Plugin.
• The Environment: A Kubernetes environment.

 

A Modern Transport Protocol: Streamable HTTP

Before we begin, it's important to understand transport mechanisms for client-server communication we'll be using. This guide utilizes a modern and powerful approach defined by the MCP standard: Streamable HTTP.

We chose this approach for several key advantages that make it superior for modern AI systems:

• Simplified Architecture: In the Streamable HTTP transport, the server operates as an independent process that can handle multiple client connections. Because the session context is maintained within this single, stateful connection, the need for an external session manager like Redis is often eliminated.
• Bidirectional and Flexible Communication: The protocol handles simple request-response patterns efficiently but also enables true bidirectional communication. Server can optionally make use of Server-Sent Events (SSE) to stream multiple server messages. This permits basic MCP servers, as well as more feature-rich servers supporting streaming and server-to-client notifications and requests.

Step 1: The Starting Point - A Simple REST API

As the requirement of Streamable HTTP, The server MUST provide a single HTTP endpoint path (hereafter referred to as the MCP endpoint) that supports both POST and GET methods.

To demonstrate the transformation process, this guide will use the ExchangeRate-API, a professional service that provides real-time currency exchange data. We'll use its lasted endpoint, which returns up-to-date global rates based on the US Dollar.

• API Endpoint: https://open.er-api.com/v6/latest/USD

A successful request to this endpoint returns a JSON object with a structure similar to this, containing metadata and a nested rates object:

{
  "result": "success",
  "time_last_update_utc": "Mon, 15 Sep 2025 00:02:31 +0000",
  "base_code": "USD",
  "rates": {
    "USD": 1,
    "EUR": 0.925,
    "GBP": 0.789,
    ...
  }
}

This represents a typical "legacy" capability—useful, but not inherently agent-friendly. 

Step 2: Preparing the Gateway with Higress

Instead of modifying the API's code, we'll use a gateway to act as a transformation layer. Higress is an ideal choice because its plugin architecture is designed to extend gateway capabilities, including native support for AI scenarios through protocols like MCP.

2.1 Higress Deployment

First, install Higress into your cluster environment (To simplify, we use k3s as an example).

Check your console's node port:

kubectl get svc higress-console -n higress-system

Once the installation succeeds, you can access the Higress Console in browser by http://<your-cluster-external-ip>:<console-port>.  

 

2.2 Config MCP Server

Once deployed, we need to enable the MCP Server functionality globally by editing the higress-config ConfigMap.

kubectl edit configmap higress-config -n higress-system

In the ConfigMap data, we'll add the MCP Server configuration. 

apiVersion: v1
data:
  higress: |-
    mcpServer:
      sse_path_suffix: /sse  # Suffix for the Server-Sent Events connection path
      enable: true           # Enable the MCP Server
      servers: []
  downstream:
    # ... (rest of the config)

 

Step 3: Transforming the API with the MCP Plugin

3.1 Add a Service Source

In the Higress Console, navigate to Service Source page http://<your-cluster-external-ip>:<console-port>/service-source  and add a new source pointing to our API's address (https://open.er-api.com/v6/latest/USD).

 

3.2 Create a Route

Next, go to the Route page and create a new route.

• Click "Route Config" on the left sidebar
• Click "Create Route" button
• Fill in the form with the following details:
  • Route Name: exchange-rate-route
  • Path: Select Exact and enter /exchange-rates
  • Target Service: Select the service source you just created

This will create a route that matches the path /exchange-rates and forwards requests to the service source you created. Now you can see the new route in the list.

At this point, Higress will simply proxy requests from /exchange-rates to our API.

 

3. Configure the MCP Server Plugin

Click the Strategy link on your new route and find the MCP Server plugin.

After enabling the plugin, click "Configure" and switch to the YAML view. This is where we define the metadata that makes our API discoverable and understandable to agents.

Paste the following configuration:

server:
  name: "exchange-rate-server"
tools:
  - name: "get-latest-usd-rates"
    description: "Fetches the latest currency exchange rates based on the US Dollar."
    requestTemplate:
      method: "GET"
      url: "https://open.er-api.com/v6/latest/USD"
    responseTemplate:
      body: |-
        **Latest Exchange Rates (Base: {{.base_code}})**
        *Updated at: {{.time_last_update_utc}}*
        
        - **Euro (EUR):** {{.rates.EUR}}
        - **Japanese Yen (JPY):** {{.rates.JPY}}
        - **British Pound (GBP):** {{.rates.GBP}}
        - **Chinese Yuan (CNY):** {{.rates.CNY}}

Let's break this down:

• server.name: A human-readable name for our new MCP server.
• tools: A list of capabilities this server provides.
• name & description: The crucial metadata for agent to intelligently discover and select this tool when a user asks about exchange rates.
• requestTemplate & responseTemplate: These define how Higress calls the backend API and formats the response. Here, the requestTemplate specifies a simple GET request, and the responseTemplate transforms the JSON output into a clean, agent-friendly format.

Save the plugin configuration. Our standard REST API is now exposed as a fully functional and discoverable MCP Server, ready for any compliant AI agent to use.

Step 4: Connecting and Invoking from an Agent with Streamable HTTP

Now, any MCP-compliant agent or client can connect to our gateway and use this new tool. To test our new MCP server, we can use any compliant MCP Host app, such as Cline, Cursor, Trae, etc.

For this guide, we'll use Cline as example. It's an autonomous coding agent that can be installed as a VS Code extension. Configure Cline with the following setting to establish a connection to our new server:

{
  "mcpServers": {
    "exchange-rate-server": {
      "url": "http://<your-cluster-external-ip>/exchange-rates",
      "type": "streamableHttp"
    }
  }
}

Now you can test the server in Cline:

Wrapping Up

In this post, we've navigated a practical path toward the broader vision of agent interoperability. We established that the most critical first step is solving the Agent-to-Tool (A2T) challenge: making existing enterprise APIs discoverable and usable by AI agents. We then demonstrated a powerful pattern to achieve this, using a cloud-native gateway, Higress, to transform a standard REST API into a fully compliant MCP Server.

The most powerful takeaway is demonstrating a flexible path to a native server: You've learned how a gateway-centric pattern can be used to build a "native" MCP server, offering full control to teams that require flexibility and customization in their MCP adoption strategy. It means existing, valuable enterprise services can be rapidly integrated into the agent ecosystem, making them dynamically discoverable and usable by any MCP-compliant agent.

Solving the Agent-to-Tool problem building the foundation for agent interoperability. With a robust A2T layer in place, the path is cleared for more advanced Agent-to-Agent collaboration, paves the way for a future where countless enterprise services can be seamlessly integrated with agent ecosystem.