Loading ToolBench
A private location archive with an MCP server: where you were, when, for how long, who with, and what the weather was doing.
Strong tool definitions with clear, domain-specific descriptions (avg 180 chars, well above 10-char minimum). All 15 tools have explicit schemas with typed parameters. Most parameters include descriptions. However, naming lacks action verbs (tools are nouns: 'stays', 'trips', 'day' rather than 'get_stays', 'list_trips', 'get_day'). Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent from visible code. One write tool (record_together) lacks required field validation guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications.
Cities over a period, with time in each, how many separate times they were there, and which days. Use for 'which cities did I go to last spring'.
Countries over a period: separate trips there, time spent, distinct days, and the cities inside each. Pass `country` for one of them ('how many times have I been to Japan').
Where the user is right now: address, coordinates, their local time, how old the fix is, which trip they are on and day N of it, and how far from home. Read this before saying anything about where they are.
One date end to end: where they woke up, every stay in order, the journeys between them, and the weather. Identify it by YYYY-MM-DD.
Run a SELECT against the archive. One statement at a time, read-only, and capped at 2000 rows. The schema is public: every table is documented in the migrations.
Tool names lack action verbs. All 15 tools use noun-only names (stays, trips, day, weather_now) instead of verb_noun pattern (get_stays, list_trips, get_day, get_weather_now). LLMs infer intent from verb, noun-only names reduce clarity and increase selection errors.
Output schemas not documented. Tool descriptions explain what they return in prose ('every stay with start, end and duration') but no formal JSON Schema for response structure. LLMs cannot predict field names, types, or nesting, forces runtime discovery and increases hallucination risk.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Record that someone was with them over a date range, times optional. Use it whenever a conversation says who they were with and when — a weekend, an evening, a week at a friend's — including for spans the archive never detected as a trip. Never write where: the archive answers that. Needs migrations/0003_companions.sql.
The chronological list of stays over a period: every stop with start, end and duration, the trip it belongs to, and the place. Use it to reconstruct a day, a week or a trip in order.
The places they spend time in, most time first: address, city, what the source calls the place, how many stops and how many hours. Use for 'where do I actually spend my time' or to find an address.
One trip in full: the day-by-day country and city, every stay, the journeys with mode and distance, the people tagged on it, and the note. Identify it by slug, by name, or by a date inside it.
Trips, newest first: name, dates, nights, countries, cities, how far from home, and who was along. A trip is a run of nights outside the country they live in or over 100 km from it. Names edited by hand are kept.
The forecast for the next week where they are: daily high and low, conditions, and rain chance. Pass nothing for where they are now, or `place`, `lat`/`lon` for somewhere else.
The weather right now where they are: temperature, conditions, wind, and the source. Pass nothing for where they are now, or `place`, `lat`/`lon` for somewhere else. The forecast is an ensemble: a chance of rain is counted over ensemble members rather than lifted off one model's output.
The weather on a date in the past where they were: temperature, conditions, wind, and the source. Reads the coordinates out of the archive instead of asking, and every answer says which position it used and how that was decided.
The link between trips and a people graph, both ways. Pass `person` for the trips shared with them, `trip` for everyone tagged on it, neither for every tagged pairing. `via` says how the link was made: 'trip' for a tag on the trip, 'range' for a window that covers it. Needs the optional people bridge.
Days spent with someone, and where those days landed. Reads the windows recorded by `record_together` against the archive: cities, countries, how long, and the trip each window falls in. Pass no `person` for every window. Needs migrations/0003_companions.sql.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked READ_ONLY or WRITE in comments but not in MCP schema. record_together is destructive (writes to database) but lacks destructiveHint annotation. Agents cannot distinguish safe from unsafe tools without reading descriptions.
Error handling absent from visible code. No guidance on retryability, user-fixable errors, or recovery steps. location_sql is capped at 2000 rows but no error message if exceeded. record_together requires person name to 'resolve to exactly one' but no error message if ambiguous.
Parameter validation rules not documented. record_together requires 'person' to resolve uniquely but no description of what happens if multiple matches exist. location_sql accepts arbitrary SELECT but no mention of injection protection or query validation.