Advanced MCP server with hybrid OpenProject API integration, real-time webhooks, enhanced notifications, internal comments, negative lag dependencies, and AI-powered enterprise analytics (OpenProject 2024-2025 features)
Scoring was not performed
Output schemas not documented in source code. LLMs cannot determine what fields to expect from tool responses, forcing them to infer structure. This violates the 'document output schema' pattern and increases hallucination risk.
Ambiguous parameter types in compound parameters. 'filters' accepts 'string|array' and 'sortBy' accepts 'string|array' in listWorkPackages (src/tools.ts) without clear documentation of the expected structure. LLMs cannot determine whether to pass JSON string or native array, or what the array element format is.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 20 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Error handling and recovery guidance missing. Tools return success/failure indicators but do not guide the LLM on what to do on failure. E.g., setProjectVariables returns validation errors but does not suggest retry strategies or alternative actions.
Descriptions lack 'WHEN to use' context for enterprise tools. Tools like analyzeEVMWithBenchmark, getPortfolioAnalytics, and getProjectVariables have strong domain names but minimal guidance on prerequisites or when to invoke them relative to other tools. Descriptions should clarify when to call getProjectData first vs. getProjectStatus.
Some parameter descriptions are minimal or generic. 'Optional project ID' for projectId in listTypes lacks guidance on valid formats (string vs. numeric ID). 'Optional name/identifier substring match (client-side)' in listProjects is clear but does not explain the scope of the search.
No pagination or result-limit documentation. listWorkPackages, listQueries, and listProjects accept pageSize and offset but lack documentation of the maximum result set or default behavior when no limit is specified. Default pageSize=25 is good, but the max of 200 should be stated in the description.
No idempotency guarantees documented. createWorkPackageViaForm and attachToWorkPackage support dryRun for validation but do not guarantee idempotency on retry. LLMs retrying on timeout risk duplicate work packages or duplicate attachments.
Tool chain references incomplete. updateWorkPackage requires lockVersion but does not explain how the LLM obtains the current lockVersion. The pattern suggests tool outputs should include IDs and references downstream tools need, lockVersion should be part of listWorkPackages or getProjectData responses.