Loading ToolBench
An MCP server that integrates with monday.com to provide natural language access to boards, tasks, and project management data via the monday.com GraphQL API
The Monday.com MCP server demonstrates significant structural issues that place it firmly in the 'Poor' category. While the server does expose 11 tools with clear naming conventions (starting with action verbs like 'get_', 'query_'), the implementation lacks critical quality signals. Parameter schemas are present but minimal, most tools accept only string or no parameters with light descriptions. Tool descriptions are present but generic and often fail to explain WHEN to use each tool or dependencies between them. No output schemas are documented anywhere in the visible code. Error handling is absent, the code contains no try-catch blocks, no error categorization, and no recovery guidance for agents. The intent analysis logic (analyzeQuestion function) is clever but exists in the tool implementation, not exposed as schema constraints. Most critically, the API key is hardcoded in plain text in the source (SECURITY CRITICAL), and there is no evidence of input validation, pagination support, or response shaping. The tool composition is reasonable (each tool has a single responsibility), but the overall quality falls well below production baseline.
Retrieves the current status of a specific board including active items, columns, and project metadata
Retrieves all deliverables and milestones identified by keywords in task or board names
Retrieves all tasks assigned to the authenticated user
Retrieves all tasks that have passed their due date
Retrieves all recurring tasks identified by keywords like 'recurring', 'daily', 'weekly', or 'monthly' in task names
Retrieves detailed information about a specific task including owner, status, due date, and board context
Retrieves the owner or assignee of a specific task
No output schemas documented for any tool. Agents cannot infer what fields to expect in responses or plan chained calls.
Many tools (get_overdue_tasks, get_tasks_due_today, get_tasks_due_this_week, get_recurring_tasks, get_deliverables) have empty input schemas with no parameters at all, yet descriptions suggest they accept filters or options. Schema/description mismatch.
No error handling visible in source. No try-catch blocks, no error categorization (retryable vs fatal), no recovery guidance. Agents given raw errors with no next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Retrieves tasks filtered by specific status value such as 'on hold', 'working on it', 'done', 'blocked', etc.
Retrieves all tasks with due dates within the current week
Retrieves all tasks with due dates matching today's date
Queries monday.com boards and items based on natural language intent analysis, supporting filters for status, due dates, assignments, recurring tasks, and deliverables
No input validation. Parameters accepted as-is without checking type, length, enum membership, or format. Malicious or malformed input could break downstream API calls.
No pagination support visible. Tools return unbounded result sets from GraphQL queries (limit: 50, 100, 200). Large datasets will exceed context windows and degrade LLM reasoning.
Tool descriptions are vague and generic. Most are under 100 characters and do not explain WHEN to use the tool or how it differs from similar tools (e.g., get_tasks_due_today vs get_tasks_due_this_week). Agents cannot disambiguate.
Parameter descriptions are minimal or absent. The 'status' parameter in get_tasks_by_status lacks constraints (valid enum values). The description gives an example ('on hold', 'working on it', 'done', 'blocked') but this is not enforced as an enum, inviting hallucinated status values.
No dependency hints in descriptions. When query_tasks_by_intent requires userEmail, the description does not say 'if you do not have the email, call search_users first'. Agents must infer multi-step sequences.