Loading ToolBench
This is a Model Context Protocol server for Redmine
This Redmine MCP server has severe definition quality gaps across all four tools. Tool descriptions are extremely minimal (6-37 chars, well below the 10-1024 baseline and 194-char production average). Parameter descriptions are missing for list_issues and list_wiki_pages despite having required parameters. Schema definitions are incomplete: list_issues and list_wiki_pages provide only bare {"type":"object"} with no properties or required fields, making it impossible for LLMs to understand what inputs they accept. The read_* tools fare slightly better with one documented parameter each (id), but even those lack constraints (min/max), format hints, or usage guidance. No output schemas are documented, leaving LLMs unable to plan downstream calls. Tool names follow verb_noun convention (list_*, read_*) which is correct, but descriptions fail to explain WHAT the tool does, WHEN to use it, or what it returns, all critical for LLM selection and planning.
List all issues in project.
List all wiki pages in project.
Read issue in project.
Read wiki page in project.
list_issues and list_wiki_pages have bare {"type":"object"} schemas with no properties, required fields, or descriptions. LLMs cannot understand what parameters these tools accept.
All four tool descriptions are under 40 characters and provide no guidance on what the tool does, when to use it, or what it returns. Production baseline is 194 chars; these are 5-10x shorter.
No parameter descriptions for list_issues and list_wiki_pages despite having required parameters. Even documented parameters (id in read_* tools) lack constraints, ranges, or format hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | 2025-11-25+ | v1 |
No output schemas documented for any tool. LLMs cannot predict what fields to expect or what IDs/references to chain downstream calls with.
No pagination guidance. list_issues and list_wiki_pages lack limit, offset, or page parameters visible in schemas. If these tools return many results, they will blow token budgets.
No error handling guidance in tool definitions. LLMs will not know what to do if a tool call fails (retry? ask user? different tool?).