Loading ToolBench
A working WebMCP implementation for Next.js, built around a fictional bike shop. Demonstrates how to register and execute WebMCP tools in a browser environment.
Four tools with clear verb-noun naming (get_*, check_*, start_*) and well-written descriptions (100-200 chars, matching production baseline). All tools have input schemas with enums and type constraints. Descriptions follow the 'what/when/why' pattern effectively. Key strength: descriptions explicitly state when to use each tool ('Use this when someone asks...'), guiding LLM selection. Weakness: no output schemas documented; error handling guidance minimal; no pagination or result limits specified (though data volume appears small for this domain).
Whether Northwind Bikes collects from a given town. Use this when someone names where they are and wants to know if collection is an option.
Adds up a job from a service and an optional collection from the customer's town. Use this once someone has said what they need done, rather than quoting from the price list yourself, so the total and any collection fee come out of one place.
Everything Northwind Bikes offers, with the price and a one-line summary of each. Use this when someone asks what the shop does, what something costs, or whether a particular job is handled here.
Types someone's details into the booking form on the page so they can send it. It fills the form and stops there: the person reads it and presses the button themselves, and nothing is sent until they do. Use it once someone has said they want to book and has given their own details. Never invent values to fill it with.
No output schemas documented. Tool descriptions state what is returned (e.g., 'price and summary'), but LLMs cannot plan downstream calls without knowing exact response field names and types.
start_booking lacks error handling guidance. Description says 'Never invent values', but no error response documents what happens if validation fails (e.g., invalid email, unknown town) or how the LLM should recover.
check_service_area accepts free-form 'town' string with no validation hints. Description says 'in plain words', but no guidance on format (e.g., 'London' vs 'london', 'New York' vs 'NY'). LLMs may pass invalid formats.
start_booking 'notes' parameter is optional but description says 'what is wrong with the bike, in their own words', implies it should be required for a complete booking. Ambiguous optionality may cause LLM to omit critical context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
No idempotency or confirmation pattern for start_booking. Description says 'person reads it and presses the button themselves', but no explicit confirmation step or dry-run mode. If LLM retries on ambiguous failure, form may be prefilled twice.