Loading ToolBench
A lightweight, self-hosted project management tool built for AI+Human collaboration with vibe coding in mind.
This server exposes a project management REST API as MCP tools. While tool names follow verb_noun conventions (get_projects, create_project, etc.), the implementation has significant gaps: parameter descriptions are present but minimal (10-50 chars), output schemas are not documented in the tool definitions, error handling is not visible in the schema specifications, and there is no evidence of validation guidance for constrained inputs like sprint status enums. The tools are clearly named and most parameters have basic type information, but lack the depth and structure required for reliable LLM-driven composition. Average per-tool score: 48/100.
API endpoint to create a new issue
API endpoint to create a new project
API endpoint to create a new sprint
API endpoint to delete an issue
API endpoint to delete a project
API endpoint to delete a sprint
API endpoint to get a specific issue by ID
Output schemas not documented. Tool definitions lack return type specifications, preventing LLMs from knowing what fields to expect or how to chain downstream calls. E.g., get_projects returns a list of project objects but the structure is not declared in the tool definition.
Destructive operations (delete_project, delete_sprint, delete_issue) lack confirmation or dry-run patterns. No mention of error recovery or undo steps. Agents could trigger data loss without safeguards.
Enum constraints for 'status' parameter in create_sprint and update_sprint are documented in descriptions ('Planned', 'Active', 'Completed') but not declared as formal JSON Schema enums. LLMs cannot reliably pick valid options without formal schema constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
API endpoint to get all issues. Optional query parameter: sprint_id to filter issues by sprint ID
API endpoint to get a specific project by ID
API endpoint to get all projects
API endpoint to get a specific sprint by ID
API endpoint to get all sprints. Optional query parameter: project_id to filter sprints by project ID
API endpoint to update an existing issue
API endpoint to update an existing project
API endpoint to update an existing sprint
No pagination or result-limiting parameters visible in list tools (get_projects, get_sprints, get_issues). Without limit/offset/page parameters, large datasets will bloat the context window and degrade LLM reasoning.
Error handling guidance is not visible in tool definitions. No indication of how LLMs should handle invalid project_id, missing sprints, or constraint violations. Stack traces or raw error codes will not guide agent recovery.
Parameter descriptions are brief (10-50 chars) and lack format constraints, range limits, or dependency hints. E.g., 'name' in create_project states '1-100 characters' in description but no minLength/maxLength in schema; 'project_id' lacks guidance on what to do if the ID is invalid.
No tool metadata (tool annotations) visible. Tools handling destructive operations do not declare destructiveHint=true; read-only tools do not declare readOnlyHint=true. This prevents agents from reasoning about side effects and safety.
Query parameter 'project_id' in get_sprints and 'sprint_id' in get_issues are marked as optional in descriptions but unclear if they filter (recommended) or are ignored. No documentation of behavior when both are provided or when neither is provided.