Loading ToolBench
MCP Server for OpenProject – proxies the OpenProject REST API v3
Strong definition quality overall. All 23 tools have clear, verb-based names and documented descriptions. Input schemas are present and properly typed for all tools. Parameter descriptions are consistently provided. Output schemas are not explicitly documented in the visible source code, which is the primary gap. Pagination is well-implemented across list operations. Error handling patterns are present but could be more specific about recovery paths. The server demonstrates good adherence to tool naming conventions (list_, get_, create_, update_, search_, delete_, mark_) and composition principles.
Create a relation between two work packages. Types: relates, duplicates, blocks, precedes, follows, includes, partof, requires.
Create a new version (milestone) in a project.
Create a new work package in a project.
Delete a relation between work packages.
Get the currently authenticated OpenProject user. Useful to verify the API key is valid.
Get a single notification by ID.
Output schemas not documented in visible source code. Tool descriptions state what is returned (e.g. 'List all accessible OpenProject projects') but do not include structured field definitions, types, or pagination metadata structure.
Raw filter parameters accept JSON strings (e.g. 'JSON filter array, e.g. [{"status_id":{"operator":"o","values":[]}}]'). This defers validation to the API and forces LLMs to hand-construct JSON, increasing error rate. Consider wrapping common filters in dedicated parameters.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get a single project by ID or identifier string.
Get a single version (milestone) by ID.
Get a single work package by ID.
List notifications for the current user. Returns unread notifications by default.
List all available work package priorities (e.g. Low, Normal, High, Immediate).
List all accessible OpenProject projects. Supports pagination and filtering.
List relations for a work package.
List all available work package statuses (e.g. New, In Progress, Closed).
List all available work package types (e.g. Task, Bug, Feature, Milestone).
List OpenProject users. Requires admin or manage_user permission.
List versions (milestones). Optionally filter by project.
List work packages with optional raw filters, sorting, and pagination. Use search-work-packages for common searches instead.
Mark all notifications as read for the current user.
Mark a single notification as read.
Search work packages by common criteria. Builds OpenProject filters automatically. For advanced filtering use list-work-packages with raw filters.
Update an existing version. Fetches current lockVersion automatically.
Update an existing work package. Fetches current lockVersion automatically.
Error handling responses not visible in source. No recovery guidance documented for common failure cases (e.g. 'If project not found, call list-projects' or 'Invalid filter syntax, use predefined filters instead'). LLMs need explicit recovery paths.
Destructive operation 'delete-relation' has no documented confirmation or dry-run mechanism. Agents should have an opportunity to preview or confirm before irreversible deletion.
Parameter 'assigneeId' accepts both user ID and 'me' string, but this polymorphism is only documented in search-work-packages, not consistently across all tools. Similar polymorphisms (ID vs identifier for projects) should be explicitly declared in all tools that use them.
sortBy parameter documented generically as 'e.g. [["updated_at","desc"]]' across all list tools. Acceptable sortable fields should be enumerated or linked to a discovery tool (e.g. list-work-package-fields).