Skip to main content

​
What’s exposed

800+ tools on the site. If a tool page’s Builder menu shows “MCP”, an agent can call it. The rest run entirely in the browser — webcam capture, some PDF and image editing — and have no server-side equivalent. Calling one returns tool_not_allowed, so an agent knows to stop retrying and send the user to the website.

​
Name mapping

MCP tool names can’t contain /, so nested slugs use a double underscore:
Flat slugs are unchanged.

​
Finding and running a tool

A hosted session lists five tools, not all — see the overview for why. Three calls get from “convert a CSV” to a result:
1

search_tools

Returns:
2

describe_tool

Returns:
3

run_tool

Charged 3 credits — exactly what describe_tool quoted.
Search and describe are free. Always describe before you run: field names aren’t guessable. credit_cost_multiplier_field names the input that multiplies the price on per-unit tools (ioCount on the name generators, at 2 credits a name). null for the flat-priced majority. Connect to ?listing=full to get all supported tools with their own schemas instead — worth it only if your client loads tools lazily. Either way a tool can be called by its own name directly. Over REST the equivalents are GET /v1/tools/search and GET /v1/tools/list.

​
Inputs

Inputs use the same names as the REST API (ioInputString, ioCase, …), advertised through describe_tool’s input_schema — or, under ?listing=full, through each tool’s own inputSchema. They are the same object either way.

​
Results

A successful call returns both text content and structuredContent — the same outputs object REST returns, so an agent can read fields by name. Failures come back as an MCP error result carrying the same error codes as REST, as code: text: Parse the prefix up to the first colon — the text after it varies by code (a field map, a sentence, a short phrase) and isn’t guaranteed stable.

​
Checking your balance

Alongside the three above, hosted MCP sessions get two tools that aren’t from the catalog. get_credits takes no arguments:
It costs no credits, so an agent can check whether it can afford an expensive tool without paying for the answer. It still takes your per-minute rate limit — use it before a batch, not on a loop. It is not offered over the local stdio server, which runs on your own machine with no API key and no metering, and so has no balance to report.

​
Reading your usage history

And the fifth, get_usage — also no arguments:
What the balance doesn’t tell you is what it went on. No credits, last 30 days of spend — one row per tool per day per surface (web, api, mcp), so browser and REST use show up here too. Same stdio carve-out as get_credits. credits is the same object get_credits returns, from the same builder, so the two can’t quote different numbers — it’s here because spend and balance answer each other’s obvious follow-up. It’s null only on an unmetered deployment. Use get_credits when the balance is all you want: it also carries your rate limit and per-plan credit floor. Over REST, GET /v1/me/usage returns the history alone — pair it with GET /v1/me/credits for the balance.

​
Cost

Every tool call is metered and refunded on failure — see Credits for the per-plan floor. run_tool costs the same as calling the tool directly: no surcharge, no discount. Listing is free, and so are search_tools, describe_tool, get_credits and get_usage.