Turn Any REST API into an MCP with MCPWorks

There's a gap in how AI assistants talk to the outside world. The Model Context Protocol is spreading fast, but the overwhelming majority of useful automation still lives behind plain REST APIs — Stripe, your internal billing service, a weather provider, the CRM your team already pays for. None of those shipped an MCP server.

Today, connecting an AI to one of those APIs means one of two bad options:

Find a pre-built MCP server for that specific API — if one exists, if it's maintained, and if it exposes the endpoints you need.
Dump raw API responses through the model's context window — where a single "list orders" call can burn 50KB of JSON to extract three fields.

MCPWorks now closes that gap. You can register any REST API on a namespace, and MCPWorks builds the MCP layer itself. We call it API → MCP.

What it does

Point MCPWorks at a REST API — by importing its OpenAPI/Swagger spec or defining endpoints by hand — and each endpoint becomes a callable primitive inside the code execution sandbox. Your AI then writes functions that call those primitives and compose them into a single, clean MCP tool.

If you've read about code-mode execution, this is the same idea applied to arbitrary APIs. Instead of the model loading a full endpoint schema and round-tripping the raw response through its context, it writes code like this:

from functions import api__acme__list_orders

orders = api__acme__list_orders(query={"status": "open"})
open_count = len(orders["data"])
total = sum(o["amount"] for o in orders["data"])

The 50KB response is parsed inside the sandbox. Only open_count and total ever return to the model. That's how Anthropic's code-execution research measured 70–98% token savings — and now it applies to APIs that were never designed for AI in the first place.

This is the inverse of our MCP Server Plugins feature. Where that bolts a third-party MCP server onto a namespace, API → MCP points at a plain REST API and synthesizes the MCP for you.

Registering an API

The whole flow happens in natural language from your MCP client. Ask Claude Code (or any MCP client connected to your namespace) to register the API:

$ claude "register the Acme API on my namespace from
  https://api.acme.com/openapi.json, and enable the
  orders endpoints"

✓ Imported OpenAPI spec from api.acme.com
  → 47 endpoints discovered
✓ Enabled: list_orders, get_order, create_order
  → 44 cataloged but disabled (curation)
✓ Server 'acme' ready
  → primitives available as api__acme__{operation_id}

A few things are happening under the hood:

OpenAPI import or manual definition. Import a spec from a URL or an uploaded file, define endpoints by hand, or mix both on one server. refresh_api_endpoints re-fetches the spec later and diffs what changed — preserving your settings by operation_id.
Selective, LLM-curated import. A big API might have hundreds of endpoints. You don't enable all of them. The import returns the full inventory and the model (or you) picks which endpoints to turn on. Unselected endpoints are cataloged but generate no sandbox primitives, so your catalog's token cost is bounded by what you actually use, not by how sprawling the upstream API is.
Functions-only by default. Enabled endpoints are sandbox primitives, not raw MCP tools. You compose them into clean tools by writing functions. (There's an opt-in escape hatch — publish_endpoint — to expose a single raw endpoint as a direct MCP tool when you genuinely want the thin passthrough.)

Composing endpoints into a clean tool

The point isn't to expose list_orders as-is. It's to build the tool you actually wanted. Ask for it:

$ claude "write a function 'open_revenue' that uses the
  Acme orders endpoint to return total revenue from open
  orders this month"

✓ Created function open_revenue
  → composes api__acme__list_orders
  → returns one number, not the full order list

The model writes a function that calls the endpoint primitive, filters and sums inside the sandbox, and exposes one tidy MCP tool — open_revenue — that any client on the namespace can call. The messy pagination, the 50KB payloads, the field-picking: all of it stays server-side.

Credentials: stored or passthrough

APIs need keys, and there are two very different situations. MCPWorks supports both from a single feature:

Stored credentials are encrypted at rest (envelope encryption, AES-256-GCM) and injected server-side at call time. The end-user — and the AI writing sandbox code — never sees them. This is for "my namespace, my API key, managed centrally."
Passthrough credentials are supplied at runtime from the execution environment and never persisted. This is for "each agent brings its own key" — each end-user or agent supplies their own credential at call time.

Either way, sandbox code never handles credential values. Injection definitions (where the key goes — header, query, bearer, or basic, with a format template) live in plain config; the secret values live in a separate encrypted blob or come from the transient execution env. Secrets are never in tool output, never in logs, never in the model's context.

Reaching out safely

Letting users register arbitrary base URLs is the largest new attack surface we've added — a naive implementation is a textbook SSRF vector. So API → MCP ships with a global denylist of private, link-local, and loopback ranges, and it re-resolves DNS at call time to defend against rebinding attacks. A registered URL that resolves to 169.254.169.254, 10.0.0.x, or localhost is refused — at registration and on every call.

Two more guardrails worth knowing:

Idempotent-only retries. Automatic retries on transient upstream failures apply to GET/HEAD/PUT/DELETE only. POST and PATCH are never auto-retried, so you'll never double-create or double-charge.
Full per-call telemetry. Every call records namespace, server, endpoint, method, latency, response size, and status — so you can see exactly what your APIs are doing.

Why this matters

The MCP ecosystem is growing, but it will never cover every API — and it doesn't need to. Most teams already depend on REST APIs that work perfectly well; they just aren't AI-shaped. API → MCP meets those APIs where they are. You don't wait for someone to publish an MCP server for your billing system. You point MCPWorks at it, enable three endpoints, and your AI writes the clean tools your workflow actually needs.

And because the composition happens in code inside the sandbox, you get the token economics for free. A REST API that would have flooded your context window becomes a handful of tight, purpose-built tools.

Getting started

Sign up for MCPWorks — Developer Preview includes a 14-day Pro trial with 125,000 executions, no credit card required.
Connect your namespace to any MCP client via .mcp.json.
Ask it to register an API from an OpenAPI URL, enable the endpoints you want, and write your first composed function.

Questions? Reach out at [email protected] or find us on Bluesky.

Frequently asked questions

Can MCPWorks turn any REST API into an MCP? Yes. Register a REST API on a namespace by importing its OpenAPI/Swagger spec (from a URL or uploaded file) or by defining endpoints manually — you can mix both. Each enabled endpoint becomes a callable primitive in the code execution sandbox, and your AI composes those primitives into clean MCP tools. No pre-built MCP server for that API is required.

Do API endpoints become MCP tools directly? By default, no — enabled endpoints are sandbox primitives, not raw MCP tools. The AI writes functions that compose them into token-efficient tools. This keeps your tool catalog small and purpose-built. An opt-in publish_endpoint option can expose a single raw endpoint as a direct MCP tool when you want a thin passthrough.

How are API credentials handled? Two ways. Stored credentials are encrypted at rest and injected server-side — the end-user and the sandbox code never see them. Passthrough credentials are supplied at runtime from the execution environment and never persisted, so each agent can bring its own key. In both cases, sandbox code never handles credential values, and secrets never appear in tool output or logs.

Is it safe to register an arbitrary API URL? Yes. MCPWorks enforces a global SSRF denylist of private, link-local, and loopback IP ranges and re-resolves DNS on every call to defend against rebinding attacks. URLs that resolve to internal addresses are refused at registration and at call time.

How does this save tokens? The AI calls an endpoint as a primitive inside the sandbox, processes the full response there, and returns only the extracted result. A 50KB JSON response never enters the model's context. This is code-mode execution applied to REST APIs — the same approach Anthropic measured at 70–98% token savings.