Loading ToolBench
Give Claude a sense of your motion — from your phone's browser. No app, no account, no location, nothing stored.
Three tools with identical zero-parameter schemas and minimal descriptions. All tools are READ_ONLY and stateless, which is good for safety. However, descriptions lack actionable context for LLM selection (e.g., when to call motion_get_current_state vs motion_summarize_session). No parameter descriptions exist (all schemas have empty properties). Output schemas are not documented. Naming follows verb_noun pattern correctly but descriptions are too terse (avg ~100 chars, below the 194-char baseline for A+ tools). No error handling guidance, no pagination info, no chaining IDs documented.
Current interpreted motion state of the paired phone: freshness, orientation, activity (stationary/walking/running/unknown), cadence and confidence. Missing data is null, never a fabricated zero.
Just the phone's latest orientation (heading, pitch, roll) and how old it is. Null when nothing with a full orientation arrived in the last 3 seconds.
Summary over the whole retained window (at most 30 minutes): sample count, moving/stationary/unclassified shares, average cadence, heading range and merged activity bouts, newest last.
All three tools have empty input schemas (no parameters, additionalProperties: false).
Descriptions lack actionable context for LLM selection. 'Current interpreted motion state' does not explain WHEN to call this vs motion_summarize_session (current vs historical). Descriptions should answer: What does it do? When should the LLM call it instead of a similar tool? What does it return?
Output schemas are not documented in the tool definitions. LLMs cannot plan downstream calls or extract the right data without knowing what fields to expect (e.g., does motion_get_current_state return {heading, pitch, roll, freshness, activity, cadence, confidence} or a different structure?).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
No error handling guidance. Descriptions do not explain what happens if the phone is not paired, sensors are unavailable, or data is stale. LLMs need recovery hints like 'If null, the phone may be offline, ask the user to check the connection.'
Descriptions mention data freshness and time windows (e.g., 'last 3 seconds', 'at most 30 minutes') but do not document how to interpret or use this info. LLMs need explicit guidance: 'Use motion_get_current_state for real-time activity; use motion_summarize_session for historical trends over the retention window.'