Loading ToolBench
Two tools with clear naming (list-events, get-event) and complete input schemas. Descriptions are present but generic (10 - 20 words each). All parameters have type definitions and descriptions. However, output schemas are not documented, error handling lacks recovery guidance, and parameter descriptions lack format/constraint details. No tool annotations (readOnlyHint). Schemas are well-formed JSON Schema with required fields properly declared.
Get detailed information about a specific event by its ID.
List events for a specific user. Returns upcoming, past, or all profile events.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing what list-events and get-event return.
Parameter descriptions lack format/constraint details. 'limit' has no min/max bounds; 'type' enum is documented but 'username' lacks guidance on format (email vs username string).
Error responses in code return generic error objects without recovery guidance. E.g., 'Unknown tool' or 'Missing API key', no hint to call search_users or check env vars.
No tool annotations (readOnlyHint). Both tools are read-only but this is not declared in the tool definition, forcing LLMs to infer safety from descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Pagination not documented. list-events accepts 'limit' but no offset/cursor or total_count guidance. Large result sets could exhaust context without pagination hints.