Your API Is Already a Hidden MCP Server, You Just Need to Discover It

What began as an internal hackathon project, where a small team at Infobip set out to create and launch a marketing campaign for a fictional chocolate brand using AI agents, evolved into the company’s first MCP servers running in production.

At Devoxx UK, Filip Srnec, Principal Engineer at Infobip and lead of the company’s MCP team, explained how they built the OpenAPI MCP Spring Boot Starter, a tool that turns any OpenAPI-documented API into a fully capable MCP server, without the need for rewrites or custom integration code.

Why not just build custom MCP servers?

Filip kicked off his talk by asking the audience if anyone had an HDMI adapter so he could point out a common challenge in technology:

Protocols evolve, and systems don’t necessarily upgrade in sync.

Most of the systems AI agents need to interact with today already expose REST APIs. REST APIs helped us build the world that we now today. Mobile apps, smart devices, command-line tools, and interactive user interfaces all rely on them, running on top of decades of standards, tooling, and shared knowledge. Now AI agents need a way to use that same infrastructure.

MCP, announced by Anthropic in November 2024, was positioned as “a USB-C port for AI applications.” That immediately raised the question of whether every existing API (the HDMI cable) would now need custom glue code (an adapter) to become agent-accessible.

Infobip’s answer was no.

The OpenAPI connection

The breakthrough came when the team compared the structure of an MCP tool with an OpenAPI operation. The two map directly onto each other at the field level. MCP tools define elements such as a name, title, description, input schema, and annotations, while OpenAPI operations include an operation ID, summary, description, parameters, and request body. Comparing the two side by side shows that most OpenAPI operation metadata already has a direct equivalent in MCP:

The name can be an operation ID, because operation ID uniquely identifies an operation in the specification. For a title, we can use a summary. Description is obvious. We have a way to define the input schema by combining parameters and the request body.

Infobip already had OpenAPI specifications for all of its public APIs. Since those specifications were powering the company’s API platform and SDK generation process, building a bridge to MCP made more sense than creating custom servers from scratch.

Let’s take a look at how the OpenAPI MCP Spring Boot Starter works in two phases.

How the framework works

The process begins by reading the OpenAPI specification and turning it into MCP-compatible tool definitions. Because the connection is dynamic, updates to the API are reflected on the MCP side as well.

At runtime, on every tool call, the framework validates credentials, maps tool arguments to HTTP requests, enriches and forwards those requests to the downstream API, handles errors, and returns the result to the agent.

The setup is intentionally minimalistic. It requires only the OpenAPI specification URL and the base URL of the API being exposed. As Filip explained:

You just point it at your OpenAPI specification, and your API instantly becomes an MCP server. This is something that we’ve been running in production for months now.

Not every endpoint should become a tool

Filip pointed out that exposing an entire API surface to agents is a bad idea. Irrelevant operations add noise, increase costs, and can mislead the model. A larger surface also extends the potential attack surface for prompt injection.

The framework tackles this through an OpenAPI filter chain. Before tools are exposed through MCP, developers can adjust the specification. That means removing endpoints, tweaking schemas, or changing how operations are presented. The good thing is that this approach works even when the API is maintained by someone else.

One example involved OpenAPI’s discriminator feature. It is commonly used to select different schemas based on a property value, making server-side validation more flexible. The catch is that discriminators are not valid JSON Schema constructs, while MCP tool definitions require strict JSON Schema compliance. To solve the problem, the framework automatically rewrites discriminator-based schemas into oneOf structures that MCP clients can consume without issue, Filip explained.

Unfortunately, exposing the right tools solves a part of the problem. For an AI agent to use a tool correctly it needs to understand both what the tool does and when to use it.

Naming, descriptions, and making agents actually use your tools

LLMs select tools based on names and descriptions and both matter more than most developers realize.

The framework gives developers several ways to name tools. They can keep the original operation ID, use a simplified version with special characters removed, or generate a name from the API endpoint itself when no operation ID is available. It also includes safeguards for clients that impose strict limits on name length.

Tool descriptions require just as much attention because every description from every connected MCP server is loaded into the model’s context. These descriptions need to be concise and easy for AI agents to interpret. The framework can enrich them with summaries and examples from the OpenAPI specification, which Filip highlighted as especially useful when matching requests to input schemas.

The tools, however, still need to work with existing authentication and authorization systems.

Solving authentication without reinventing it

Authentication has been one of the more debated aspects of MCP and because of that the framework takes a pragmatic approach by relying on existing mechanisms rather than new ones. Filip explained:

Your API already knows how to perform authentication and authorization. It knows how to reject bad credentials.

Instead of introducing a separate authentication layer, the framework forwards credentials to a configurable endpoint that already handles it. As a result, any method supported by the underlying API, whether API keys, basic authentication, or JWTs, works through the MCP server as well.

For OAuth, the framework proxies OpenID configuration calls and authorization requests to a configured OAuth server, and performs automatic scope discovery from the OpenAPI security definitions:

To have full OAuth support, you need to point it at your OAuth server. And you’ll get minimal scope discovery automatically directly from the framework.

It is important to mention that building the features was, once again, only part of the story. The team was also developing the framework while the MCP ecosystem itself was still taking shape.

Building on a moving train

Filip was candid about the challenges the team faced. As Infobip was building and shipping the framework, the MCP specification evolved, with changes affecting everything from transport mechanisms and authentication flows to client behavior:

Sometimes we need to pick between features and compatibility. We decided that we wanted to move fast. We wanted to be in that space. The spec was still being written while we were shipping production code.

Along the way, the team had to deal with a growing list of compatibility issues. Different clients imposed different limits on tool name lengths, some sent nested objects as escaped strings instead of valid JSON, and OAuth implementations often behaved differently despite following the same specification:

My point here is that sometimes you can’t wait for the ecosystem to mature. You ship and you adapt.

The demo

Filip wrapped up the session with a demonstration. Using the framework, he connected an OpenMeteo weather forecast server and Infobip’s production SMS MCP server, then showed how an AI agent could retrieve the next day’s weather forecast for London, generate a short summary, and send it as a text message. The point was how quickly an existing API could be turned into an MCP-compatible service. As Filip put it:

Your API may already be a hidden MCP server. Try to use this framework, point it at your specification, and ship it.

• Listen to Filip’s entire talk on YouTube
• The framework and examples are open source and available on GitHub.
• Infobip’s production MCP server is accessible at mcp.infobip.com.