Loading ToolBench
The server has 3 read-only tools with adequate but basic descriptions and complete input schemas. All tools follow verb_noun naming conventions and declare their parameters with types and descriptions. However, descriptions are terse (8-18 words), lack context about when to use each tool, and do not guide LLM reasoning about tool selection or composition. Output schemas are not documented in the visible code. Parameter descriptions are functional but minimal, they state what the parameter controls without examples, constraints, or error recovery guidance. Error handling is absent: no guidance for retryable vs fatal failures, no actionable error messages, and no recovery patterns. The tools are well-isolated (each does one thing) but lack composition hints, no chaining advice or mention of prerequisite lookups. Security is adequate (read-only operations, no secrets in params), but no audit or permission documentation.
Get details of a specific activity.
Get the segments of a specific activity.
Get the authenticated user's activities.
Tool descriptions are extremely terse (8-18 words) and lack LLM-optimized guidance. 'Get the authenticated user's activities' does not explain when to call this vs. get_activity, whether filtering is applied server-side, or what the response structure contains. Target: 50-200 chars with WHAT, WHEN, and HOW guidance.
No documented output schemas. The server does not specify what fields each tool returns, their types, or whether they include chaining IDs (e.g., activity_id for downstream calls). LLMs cannot plan composition without knowing response structure.
Parameter descriptions are minimal. 'Page number' and 'Number of items per page' lack constraints. What is the valid range for page and per_page? Are there defaults? What happens if page exceeds the result set? Descriptions should state range, default, and error behavior.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
No error handling guidance. If activity_id is invalid, does the tool return a 404 or a graceful error? The LLM has no recovery strategy. Tools should indicate which errors are retryable and what the agent should do next (e.g., 'Not found, try searching for the activity by name').
Missing pagination documentation. get_user_activities accepts page and per_page but does not document the total count or cursor for fetching the next page. Without metadata about result size, LLMs cannot determine when to paginate or when they have retrieved all data.
No composition hints or prerequisite guidance. All three tools read data but do not explain their relationships. Should get_user_activities be called before get_activity? Can get_activity_segments work independently? Missing these hints forces the LLM to discover relationships through trial and error.