For agents

Each tool page hydrates a small island and then exposes its API on window.__tools[slug]:

• run(input) — calls the underlying pure function and returns its result, or a Promise you should await (e.g. hash). input is a plain object whose accepted fields are documented per tool by describe() and in each /tools/<slug>.json manifest.
• describe() — returns { slug, params, returns } (plus async, guide and example/examples where the tool has them) so you can discover a tool's contract at runtime. It is derived from the same schema module that generates /tools/<slug>.json and /SKILL.md, so the three never disagree.

The page's #tool-output element (a stable, aria-live selector) shows results from the UI and #fragment URL-invocation paths — handy if you would rather read the rendered DOM. A direct run() call does not update it; read run()'s return value instead.

// on a live tool page, after hydration
window.__tools["base64"].describe();
const result = await window.__tools["base64"].run({ input: "…" });
// `result` is the answer; #tool-output reflects the UI / #fragment path

A self-contained agent skill — the drive contract plus every tool's params, return shape and a worked example — lives at https://aaronchartier.com/SKILL.md. Fetch it once instead of hydrating each page to discover schemas.

Documented parameters pre-fill a tool's inputs and run on load — a URL alone can drive a tool, no scripting required. Prefer the fragment (#); the browser never sends it to the server, so the input stays client-side. Each tool's parameters are listed in its describe() and its /tools/<slug>.json manifest.

https://aaronchartier.com/tools/base64#input=hello

A ?query form also works for back-compat, but prefer the # form — the fragment stays client-side.

Where the browser exposes the experimental Web Model Context Protocol (WebMCP) at document.modelContext (or navigator.modelContext on older preview runtimes), every page registers the tool catalog — every live tool with a headless run, read-only, since those tools are deterministic and side-effect-free. The interactive PDF editor (sign) has no headless run and is not registered: it stays page-only, via window.__tools.sign on its page. WebMCP is not in stable browsers yet; where it is absent this is a no-op, and the in-page window.__tools API above is the path that works today.

Prove the contract above end-to-end: the playground detects your WebMCP runtime, enumerates the catalog, runs the tools against pinned values, and grades three agent challenges — all on a live pass/fail scorecard.

/for-agents/playground— markdown mirror at/for-agents/playground.md.