Frame the tool registry runtime experiment

Success is not “I followed the tutorial.” Success is producing evidence that: unknown tools are rejected; calculator and lookup return typed results. The accepted input is narrow on purpose: tool name, JSON args, registry of handlers. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: inline if/else tool routing without schemas. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

export const acceptance = {
  project: "a small tool registry containing a calculator and a read-only knowledge lookup",
  invariant: "tool descriptions, validators, and implementations agree on names and shapes",
  expected: "calculate({expression:\"6*7\"}) returns 42; an unknown tool is rejected without execution.",
} as const;

Expected evidence: duplicate names, stale schemas, timeouts, oversized results, and unsafe side effects. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the calculator + knowledge lookup tool registry, a decorative win often looks like a clean run that never checks allowlist reject count; schema validation failures; successful typed results. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: registering shell-exec as a 'helper' tool.

For tools-in-code, write the claim on a sticky note in this exact shape: “Given tool name, JSON args, registry of handlers, the tool registry runtime will …”. Fill the ellipsis with the observable part of: unknown tools are rejected; calculator and lookup return typed results. Tape the baseline beside it: inline if/else tool routing without schemas. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to route model tool requests through a registry that validates names and args. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (registry with calc and kb.lookup) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against registry with calc and kb.lookup. Note the metric you will eventually require (allowlist reject count; schema validation failures; successful typed results) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is string-eval calculator, or lookup that returns entire DB on missing id.

At the experiment brief stage for tools-in-code, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about registry with calc and kb.lookup that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: inline if/else tool routing without schemas.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to route model tool requests through a registry that validates names and args. If you cannot point to a file, command, or assertion that proves that for the tool registry runtime, stay on this page instead of advancing.

Glossary: tool · Glossary: structured output · Cheatsheet: production ops signals

Next