The API-to-MCP Pipeline Becomes a Platform Play

The race to wire every existing API into the AI agent ecosystem is no longer a side project. It is a platform land grab.

Microsoft published documentation on April 30 showing how Azure API Management customers can expose any managed REST API as a Model Context Protocol server. Tyk Technologies shipped an open-source tool on GitHub that does the same thing from the command line: point it at an OpenAPI spec, and it generates an MCP server that AI assistants like Claude Desktop and Cursor can call directly. Dozens of smaller tools on Product Hunt and npm offer variations on the same pattern.

The technical work is trivial. The strategic implications are not.

MCP, the protocol Anthropic open-sourced in late 2024, defines how AI models discover and call external tools. An MCP server exposes a list of tools, each with a name, description, and parameter schema. An MCP client — Claude Desktop, VS Code with GitHub Copilot, Cursor — connects to the server and lets the model decide which tools to invoke. The protocol has become the de facto standard for connecting frontier models to live data and actions.

The problem MCP solves is real. Before MCP, every AI integration required custom glue code: a function call wrapper, an API key handshake, a rate-limiting layer, a retry mechanism. MCP standardizes the contract. But the protocol alone does nothing for the thousands of legacy REST APIs that were never designed for AI consumption. Each one needs an MCP wrapper.

That is where the platform play begins.

Microsoft’s approach is the most telling. Azure API Management already sits in front of enterprise APIs, handling authentication, rate limiting, transformation, and logging. By adding MCP export as a built-in feature, Microsoft turns its existing API gateway into an AI gateway. A customer clicks a button, selects which API operations to expose as tools, and the gateway handles the rest — including policies that trace the agent ID making each call. The MCP server is not a separate service. It is a configuration toggle on infrastructure the customer already pays for.

Tyk’s open-source tool takes the opposite route. It is a standalone Node.js process that reads an OpenAPI spec and starts an MCP server on the local machine. It supports overlays, whitelist filtering, custom headers, and multiple authentication schemes. The tool is agnostic about where the API lives. It works with any spec, any backend, any AI client. Tyk, an API management company, is effectively giving away the MCP adapter and betting that customers will pay for the management layer around it.

Both approaches reveal the same truth: the MCP adapter itself is a commodity. The value is in what surrounds it.

For Microsoft, that means the existing API Management install base. Every enterprise already running Azure API Management can enable MCP with zero new infrastructure. The stickiness is the gateway — once an organization routes its AI tool calls through Azure, Microsoft sees every agent interaction, every API call pattern, every authentication attempt. That data feeds Azure AI Foundry, Azure Monitor, and Microsoft’s broader AI platform strategy.

For Tyk, the bet is that enterprises will want more control than a single cloud gateway provides. The open-source tool can run locally, in a CI/CD pipeline, or alongside a self-hosted API gateway. Tyk’s commercial product adds governance, analytics, and policy enforcement across multiple MCP servers. The company is positioning itself as the control plane for a heterogeneous AI tool ecosystem.

Neither approach is wrong. Both are racing to establish the default path from API to agent.

The numbers suggest the market is real. Azure API Management serves tens of thousands of enterprise customers. Tyk’s GitHub repository for the MCP tool shows active development and a growing contributor base. The Product Hunt listing for “API to MCP” — a generic name that dozens of tools share — consistently trends in the developer tools category. The pattern is not experimental. It is being deployed.

What is missing is standardization at the governance layer. MCP defines how a client talks to a server. It does not define how an organization manages dozens or hundreds of MCP servers, each exposing different APIs to different AI assistants with different access controls. That is the problem the platform vendors are racing to solve.

Consider the enterprise scenario. A company has 200 internal APIs. Each one needs an MCP server. Some APIs should be available to every employee using Claude Desktop. Others should only be callable by the finance team using a custom agent. Some tools should log every invocation. Others should enforce rate limits per user. MCP does not address any of this natively. The gateway does.

Microsoft’s policy engine in Azure API Management already supports rate limiting by IP address, custom headers for agent identification, and subscription keys for access control. Tyk’s commercial product adds similar capabilities. The platform vendors are not competing on the MCP adapter. They are competing on the management plane that sits above it.

The open question is whether the management plane will be a single cloud gateway or a distributed control layer. Microsoft’s bet is that enterprises will consolidate on Azure. Tyk’s bet is that enterprises will want to run MCP servers across multiple clouds and on-premises environments. Both could be right for different segments.

For AI builders, the takeaway is straightforward. The API-to-MCP conversion is solved. The bottleneck is no longer technical. It is organizational: who manages the gateways, who sets the policies, who audits the agent calls. The platform that answers those questions first will own the enterprise AI integration market.

Microsoft published its MCP documentation on April 30. Tyk’s tool has been on GitHub since early 2025. The race is close. But the finish line is not the MCP adapter. It is the gateway that sits behind it.