Turn Any Existing API into an AI-Ready MCP Server Without Writing Code

Most teams assume that letting an AI agent call their existing APIs means rewriting an entire server layer, or manually wrapping an adapter around every endpoint — and then maintaining two codebases forever. In a demo, Roby from La Rebellion Labs proves that's not the only path: your existing production-grade API, plus an OpenAPI contract and a single command, can become an MCP server directly.

The more important question comes next: when an enterprise has 23 services and 276 operations, how do you get the model to orchestrate cross-service flows without guessing? The answer is hiding in the contract itself.

The Core Idea: The Contract Is the Tool Definition

The demo starts with an ordinary OpenAPI 3.1 contract — an Orders API with four operations: list orders, read a single order, track shipment, and cancel order. There's nothing AI-related in the contract.

After running the serve command with the dry-run flag, the four operations automatically become four tools. Read-only operations are flagged as read-only; the cancel operation is flagged as destructive — these safety hints come directly from the HTTP method itself. Roby notes that the system can even estimate the context overhead: roughly 250 tokens. No server code is generated, no network call is made — the contract is simply previewed as a tool list.

The real value of this dry-run mechanism is that it lets developers see, before anything goes live, the exact tool definitions an AI client will receive — including input schemas (derived from path parameters) and safety hints (derived from HTTP methods).

MCP (Model Context Protocol) is a protocol proposed and open-sourced by Anthropic in late 2024, designed to standardize how AI models communicate with external tools and data sources. Before MCP, every new tool integration typically required writing client-specific adapter code for each AI client (Claude, IDE plugins, custom agent frameworks), producing an N×M integration explosion. MCP solves this with a unified server–client model: tool providers only need to expose one protocol-compliant endpoint declaring each tool's name, input schema, and invocation method, and any compatible client can discover and call it automatically. The MCP servers Hoppy generates in this article follow this protocol, so desktop assistants, IDE agents, and custom frameworks can all connect the same way — no per-client adaptation needed.

Headless Mode: Zero-Intrusion Integration with Existing Backends

When actually launched, Headless mode places an MCP endpoint in front of the existing backend. Business logic stays where it is; tool calls are forwarded to the existing API — authentication, validation, and monitoring all continue to work.

Querying that server from another terminal returns standard MCP responses. Any MCP client — desktop assistant, IDE agent, custom agent framework — can connect to that URL.

According to the demo on the YouTube channel La Rebellion Labs, all of this is driven by a command-line tool called Hoppy.

OpenAPI (formerly Swagger) is the industry-standard specification for describing RESTful APIs. The widely used 3.0/3.1 versions declare each endpoint's path, HTTP method, parameters, request body, response structure, and security scheme in YAML or JSON. It's both human-readable documentation and a machine-parseable contract — code generators, testing tools, gateways, and documentation sites all depend on it. The key insight here is that an OpenAPI contract already contains most of what's needed to build AI tools: path parameters map to tool input schemas, and HTTP methods (GET read-only, DELETE destructive) map to safety hints. So there's no need to write a separate "AI description" — translating the contract itself into MCP tool definitions achieves a single source of truth that never drifts.

Cross-Service Workflows: Replacing Model Guesswork with Contracts

The real enterprise pain point is API fragmentation: payments belong to one team, logistics to another, each deployed and maintained independently. Each API can become its own MCP server, but customers don't think in service boundaries. A customer says, "Charge me and ship it."

If you only expose raw tools, the model has to figure out the call order across three systems, pass data from one response into the next request, and hope nothing goes wrong each time. That uncertainty is a breeding ground for hallucination.

Arazo (a standard from the OpenAPI Initiative) is used to describe cross-API workflows. The Arazo 1.1 file in the demo references three contracts directly, without copying or modifying them. The fulfillOrder workflow sequentially reads the order, initiates payment using the total amount from the first step's response, and creates a shipment. The data flow between steps is declarative, not coded.

When the same serve command recognizes the Arazo document, it exposes each workflow as an MCP tool. The AI only needs to call fulfillOrder with an order ID, and Hoppy executes three steps across three independent services in order and returns the shipping information. The orchestration logic lives in a reviewed contract, not in the model's improvisation.

The Point of Single-Step Workflows

The second workflow in the demo has only one step. Why wrap a single call in a workflow? Because it lets you name things by business scenario instead of by endpoint. "Where's my order?" is the question customers actually ask. That workflow takes exactly the input that scenario needs, calls one operation, and returns only status and arrival date.

This way, you can narrow a complex domain down to a small, focused MCP — instead of exposing every endpoint of every service, you publish just the few business capabilities that actually matter, each tailored to a specific scenario.

