Loading ToolBench
MCP server that lets an AI model access issues, projects and notes in my-tracker on behalf of an authenticated user
30 tools with consistent naming (verb_noun pattern) and descriptions present. However, critical gaps: parameter descriptions are minimal or absent for many tools (e.g., 'include' in get_issue lacks detail on what 'comments', 'history', 'attachments' contain); output schemas are not documented anywhere in the source; error handling guidance is absent; no enum constraints on status/priority/type fields despite domain-specific vocabularies. Tool composition is reasonable (single responsibility), but parameter relationships (e.g., which fields are required when updating vs creating) are underdocumented. Descriptions average ~80 chars, below the 194-char baseline for A+ tools. No evidence of input validation rules or format constraints in parameter descriptions.
Add a stage to an existing board
Add an attachment to an issue
Add a comment to an issue
Create a new planning board for a project
Create a new issue in a project
Create a note, optionally attached to an issue
Get the architecture rules and restrictions for a project
Get detailed information about a specific board
Output schemas not documented. No tool returns a documented response structure. LLMs cannot plan downstream calls or extract required fields (e.g., what fields does get_issue return? Does it include issue_id for chaining to add_comment?).
Parameter descriptions are minimal or absent. 'include' in get_issue says 'Optional fields to include: comments, history, attachments' but does not explain what each field contains or when to use them. 'specification' in publish_project_architecture is 'Architecture specification JSON' with no schema or format guidance.
No enum constraints on domain-specific fields. 'type' (issue type), 'priority', 'status', 'visibility', 'segment' are free-form strings with no declared valid values. LLMs will hallucinate invalid values like 'super-urgent' or 'archived' instead of picking from the actual domain vocabulary.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Get detailed information about a specific issue
Get the published architecture map for a project
Get a specific project skill with its content
Get a specific project workflow with step-by-step instructions
Get the workflow skill file for installation in a repository
Get details about a specific workspace
Upload project-specific skills and subagents to my-tracker
Download and install all active project skills to the repository
List planning boards (sprints, cascades, timelines) for a project
List issues in a project, optionally filtered by text or module
Get project metadata including types, statuses, modules, and members
List available skills and subagents for a project
List available workflows for a project
List workspaces accessible to the authenticated user
Authenticate with my-tracker using OAuth browser flow
Clear the stored authentication session
Publish an architecture specification for a project
Move or place issues between board stages
Set a timeline segment for a timeline board
Update board stage status (e.g., mark sprint as complete)
Update an existing issue
Get the currently authenticated user's email and ID
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., create_issue may fail if title already exists (per server.ts Rule 1), but no error response guides recovery.
Parameter relationships undocumented. update_issue has 8 parameters (title, description, status, resolutionNotes, businessLogic, stepsToReproduce) but does not state which are required, which are mutually exclusive, or what combinations are valid. Per server.ts Rule 3, closing requires all three of resolutionNotes, businessLogic, description, but the tool definition does not enforce or document this.