Loading ToolBench
A Model Context Protocol server for managing projects, tasks, threads, and evidence verification with SQLite persistence and budget controls
TaskHelix has 11 tools with basic naming (verb_noun pattern) and descriptions present, but quality is inconsistent. All tools have input schemas with types and descriptions visible in main.go. However, descriptions are terse (avg ~60 chars, well below the 194-char baseline), lack context on WHEN to use each tool, and omit error recovery guidance. Parameter descriptions are minimal. Output schemas are not documented, callers must infer structure from code. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Error handling is absent from tool definitions. Security concerns: set_budget and get_budget expose API keys as parameters (pattern:secret-injection violation). No pagination support despite list_projects returning unbounded results. Overall: functional but below production baseline.
Add a log entry to a project, optionally associated with a specific task
Create a new project with a PRD (Product Requirements Document) path and initial content
Create a new task within a project with title, description, and optional dependencies
Create a new conversation thread for a project with an intent and initial prompt
Get the current API call budget for an API key
Retrieve a project by ID with all its tasks, threads, and logs
List all projects with minimal information, ordered by most recently updated
API keys exposed as tool parameters (set_budget, get_budget). Credentials must use server-side secret injection; agent traces log all parameters, leaking secrets into logs and prompt history.
No output schemas documented. Callers must infer response structure from code. LLMs cannot plan downstream tool calls or extract required fields without explicit schema documentation.
Descriptions are terse (avg 40-50 chars vs 194-char baseline) and lack context. Missing WHEN to use each tool, prerequisites, and error recovery guidance. LLMs cannot reliably select the right tool.
list_projects returns unbounded results with no pagination support. Large result sets blow context windows and degrade LLM reasoning. No limit parameter, no offset/cursor, no total count.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Set or update the API call budget for an API key
Update a task's status, description, evidence, or dependencies
Update a thread's report, summary, or active status
Verify task evidence by checking file existence, git status, and other verification methods
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes, risking accidental data loss. update_task and delete operations lack safety markers.