Arazo is a standard under development at the OpenAPI Initiative for declaratively describing workflows that span multiple APIs. Traditionally, making an AI "charge and ship" required either writing orchestration code or relying on the model to infer the call order — the former is expensive to maintain, the latter error-prone. Arazo's approach: reference operations from multiple OpenAPI contracts directly in a workflow document, and describe the data flow between steps declaratively (e.g., "use the amount from step one's response as step two's payment amount") without copying or modifying the referenced contracts. This makes orchestration logic a reviewable, versionable first-class citizen, and the model only needs to call one high-level workflow tool, with the actual steps executed by the runtime per the contract.

Capability Graph: Letting the Model Ask Before It Acts

The most illuminating part of the demo is a simulated wholesale back office with 23 services and 276 operations. 23 of those operations are named "release" — release order, release inventory, release billing hold. Hand all of them to a model and the user has burned roughly 16,000 tokens before even speaking; then the model still has to guess which "release" they meant and what preconditions it needs to satisfy to call it.

"The model isn't broken. It's missing context your business has but the contract never wrote down."

Hoppy's Capability Graph fills in that knowledge at the contract level. Add a few optional extensions to the Orders API:

• capability: place the operation in a business taxonomy
• intent: tell the model when to use it and when to avoid it
• effects: declare that cancel is destructive and requires confirmation
• planning facts: declare preconditions (verified customer, identified order) and new facts after the operation
• client facts: declare that identity verification is performed by a support agent, not produced by the API
• outcome: declare what a 409 response means

This metadata doesn't change the API itself — it's reviewed and versioned alongside the contract.

Auditing and the Planner

Before the model ever touches anything, an audit mechanism verifies the completeness of the vocabulary: every required fact must either be produced by some operation or declared as client-verified; every goal must actually be reachable. In CI, gaps block the build like failing tests.

In a simulated cancel operation, with no verified customer, the planner refuses to invent a path and instead declares "needs clarification." After verifying the customer, it produces a deterministic two-step plan: identify the order, cancel the order. The plan still stops at two gates — confirmation and the destructive-operation check — because the contract says so. The planner never calls the API; it only decides what's safe to do next.

What the Model Actually Experiences

With two extra flags on the same server, three assistive tools appear. When the user says "cancel my order," the model calls capability context and gets the relevant tools, goals, preconditions, and which facts need to be obtained from the user. Identity is marked as client-established, so the model knows to ask rather than assume.

Then the model requests a plan. The plan lists two steps, the confirmation it needs to collect, and what happens otherwise. If the order has already shipped, the 409 tells the model cancellation is impossible, so it replans instead of retrying. The same applies to search behavior — "where's my package" finds track order; "cancel order" finds cancel order.

"The model didn't get smarter. It got better informed by your contract."

Workflows get the same treatment. After adding planning facts to fulfillOrder, Hoppy checks them against the three operations it calls. In the first draft, the workflow forgot that a step requires a verified customer and omitted two produced facts. Strict mode fails the check, so the error can't reach production. Once the steps declare their true requirements and outputs, the check passes. Cross-service workflows now have the same guarantees as single endpoints.

Planning facts and client facts are a complementary pair of metadata in the Capability Graph extension. Planning facts describe an operation's preconditions (e.g., "requires a verified customer") and the new facts it produces (e.g., "order cancelled"), letting the planner determine whether a goal is reachable in the current state. Client facts flag information that can't be produced by the API itself and must be confirmed by a client or human (e.g., identity verification done by a support agent). Together, they let the planner check for gaps against the contract without calling the API: if some required fact is neither produced by an operation nor declared as client-verified, the audit fails. This is the mechanism that moves the model from "guessing" to "asking."

What Zero Code Really Means

Throughout the entire process, no adapters, handlers, or prompt templates were created. Every tool traces back to a line in the contract, reviewable, versionable, diffable. Nothing runs in the shadows — if a tool exists, the contract declares it; if behavior changes, a pull request changed it.

That's the standard production-grade APIs deserve, and the standard AI integration should meet.

Roby's suggested first step is pragmatic: run a dry-run on your own contract and look at the tool list; then pick the operation users are most likely to misuse and give it an intent. That's the first step toward an AI-Ready API — one that still belongs to you.

One-line Summary

Use an OpenAPI contract and a single command to turn any existing API into an AI-ready MCP server, zero code required.

Paragraph Summary

This article covers a method demoed by Roby at La Rebellion Labs: with the Hoppy CLI, a single OpenAPI contract and one serve command turn an existing production API into an MCP server — no rewriting, no backend changes, with authentication and monitoring fully preserved. Dry-run previews tool definitions and context overhead, while Headless mode places an MCP endpoint in front of the existing backend. For cross-service orchestration, the Arazo standard replaces model improvisation with declarative workflows; Capability Graph adds business context via capability, intent, planning facts, and more, so the model asks before acting — with knowledge gaps auditable in CI.