The moment a new tool's web page renders correctly in the browser is the moment it looks finished. On this site, it is roughly half done. A tool that exists only as a page is a tool in a silo: invisible to the API, absent from the MCP server, missing from the sitemap, undocumented. Treating "the page renders" as the finish line is how tools quietly become inconsistent with each other. So the finish line is defined differently, as a checklist.
The six surfaces#
A tool is "done" when the same capability is present and consistent across all of these, not one:
- The registry / handler. The tool is a shared handler — a pure function from validated input to a result — over the same sourced data every other tool uses. No private copy of the pricing.
- The web page. The human interface, with its inputs, its result, and its honest treatment of pending and stale data.
- The REST door.
POST /api/tools/<slug>, calling the identical handler, returning the identical answer in JSON. - The MCP tool. The same capability exposed to agents over the protocol, carrying the verified/pending/stale status through so an agent can't launder an uncertain number.
- The sitemap and metadata. The page is in the sitemap, has a canonical URL, a description, structured data, and a markdown twin — so both search crawlers and agents can find and read it.
- The docs. The tool is discoverable and explained where developers look, not just findable by luck.
Miss any one of these and the tool is technically live but practically inconsistent — reachable by a human but not an agent, or by an agent but absent from search, or present everywhere but running its own slightly-different copy of the math.
Why a checklist beats good intentions#
The reason this is written down as a checklist, rather than trusted to care, is that the failure mode is silent. A tool that shipped its page but not its MCP door doesn't error — it just isn't there when an agent looks, and nobody notices until someone goes looking. "Integrated everywhere" is not a state you can see by glancing at the page; it is a set of separate facts that have to be checked one at a time.
The shared-handler design is what makes the checklist affordable rather than onerous. Because there is one handler behind all the doors, adding the REST and MCP surfaces is wiring, not reimplementation — the hard part (the logic, and its honesty rules) is written once and reused, so keeping six surfaces consistent is mostly a matter of remembering to open all six doors.
The point#
A tool in a silo is a small, specific kind of dishonesty: it implies a capability is available when it is only partly available, in the one place you happened to look. The checklist exists so that "we have a token counter" means the same thing to a person, a script, and an agent — the same answer, from the same data, reachable the same six ways. A tool isn't done when its page renders. It's done when there's no door left that a caller could knock on and find nobody home.