Loading ToolBench
MCP server exposing the Orkestrr project-management hierarchy (Bundles, Goals, Tasks) to AI agents
Orkestrr MCP demonstrates solid naming conventions (verb_noun pattern across all 19 tools) and comprehensive parameter descriptions. All tools have clear, actionable descriptions (avg ~120 chars). Input schemas are present with type definitions and parameter descriptions. However, output schemas are not documented in the source code, critical for LLM planning. Error handling lacks recovery guidance (no 'try X instead' patterns). Parameter constraints (enums for status values) are mentioned in descriptions but not formalized in schemas. Missing tool annotations (readOnlyHint, destructiveHint) despite clear read/write risk classification in the spec.
Add labels to a task (keeps existing ones). The API replaces the whole label set on update, so this reads the task's current labels and sends the union — existing labels are preserved.
Create a bundle under a project.
Create a goal under a bundle.
Create a new label in a project.
Create a task under a goal.
Get a single project's full detail by id (status, counts, dates, role).
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what fields does list_projects return? Does it include project_id for use in get_project?). Critical for tool chaining.
Status enums (draft, ready, in-progress, review, blocked, on-hold, done, cancelled) are documented in descriptions but not formalized as JSON Schema enums. LLMs cannot validate against constraints and may hallucinate invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
List bundles in a project. Search here BEFORE creating, to reuse an existing bundle instead of duplicating it.
List a project's estimation values (e.g. XS/S/M/L/XL or 1/2/3/5/8). Use this to resolve a size to the estimation_id needed by set_task_estimation.
List goals, filtered by bundle and/or project. Search here BEFORE creating, to reuse an existing goal. Provide at least bundle_id or project_id.
List a project's labels. Use this to resolve a name to a label id, or to check whether a label exists before creating one.
List a project's members. Use this to resolve a person to the user_id needed for `responsible` (bundle/goal) or `assigned_to` (task).
List Orkestrr projects you can access. Use this first to find a project's id.
List tasks, filtered by goal/bundle/project. Search here BEFORE creating, to reuse an existing task. Provide at least one of goal_id, bundle_id, or project_id.
Remove specific labels from a task, leaving the rest in place.
Set a task's estimation to an EstimationValue (see list_estimation_values).
Change a task's status. Status propagates up to goal/bundle/project. Valid: draft, ready, in-progress, review, blocked, on-hold, done, cancelled. Note: the API rejects moving to in-progress/done while the task has action items that are not all done.
Update a bundle's fields and/or status. Only provided fields change.
Update a goal's fields and/or status. Only provided fields change. Status propagates up to the bundle and project.
Update a task's fields, status, and/or assignee. Only provided fields change. Status propagates up to the goal, bundle, and project.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Server classifies tools as READ_ONLY or WRITE in spec but does not expose this via MCP tool annotations, limiting client-side safety checks and UI hints.
Error handling lacks recovery guidance. Descriptions mention prerequisites (e.g., 'bundle must be active') but do not guide LLM on what to do if a call fails. No 'try X instead' patterns or error classification (retryable vs user-fixable).
Pagination not visible in source. list_* tools accept search/status filters but no limit, offset, or page parameters. Large result sets could exhaust context window without pagination support.