# A tool isn't done when its page renders

> 23 Jul 2026 · Telemeter · 3 min read

Shipping a tool on telemeter.ai means wiring it through six surfaces at once — page, API, MCP, sitemap, docs, and the registry. Here's the checklist, and why it's a checklist.

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:

1. **The registry / handler.** The tool is a shared handler — a pure function
   from validated input to a result — over the same [sourced data](/blog/prices-in-git-not-a-database)
   every other tool uses. No private copy of the pricing.
2. **The web page.** The human interface, with its inputs, its result, and its
   honest treatment of pending and stale data.
3. **The REST door.** `POST /api/tools/<slug>`, calling the identical handler,
   returning the identical answer in JSON.
4. **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.
5. **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.
6. **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.

[Read on telemeter.ai](https://telemeter.ai/blog/a-tool-is-not-done-when-its-page-renders) · [Every tool and doc, machine-readable](https://telemeter.ai/llms.txt)