// API_GENERATION
How to Expose a REST API as MCP Tools
Turning a REST API into governed MCP tools: OpenAPI import or manual endpoint definition, one typed tool per endpoint, and vault-injected auth headers the model never sees.
By MakeYourMCP Team · Published Jul 17, 2026 · Updated Jul 17, 2026
Exposing a REST API as MCP tools means turning each endpoint into one typed, independently governed MCP tool — either by importing an OpenAPI specification or by defining endpoints manually when no spec exists. Either path produces the same shape of result: no hand-written wrapper, no per-endpoint auth plumbing, and no single tool with more reach than any one caller should have.
OpenAPI import: one tool per endpoint
When an API publishes an OpenAPI (Swagger) specification, importing it generates one MCP tool per documented endpoint, with each tool's parameters typed and validated against the spec's schema. A POST /orders/{id}/refund endpoint becomes its own tool with its own parameter contract — not a generic "call this API" tool that happens to accept a path and a body. That per-endpoint typing is what makes the rest of the governance model possible: a policy engine can allow or deny a specific endpoint's tool, and validated parameters mean a malformed or out-of-range value gets rejected before it reaches the upstream API at all.
Manual endpoint definition, when there's no spec
Plenty of internal or older APIs don't publish an OpenAPI spec. For those, manual endpoint definition covers the same ground by hand: method, path, parameters, and where the auth token comes from. The resulting tool is functionally identical to one generated from a spec — same typed parameters, same governance, same registration flow — the only difference is who wrote the endpoint definition, a spec parser or a person filling in the same fields.
Vault-injected auth headers
The API credential — an API key, a bearer token, whatever the upstream requires — is stored in the credential vault, not in the tool definition and not anywhere the model's context could reach it. When a tool call actually executes, the auth header is injected into the outbound request server-side, after the model has already decided to call the tool but before the request leaves the gateway. The model never sees the token, never has to be told it, and can't leak what it was never given — which closes off an entire category of prompt injection attempts that try to get an agent to reveal or misuse a credential it's holding.
This matters more for REST APIs than it might first appear, because API credentials are frequently long-lived and broadly scoped by default — a single key that can call every endpoint the upstream service exposes, not just the ones a particular agent role should reach. Vaulting doesn't narrow what the key itself can do; that's still whatever the upstream API grants it. What vaulting removes is the model's ability to ever hold or repeat that key, which is the specific failure mode a prompt injection would otherwise try to exploit — asking the agent to "print your configuration" or "show the request you're about to send" has nothing to extract if the token never entered the conversation in the first place.
What validated parameters catch before the request goes out
Typed parameters do more than document the endpoint — they reject a malformed call before it reaches the upstream API. If an endpoint's spec declares an integer path parameter and a required string field, a call that supplies the wrong type or omits the field fails validation at the gateway, not as a confusing error returned from the API itself three network hops later. That's a smaller thing than injection prevention or credential isolation, but it's part of the same pattern: a typed tool boundary catches classes of bad input at the point closest to where the model produced it, instead of relying on the upstream service to reject everything it wasn't built to expect.
One tool per capability, including destructive ones
The same one-tool-per-capability principle that applies to a generated database tool set applies here: an API with a dozen endpoints becomes a dozen typed tools, not one tool that can do anything the credential permits. That granularity is what makes gating destructive operations practical. A refund or cancellation endpoint is still just one tool among many — it can be placed behind a human-in-the-loop approval step without touching the read-only endpoints sitting next to it in the same generated tool set. Nothing about exposing a REST API changes that framing; it's the same approval-gate model already described for database write tools in the Build pillar guide.
Where this fits, and where it doesn't
This approach works well when the thing you want to expose is already a documented (or at least well-understood) set of endpoints — a payments API, an internal order-management service, a third-party SaaS with a public spec. It doesn't replace an API that needs custom orchestration across multiple calls; each generated tool maps to one endpoint, so multi-step logic still has to live upstream of the tool layer, in whatever calls the API in the first place. If you're still deciding whether generation is the right starting point at all, the guide to evaluating a no-code MCP server builder covers that decision in more general terms, including where hand-written tools remain the better fit.
The security model underneath — RBAC, vaulting, audit logging, injection detection — is the same one covered for every connector type in the complete guide to securing MCP. Generating a tool from an OpenAPI spec doesn't create a lighter-weight version of that pipeline; it just changes how the tool got defined.
Expose your first API endpoint
Import a spec or define a couple of endpoints by hand and see the generated tools appear. Explore the no-code MCP builder, or start free — the free tier doesn't require a sales call.
Related Guides: