Paste docs. Get an MCP server.
Point at any API documentation. R28 generates a hosted MCP endpoint your AI agent can call. Auth and execution handled.
Works with every MCP client
Claude Code
OpenClaw
WindsurfDocs in. Tools out.
Crawls schemas. Generates typed tools.
R28 follows schema links across doc pages, extracts entity definitions, resolves dependencies, and outputs typed MCP tools with Pydantic models — not string blobs.
Three steps to a working tool
No SDK to learn, no code to write. Paste a URL, R28 does the rest.
1. Paste a docs URL
2. Tools get generated
3. Add to your MCP client
Manage your tools
See every tool you've generated, track usage, manage API keys, and copy MCP config — all from one dashboard.
Why R28 tools work
The agent sees clean types. The API gets the exact wire format it expects. R28 handles the translation — in both directions, at every level.
Any API. Even the messy ones.
One endpoint can reference schemas across 10 doc pages — nested types, enums, transitive dependencies. R28 crawls all of them, resolves the full type graph, and generates a tool that actually works. Miss one enum and the whole thing breaks. R28 doesn't miss.
Your agent sees what it needs. Nothing else.
The LLM gets EmailContent { to, subject, body }. Not RFC822. Not base64. Not raw MIME. R28 transforms between what the LLM understands and what the API expects — in both directions. Wire formats are invisible.
Zero drift from the docs
Same field names, same descriptions, same types as the API documentation. Input-only fields stripped from output schemas. Optional vs required preserved exactly. The generated schema is a 1:1 projection — not an approximation that breaks on edge cases.
Responses cleaned, not dumped
A single raw Gmail thread can be 50KB+ of MIME payloads, HTML, tracking pixels, and base64 attachments. That's not noise — it's a context window bomb. One tool call can eat your entire budget and break your agent. R28 transforms responses into clean, readable text before the LLM ever sees them.
R28 is the adapter.
You don't adapt your agent to the API. You don't adapt the API to your agent.
Most tool platforms build their own abstracted version of each API — flattened schemas, dropped fields, renamed types. You get their interpretation, not the API. R28 preserves the API exactly as documented and handles the complexity in the middleware.
When the tooling is accurate and deterministic, you can finally isolate what's going wrong. If a tool call fails, you know it's your prompt — not a schema bug, not a dropped field, not a casing mismatch. You can iterate on prompts without the ground shifting under you.
When the tools are solid, the model matters less. A well-wired tool with correct types and clean context can work with a small, cheap model — because the tooling is doing the hard work, not the LLM. That's the path to agents you can actually rely on.
You designed custom tool schemas. You trained your agent on them. Then you changed something and everything broke. You spent weeks reimplementing one API. When a tool call failed, you couldn't tell if it was the prompt, the schema, or the API.
We did all of that building SurfBuddy. So we built R28. Now available to everyone.