Loading ToolBench
This server has 6 tools with basic Zod schemas and descriptions, but significant quality gaps prevent it from reaching production readiness. All tools are directly registered in src/mcp.ts with names, descriptions, and input schemas using Zod. However, descriptions are minimal (10-50 chars), parameters lack type-specific guidance, schemas are underspecified for complex operations, and there is no output schema documentation. Error handling is minimal, most tools only check for missing MONDAY_TASKS_BOARD_ID. No input validation, no parameter constraints (enums, ranges), no guidance on valid values. The tool names are clear (verb_noun style), but parameters like 'columnValues' accept generic 'object' type with no constraint on structure. Composition is reasonable, tools are single-responsibility (read vs write operations separated). However, the lack of structured error messages, missing output documentation, and absent input validation across all tools place this firmly in the 'fair' range.
Add a new task (item) to the Monday.com board.
Get all groups from a Monday.com board.
Get detailed information for a specific item including all its columns and values.
Get items assigned to the current user for a specific Monday.com board.
Update a task (item) on the Monday.com board with custom column values.
Update the status of a task (item) on the Monday.com board.
No output schema documentation. Tools return {content: [{type: 'text', text: string}]} but LLMs cannot plan subsequent tool calls or extract structured data without knowing what fields are present in responses. Baseline: 100% of A+ tools have documented return types.
'columnValues' parameter in add-task and update-task accepts z.record(z.any()) with no constraint. Monday.com APIs expect specific column ID → value mappings. LLMs will hallucinate invalid column IDs. Need enum or documented format with examples.
No error recovery guidance. All error responses are bare text (e.g., 'MONDAY_TASKS_BOARD_ID is not set'). LLMs cannot determine: Is this retryable? Is it user-fixable? Should I ask for a different parameter? Baseline: Error responses must tell LLM what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
'newStatus' parameter in update-task-status accepts any string. Should enumerate valid statuses (e.g., 'in progress', 'in review', 'done') with an enum. Current approach invites hallucinated status values.
No pagination support on my-items despite 'limit' parameter. If a board has 1000+ items, response could blow context window. Tool description does not mention limit semantics (default 25, why?). No mention of next_cursor or offset.
Tool descriptions are 10-65 chars, below baseline avg of 194 chars. E.g., get-groups: 'Get all groups from a Monday.com board.' lacks context on when to call, what it returns, dependencies. Baseline: descriptions 10 - 1024 chars, avg 194.
No parameter descriptions for 'limit' (my-items) explain: What is default? Why 25? What's the max? Baseline: Every parameter must have a description explaining what it controls, format, range, and allowed values.
No input validation or constraint checking visible in tool implementations (only schema definitions shown). addTask.ts truncated but no evidence of validation for Monday.com API requirements (e.g., column ID format, valid field types).