Loading ToolBench
MCP server for Fizzy.do integration - manages boards, cards, steps, and todos
The server defines 9 tools with explicit schemas and descriptions. All tools follow verb_noun naming conventions (fizzy_list_*, fizzy_create_*, fizzy_get_*, fizzy_update_*, fizzy_add_*, fizzy_sync_*, fizzy_close_*). Descriptions are present for all tools and most are 15-50 characters, which is concise but at the lower end of the 10-1024 character baseline. Input schemas are properly defined using Zod with type validation and constraints (min/max lengths, enums for compound objects). However, output schemas are not documented, tools return JSON but the expected response structure is not described in the tool metadata. Error handling exists (authentication check, textResponse() helper with isError flag) but error messages are generic. Parameter descriptions are minimal (1-4 words typically). No output pagination or limits are documented for list operations. The server properly handles secrets via environment variable injection rather than parameters (loadConfig() pattern).
Add steps to a card
Close a card
Create a new Fizzy.do board
Create a new card in a board
Get details of a card by its number
List all Fizzy.do boards
List cards, optionally filtered by board
Output schemas are not documented. Tools return JSON but the expected response structure (fields, types, pagination) is not specified in tool metadata. LLMs cannot plan downstream calls or extract data reliably without knowing the response schema.
Parameter descriptions are too terse (1-4 words). Pattern baseline is 72 chars average. E.g., 'Optional board ID to filter cards' (5 words) should explain: 'Board ID to filter by (optional; if omitted, returns cards from all boards)'. Current brevity provides insufficient context for LLM parameter selection.
Destructive operations lack confirmation/dry-run support. fizzy_close_card is marked IRREVERSIBLE but has no confirmation step or recovery guidance in its description. No pattern:confirmation-request implementation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Sync todos to a card, creating if needed
Update a step's completion status
No pagination or result limits documented for list operations. fizzy_list_boards and fizzy_list_cards lack limit/offset parameters and do not document max result count. Per pattern:paginated-result, list tools should support pagination to avoid context window exhaustion.
Error messages are generic. The server returns 'Fizzy.do is not configured. Please run /fizzy:setup...' which is actionable, but other error paths (API errors in switch cases) are not shown. No pattern:recovery-guide or pattern:error-classification implementation visible, error responses do not categorize as retryable/user-fixable/fatal or provide specific recovery steps.
Tool descriptions do not clarify state mutation. fizzy_create_board, fizzy_create_card, fizzy_add_steps, fizzy_update_step, fizzy_sync_todos, and fizzy_close_card are WRITE/IRREVERSIBLE but descriptions do not explicitly state 'Creates...' or 'Modifies...'. Agents need explicit mutation clarity for safe retry logic.
fizzy_sync_todos combines two concerns: checking if a card exists, creating it if missing, and syncing todos. No separate create vs. update tools. Description does not explain idempotency or exactly what 'sync' means (replace? append? merge?). Per pattern:tool, each tool should do one thing.
No scope/permission declarations. Tools do not declare what permissions they require (e.g., 'read:boards', 'write:cards'). Agents cannot be configured with least-privilege; no audit trail hints.