Turning any REST API into an MCP server
Most of an MCP server is mechanical translation from a schema you already have. Here is what generates cleanly and what still needs a human.
The 1,500 connectors get the attention, but the feature teams reach for on day one is usually the converter, because the API that matters most to them is the one only they have.
The mapping is mostly mechanical
An OpenAPI document already contains nearly everything an MCP tool definition needs:
| OpenAPI | MCP tool |
|---|---|
operationId | tool name |
summary + description | tool description |
| parameters + request body schema | input JSON Schema |
| response schema | output shape |
securitySchemes | auth binding |
Walk the paths, emit a tool per operation, and you have a working server. GraphQL maps similarly, with queries and mutations standing in for operations.
Where naive generation goes wrong
If you stop at the mechanical translation, you get a server that is technically correct and unpleasant to use.
Too many tools
A large API can have 400 operations. Emitting 400 tools produces a connector no agent can navigate. The fix is selection: generate everything, then expose the operations that represent real tasks and leave the rest addressable but unranked.
Descriptions written for humans
summary: Updates the resourceA model reading that learns nothing. Tool descriptions are prompt text: they are the entire basis on which the model decides whether to call this tool. They need to say what the operation does, when to use it, and what it affects.
Unbounded parameters
An endpoint that accepts a free-form filter string is a bug waiting to happen when the caller is a language model. Enums, ranges and required fields need to be tight, and additionalProperties: false is your friend.
Idempotency and blast radius
DELETE /v1/customers/{id} generates as cleanly as GET /v1/customers. They should not be equally reachable. Destructive operations deserve explicit opt-in, and ideally a confirmation step, before an autonomous caller can reach them.
What we generate, and what we ask you to review
The converter produces the full tool set from your schema, infers auth from securitySchemes, and flags three things for a human:
- 1Descriptions it judged too thin to be useful, with a suggested rewrite.
- 2Destructive operations: off by default, enabled deliberately.
- 3Loose parameter schemas: where narrowing a type would remove a whole class of bad call.
Ten minutes of review on a generated connector is the difference between an agent that uses your internal API correctly and one that uses it enthusiastically in the wrong direction.
Keep reading
The N×M problem is eating agent teams alive
Every agent needs tools; every tool needs an integration. The arithmetic gets ugly fast, and a gateway is the only shape that fixes it.
Stop putting API keys in your agents
Handing provider credentials to an autonomous process is a blast radius problem. Scoped, revocable, brokered access is the fix.
How tool discovery keeps 25,000 tools out of your context window
A catalog this size cannot be pasted into a prompt. Here is the retrieval layer that decides what an agent actually sees.