Redmine MCP has clear verb-based naming (list_, get_, create_, add_, update_) and structured schemas with type definitions. However, descriptions are inconsistent in depth and quality. Most tool descriptions are brief (10-50 chars) and lack context on WHEN to use them or what happens on failure. Parameter descriptions are present but often minimal. Output schemas are partially documented in code but not formally declared. Error handling is absent, no guidance on recovery, retryable vs. fatal errors, or actionable error messages. The server lacks tool annotations (readOnlyHint, destructiveHint) despite having clear read/write semantics. Overall, this is a functional but below-average implementation.

• Add tool annotations: @mcp.tool(readOnlyHint=True) for list_* and get_* tools; @mcp.tool(destructiveHint=True) for create_issue, add_comment, update_wiki. This enables clients to apply safety policies and warn users before destructive operations.
• Expand tool descriptions to 100-200 characters. Example: 'list_projects() → List all Redmine projects with ID, name, and description. Use this first to discover available projects before querying issues. Returns up to 100 projects.' Include WHEN to use and what it returns.
• Add structured error handling: catch httpx.HTTPError, categorize as retryable (5xx, timeout) vs. user-fixable (4xx), and return actionable messages. E.g., 'Project not found: "my-project". Available projects: [list]. Call list_projects() to see all.'
• Document output schemas formally. Add a docstring to each tool showing the return type and key fields. E.g., 'Returns: {"id": int, "subject": str, "status": str, "url": str, ...}'. This helps LLMs plan multi-step workflows.
• Add parameter validation and enums. For 'status' param in list_issues, define enum=['open', 'closed', '*'] and validate input. For date params, validate YYYY-MM-DD format and return 'Invalid date format: expected YYYY-MM-DD, got "2024/01/15"'.