Loading ToolBench
Server has 7 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short), and input schemas are present with Zod validation. However, descriptions lack depth, most are single-clause statements without context on WHEN to use the tool or what it returns. Parameter descriptions are minimal (e.g., 'The ID of the form'). Output schemas are not documented. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint, destructiveHint). Naming is clear and verb-based, but parameter naming could be more explicit (e.g., 'filters' is vague). The delete_form tool reuses GetFormSchema instead of having its own definition, suggesting incomplete schema design.
Create a new form
Delete a form by ID
Get a specific form by ID
Get responses/submissions for a specific form with optional filtering
Get a specific form submission by ID
List forms with optional pagination
Submit a response to a form
Descriptions lack depth and recovery context. Most are 10-50 chars (baseline 194 chars for A+ tools). No descriptions explain WHEN to use a tool vs. similar ones, what it returns, or prerequisites. E.g., 'Get responses/submissions for a specific form with optional filtering' does not explain pagination behavior, response structure, or when to call get_form_submission instead.
Output schemas are not documented. LLMs cannot plan downstream calls or extract required fields. E.g., does list_forms return a 'total' count? Does get_form_responses include 'nextCursor' for pagination? Does create_form return the new form_id?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
delete_form reuses GetFormSchema instead of declaring its own schema. This suggests incomplete schema design and makes the tool definition ambiguous. Destructive operations should have explicit, dedicated schemas.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes. delete_form and submit_form_response should be marked destructive; list_form and get_form should be marked readOnly.
Error handling lacks recovery guidance. handleFilloutError() throws FilloutError, AuthenticationError, or ValidationError, but error responses do not tell LLMs what to do next (e.g., 'Try search_forms() with a partial name' or 'Check FILLOUT_API_KEY environment variable').