Turn your REST API into an MCP

If your API has an OpenAPI spec, it can be called by Claude, Cursor and any other MCP client — without you writing an MCP server. Paste your spec below and see exactly which tools it produces.

Nothing is saved and no account is needed. Your spec is fetched once and the tools are derived from it.

No spec yet?

Usually there is one already and nobody knew the URL. If not, a listing needs far less of a document than people expect.

You may already have one

Most frameworks generate a spec whether or not you asked. Try the path for yours before writing anything.

Framework	Usual path	Notes
FastAPI	/openapi.json	Enabled by default. Exclude a route with include_in_schema=False.
NestJS	/api-json	With @nestjs/swagger set up. SwaggerModule.createDocument exposes it.
Django REST Framework	/schema/?format=json	Via drf-spectacular.
Laravel	/docs/api.json	Via Scribe or L5-Swagger.
Spring Boot	/v3/api-docs	With springdoc-openapi on the classpath.
Go	/swagger/doc.json	Via swaggo/swag.
Express / Fastify	—	No default. swagger-jsdoc reads JSDoc comments; @fastify/swagger serves /documentation/json.
Rails	—	No default. rswag generates one from request specs.

Or write the smallest one that works

You do not need to describe your whole API. Two endpoints is a real listing — start there, paste it into the box above, and add the rest once you have seen it work.

{
  "openapi": "3.0.3",
  "info": { "title": "My API", "version": "1.0.0" },
  "servers": [{ "url": "https://api.example.com" }],
  "paths": {
    "/customers": {
      "get": {
        "operationId": "list_customers",
        "summary": "List customers, newest first.",
        "parameters": [
          {
            "name": "limit",
            "in": "query",
            "schema": { "type": "integer", "default": 20 },
            "description": "How many to return."
          }
        ],
        "responses": { "200": { "description": "Customers" } }
      }
    },
    "/customers/{id}": {
      "get": {
        "operationId": "get_customer",
        "summary": "One customer by id.",
        "parameters": [
          {
            "name": "id",
            "in": "path",
            "required": true,
            "schema": { "type": "string" },
            "description": "From list_customers."
          }
        ],
        "responses": { "200": { "description": "The customer" } }
      }
    }
  }
}

operationId is the tool name. list_customers is what the agent sees and types. Name it the way you would want it read aloud.
summary is when to use it. It is the only guidance an agent gets on which tool to reach for, so write it for someone who has never seen your product.
Describe every parameter. "From list_customers" tells an agent where an id comes from, which is the difference between chaining two calls and guessing.
Response schemas are optional. Tools are built from operations and their inputs; you can add response detail later without renaming anything.

Or build one here

Describe your endpoints and we write the spec. Nothing is guessed — every field below becomes exactly what you typed, so the tools cannot drift from the API you actually run.

Base URL

Endpoint 1

Tool name — what the agent types

What it does — when to reach for it

The spec this produces

{
  "openapi": "3.0.3",
  "info": {
    "title": "My API",
    "version": "1.0.0"
  },
  "servers": [
    {
      "url": "https://api.example.com"
    }
  ],
  "paths": {
    "/customers": {
      "get": {
        "operationId": "list_customers",
        "summary": "List customers, newest first.",
        "responses": {
          "200": {
            "description": "Success"
          }
        }
      }
    }
  }
}

How it works

1
You publish a spec
An OpenAPI 2 or 3 document at a URL we can fetch. Most frameworks generate one already — FastAPI, NestJS, Express with swagger-jsdoc, Rails with rswag.
2
We derive the tools
One tool per operation. The name is the operation's operationId, and the input schema comes from its parameters and request body, so an agent knows what each argument is without being told.
3
The gateway does the translation
When an agent calls a tool, we rebuild the real HTTP request from your spec — path params in the path, query params in the query, the rest in the body — call your API, and wrap the response back into MCP.
4
Your API never changes
No MCP server to write, no SDK to add, no new endpoint. The API you already run is the API that gets called.

Questions

What do the tools end up being called?

Each operation's operationId. That makes tool names a deliberate choice rather than something generated from a URL path — write them the way you want an agent to read them.

How does authentication work?

Subscribers never see your credentials. The gateway holds them and attaches them per call. If your API needs a key from each subscriber instead, the listing can collect it once on a setup form and send it with every request.

How do I keep internal endpoints out?

Leave them out of the spec. Every operation in the document becomes a callable tool, so an admin or internal route in the same spec becomes agent-callable too. Most frameworks can exclude a route from the schema — FastAPI's include_in_schema=False, for instance.

What happens when I change the API?

Re-sync and the tools follow the spec. Renaming an operationId renames the tool for everyone subscribed, which will break prompts written against the old name — treat operationIds as a public interface.

Do I have to charge for it?

No. A listing can be free, a flat monthly price, or metered per call with a per-tool weight, so an expensive operation can cost more than a cheap read.

Already know it works?

List your API

Or read the REST → MCP docs.