From REST API to MCP Server in 10 Minutes

If you have a REST API, you have 90% of an MCP server. This is the thing nobody tells you.

Your endpoints are your tools. Your request schemas are your input schemas. Your response shapes are your output types. The mapping is almost embarrassingly direct.

POST /users/create? That's a create_user tool. GET /orders/:id? That's get_order. The parameter types, the validation rules, the error shapes — you've already written all of it. Probably twice, if you count the OpenAPI spec.

The only thing missing is the translation layer. And — this is the part that will trip you up — good descriptions. Not "description: creates a user." Descriptions that an LLM can actually reason about. That distinction matters more than you think.

MCP tools map almost 1:1 to REST endpoints. This isn't an accident. Both are fundamentally answering the same question: what can this service do, and how do I ask it to do things?

The schema translations are mechanical. JSON Schema in, JSON Schema out. Required fields stay required. Enums stay enums. Nested objects stay nested. If you squint, an MCP tool definition looks like an OpenAPI operation with better ergonomics.

You could automate the conversion. We did automate it. The structural mapping is a solved problem. You don't need to think about it.

What you do need to think about is everything the structure doesn't capture. The implicit contracts. The ordering dependencies. The "don't call this endpoint before calling that one" knowledge that lives in your team's heads and nowhere else. That's the real translation work.

Here's where most migrations fail. And it's not where you'd expect.

You copy the endpoint names, generate schemas from your OpenAPI spec, and ship it. Everything looks great. The tool definitions are clean. The types are correct. You feel productive.

Then the LLM calls create_user when it should call update_user. Why? Because both descriptions say "manages user data." You wrote them for a developer who would read the URL path and understand the difference. An LLM doesn't read URL paths. It reads descriptions.

Your descriptions need to be unambiguous, specific, and written for a reader who has never seen your system and never will. "Creates a new user account with the provided email and password. Returns the created user object with a generated ID. Fails if the email is already registered." That's a description an LLM can work with.

This is the actual hard work of the migration. Not the plumbing — the naming.

So here's the shortcut. Point SmeltSec at your OpenAPI spec or GitHub repo. That's it. That's the starting point.

It reads your endpoints, infers the intent from your route structure and existing documentation, generates MCP tools with proper schemas, and writes descriptions that LLMs can actually parse. Then it runs security scanning to catch tool poisoning vectors and overly permissive input schemas.

The 10 minutes in the title is generous. Most repos take under 60 seconds. The bottleneck isn't generation — it's you reviewing the output and deciding if the descriptions accurately capture what each tool does.

You could do all of this by hand. You'd spend a weekend on it. You'd get the schemas right and the descriptions wrong, because writing good descriptions is a skill most backend engineers have never needed to develop. This is the kind of boring, critical work that tooling should handle.

The surprising thing about converting to MCP isn't the conversion. It's what happens after.

Your API suddenly has new consumers you didn't expect. AI agents start calling your tools in ways you never tested. They compose your tools with other tools from completely unrelated services — a calendar tool calls your payment tool calls a notification tool, all orchestrated by an LLM that figured out the workflow on its own.

You're no longer building an API. You're contributing to an ecosystem. Your tools become building blocks in systems you didn't design and can't predict.

This is uncomfortable if you're used to controlling the entire integration surface. It's exhilarating if you realize what it means: your service just became useful in ways you couldn't have imagined, to users you'll never meet, solving problems you didn't know existed.

That's the real reason to make the switch. Not because MCP is newer or trendier. Because it makes your work matter to a much larger world.