Loading ToolBench
Comprehensive write-capable MCP server for OpenProject projects, work packages, attachments, relations, boards, users, watchers, and notifications
Strong tool naming (verb_noun pattern consistently applied) and comprehensive descriptions (avg 180 chars, well within 10-1024 range). All 11 tools have clear, actionable descriptions explaining WHAT, WHEN, and WHY. Input schemas are present and typed with Zod validation. However, output schemas are not formally documented, responses are JSON stringified without declared field structure. Parameter descriptions are thorough but some lack explicit format/constraint details (e.g., 'filters' array structure not fully specified). Error handling is minimal, no recovery guidance or categorization. Security is solid (no secrets in params, read-only hints present), but destructive operations (delete_project) lack confirmation patterns.
Return only the total number of projects matching native OpenProject filters. Use instead of list_projects when no project records are needed; this is read-only and minimizes response size.
Return only the total number of work packages matching native filters and an optional project. Use instead of search_work_packages when no task records are needed; all filters are combined with AND.
Create a project or subproject immediately. Use only after confirming a new project is wanted; parentId creates it below an existing project. Requires add-project permission and is not idempotent.
Permanently schedule deletion of a project by numeric ID. Use only after get_project verifies an explicit deletion target. OpenProject archives it immediately and deletes it asynchronously; this destructive action cannot be undone through this server.
Get one complete project by numeric ID or identifier. Use when the target is already known and full project fields or links are needed; use list_projects for discovery. This is read-only.
Output schemas not formally documented. Tools return JSON.stringify(value) without declaring field structure, types, or required fields. LLMs cannot plan downstream calls or extract specific fields reliably.
Destructive operation (delete_project) lacks confirmation or dry-run pattern. No recovery guidance in error responses. Agents cannot safely preview consequences before irreversible deletion.
Error handling is minimal. No error categorization (retryable vs user-fixable vs fatal), no recovery guidance, no actionable error messages. Raw API errors will confuse agents.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Get the complete HAL+JSON representation of one work package by numeric ID. Use after search when full descriptions, links, custom fields, or lockVersion are required; this performs no write.
Download one verified attachment from a work package. Use after listing attachments. Text files return readable text; binary files return an embedded base64 MCP resource. The call fails before or during transfer if maxBytes is exceeded and does not write to disk.
List visible projects with native filters, sorting, and pagination. Use this to discover project IDs or identifiers; use get_project when the target is already known and count_projects when only a total is needed.
List metadata for files attached directly to a work package. Use before get_work_package_attachment to verify the attachment ID and size; no file content is downloaded.
Search visible work packages with focused fields plus optional native filters, sorting, and pagination. Use this for discovery or lists; use get_work_package for the complete resource once an ID is known and count_work_packages for totals only.
Patch only the supplied fields on an existing project. Use for renaming, description, visibility, activation, or archival changes; omitted fields are preserved. Requires project administration permission.
Filter and sort parameter structures not fully specified. 'filters' is array of objects but field/operator/values constraints are not enforced at tool boundary. LLMs may pass invalid filter syntax.
Response size not capped. list_projects and search_work_packages accept pageSize up to 100 but no guidance on typical result cardinality or token cost. Large result sets risk context window exhaustion.