Loading ToolBench

Reading the current corpus…

mcp-open-project MCP server · F · ToolBench

mcp-open-project

MCP server for OpenProject API integration, providing tools to interact with projects, work packages, and user information

<=2025-11-25STREAMABLE_HTTP4 tools

48/100

Definition Quality55

Protocol Readiness65

Supportability26

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Server has 4 tools with basic verb-noun naming (get_*). All tools have descriptions (10-60 chars, below the 194-char baseline). Input schemas are present with type definitions and descriptions for most parameters. However, output schemas are completely undocumented, tools return free-text strings rather than structured objects. No error handling guidance, no pagination support despite potentially large result sets, and no tool annotations. The fallback implementation shows manual tool registration, but schemas lack depth for production use.

Tools (4)

get_overdue_work_packagesread onlyauthsource verified55/100

Get work packages that are due within specified days

get_project_work_packagesread onlyauthsource verified60/100

Get work packages for a specific project with status filtering

get_projectsread onlyauthsource verified53/100

Get all projects from OpenProject

get_user_inforead onlyauthsource verified52/100

Get detailed information about a specific user

Issues (5)

CRITICALresponse-shaper ↗

All tools return unstructured free-text strings instead of structured JSON objects. LLMs cannot parse or chain results reliably. E.g., get_projects returns 'Projects retrieved successfully: {...}' as a string, not a typed object.

get_projectsget_project_work_packagesget_overdue_work_packagesget_user_info

CRITICALtool ↗

No output schema documentation. LLMs cannot predict what fields to expect, forcing them to parse unstructured responses and guess at downstream tool parameters.

get_projectsget_project_work_packagesget_overdue_work_packagesget_user_info

HIGHtool-description ↗

Tool descriptions are too short (30-45 chars vs. 194-char baseline). 'Get all projects from OpenProject' lacks context on when to use this vs. other discovery tools, what structure is returned, or prerequisites.

get_projectsget_user_info

Recommendations

Convert all tool return types from string to structured Pydantic models with typed fields. E.g., GetProjectsResponse with fields: projects: List[Project], total_count: int, etc.
Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it, and what structure it returns. E.g., 'Retrieve all OpenProject projects. Use this to discover available projects before fetching work packages. Returns project ID, name, status, and member count.'
Add limit and offset parameters to get_project_work_packages and get_overdue_work_packages. Document the default limit (10) and max limit (100) in descriptions.
Replace generic error messages with actionable recovery hints. E.g., 'Project not found. Try get_projects() to see available project IDs.' or 'API authentication failed. Verify OPENPROJECT_API_TOKEN is set.'
Add tool annotations: mark all four tools with readOnlyHint=true since they only read data and have no side effects.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

48/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	48	<=2025-11-25	v2