DocsToolkit builder

Start here

Reference

Build and run

DocsBuild and run

The toolkit builder

Paste what you have. A spec, a server, a repository, or a command. The builder reads it, names the operations worth exposing, and installs a toolkit that runs them.

What you can hand it

REST APICalled directly over HTTPS

A URL: Any OpenAPI document from Swagger 2.0 through 3.2, or a Postman v2.1 collection, published anywhere we can fetch it.
A file: The same documents uploaded, in JSON or YAML, for a spec that is not published anywhere reachable.

MCP serverImported as the server advertises itself

Remote, over HTTP: The server URL, or the whole mcpServers block your provider handed you. The endpoint and the token are read out of it. That token is used once, to read the tool list, and is never stored.
Local, over stdio: A GitHub link, which is resolved to a launch command, booted in your sandbox and asked for its tools. A command such as npx -y @vendor/mcp works too.

CLIRun in your project sandbox

A GitHub repository: The repository link. The release asset is pinned, the binary is installed in the sandbox, and the tool is asked what it can do.
A literal command: Write the command yourself with {{name}} where an agent supplies a value. Reliable when you already know the invocation, which a README often does not document.

Or start from the documentation

If you do not know which of those a product offers, give the builder its documentation URL, or its name. The builder can search the web and read a page as markdown, so it can go and find out whether a product publishes an OpenAPI document, ships an MCP server, or has only a CLI, and then build from whichever it found. Where the answer is genuinely a choice, it stops and asks you with the real alternatives rather than picking one.

A toolkit can carry more than one way in. One product with a REST API, an MCP server and a CLI is one toolkit with three interfaces, which is the point of grouping by product.

Why a built toolkit cannot invent an endpoint

A model reads the source and decides what to call each operation, which of them are worth exposing at all, and how to describe them. That is what a model is good at. What it never does is write the wiring.

Extraction is deterministic. A parser reads the document, the tool list or the command help and produces every capability it found, each with a stable id and an executable binding: the method and path for an API, the remote name for an MCP tool, the command and arguments for a CLI. The model is then shown those capabilities and may only refer to them by id. It cannot emit a binding, because bindings are not part of the shape it answers in.

Where the model sits in the pipeline

source document  ->  deterministic extractor  ->  capabilities, each with a binding
                                                     |
                                        the model sees ids, labels, summaries
                                                     |
                            selects ids, names them, writes descriptions
                                                     |
              every id resolved back against extraction  ->  an id that does not exist
                                                             fails the build

The resolution step is the safety boundary of the whole pipeline. An id the model returned that does not exist in the extraction output is a hallucination, and it shows up as a missing id and fails the build rather than becoming something an agent can call. A hallucinated endpoint is structurally impossible here, not merely unlikely.

Classification works the same way. Where the source gives a deterministic signal about whether an operation reads or writes, that signal is reconciled with the model's opinion and the result fails safe, so a model that argues for a less restrictive kind than the source implies does not quietly get its way. See Access control.

Sandbox safety

CLI operations and stdio MCP servers run in your project's sandbox. They start without a shell, which removes the whole class of injection that comes from string interpolation into a command line. Interpreters and destructive executables are refused. A release asset is pinned and verified before it is installed, and an artefact that is not pinned or not confined is refused rather than run.

A build costs 10 credits per interface it reads, so a toolkit built from one source costs 10. They are charged together as one transaction, so a build cannot be half paid for. A build refused before extraction, which is the expensive part, costs nothing. See Billing and credits.