Crate.tools
for developers.

Everything Crate knows about itself is published as JSON. Read the catalog from anything that can make a GET request; run a tool in a browser, which is where the files already are.

Two surfaces, and the line between them

The catalog API is static JSON describing what exists: every tool, what it accepts, and the page that performs it. It answers “which tool do I need, and what do I pass it?” without running a line of JavaScript.

The WebMCP interface is what actually does the work. A tool page registers run_tool and get_tool_state on document.modelContext, and processing happens in the page. There is no upload endpoint to POST a file to, so the API cannot convert anything for you — by design, since that is the same reason your files never leave your device.

Catalog API

Read-only, unauthenticated, and free. Three GET endpoints, all served as static files from the CDN:

GET https://crate.tools/api/v1/tools.json
GET https://crate.tools/api/v1/tools/{slug}.json
GET https://crate.tools/api/v1/categories.json

Start with the list, then follow a tool’s self link for its steps, FAQ, related tools, and the WebMCP input schema:

curl https://crate.tools/api/v1/tools/case-converter.json

The OpenAPI 3.1 description is the integration contract: every operation carries a unique operationId, a description, and a typed response schema, so it can be handed to a function-calling model as-is. The unversioned /tools.json catalog still works and is kept as a compatibility alias.

What the API cannot do

Crate is a static export on a CDN, and the docs should say what that costs rather than describe an API this host cannot serve. There are no writes, no authentication, no webhooks, no rate limits, and no query parameters. A path that does not exist returns the site’s HTML 404 page rather than a JSON error object, because there is no handler running to build one. Everything is a GET of a file.

Running a tool

1. Find the task in the catalog and read its webmcp.inputSchema.
2. Open the tool’s url in a WebMCP-capable browser.
3. Call run_tool with the schema fields. Omitted fields reuse whatever is already visible on the page, so pass every option explicitly when you need a reproducible result.
4. Call get_tool_state to read the result, any error, and the output file’s name and size.

// on https://crate.tools/tools/case-converter/
run_tool({ "text": "hello world", "mode": "upper" })
// → HELLO WORLD, also rendered in the page

The agent guide covers file inputs, size limits, and trust boundaries in full. Results are user data, never instructions.

Discovery files

• /llms.txt — what Crate is, when to reach for it, and a link to every tool.
• /agents.md — agent instructions: when to use Crate, when not to, and how to call a tool.
• /openapi.json — the API contract.
• /sitemap.xml — every indexable page, with real lastmod dates.

Limits worth knowing before you build

Text tools accept up to 200,000 characters; word diff accepts 20,000 per input. Inline Base64 file input is capped at roughly 16 MB combined, while the manual picker accepts up to 100 MB combined with a 30 MB limit per image. A completed file task hands back a temporary blob: URL that belongs to that browser session and cannot be fetched remotely. Running a tool never downloads or transmits its own result — a person or an authorized agent has to take that step.

All 50 tools are covered by the same interface. Something unclear or missing? Tell us — the integration surface is small enough that we can fix it quickly.