redmine-mcp-workflows

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools target distinct resources and actions, with clear descriptions. Some potential overlap exists between search and search_issues, and between add_comment and update_journal, but descriptions differentiate them. The bulk variants are clearly distinct from single operations.
Naming Consistency5/5
All tools follow a consistent 'redmine_verb_noun' pattern using imperative verbs (add, create, delete, update, list, etc.). No mixed casing or inconsistent conventions are present.
Tool Count1/5
With 81 tools, the server far exceeds the recommended range of 3-15. Even for a comprehensive Redmine integration, this number is excessive and overwhelms agents with choices, severely harming coherence.
Completeness5/5
The tool set covers virtually all CRUD operations for Redmine entities: issues, projects, groups, memberships, wiki, time entries, news, messages, etc. Bulk operations, search, file uploads, and attachments are included. Only minor admin operations are missing.
Average 4.1/5 across 81 of 81 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'Honors REDMINE_MCP_READ_ONLY' which is helpful, but does not disclose permissions, side effects, or whether update is partial. 'Partial' hints at behavioral nuance but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose. 'Partial.' is a separate line but could be integrated. No unnecessary words, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with 3 parameters and no parameter explanation, the description is incomplete. It does not explain what 'Partial' means or how the parameters affect the update. Output schema exists but description still lacks basic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no information about any of the three parameters (category_id, name, assigned_to_id). This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an issue category,' which is a specific verb and resource. It distinguishes from sibling tools like create and delete. However, the term 'Partial' is ambiguous but likely means partial update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The note about honoring READ_ONLY provides some context but no explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It only mentions 'Honors REDMINE_MCP_READ_ONLY' without explaining what this means (e.g., whether the tool is disabled in read-only mode). No details about authentication, idempotency, side effects, or response behavior are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the main purpose. The mention of READ_ONLY is a slight distraction but acceptable. There is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and is a mutation with two parameters, the description lacks completeness. It does not describe what the tool returns, any prerequisites, or potential errors. The minimal information leaves gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only says 'Update a group's name' which adds no semantic value beyond the parameter names 'group_id' and 'name'. The names are self-explanatory, but no additional constraints or formatting hints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update a group's name' which clearly specifies the action and resource, distinguishing it from other update tools like redmine_update_issue or redmine_create_group. However, it could be more explicit about what fields are updated (only name, as per schema), but it's sufficient for purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like redmine_create_group or redmine_delete_group. The description does not provide any context about prerequisites, permissions, or appropriate scenarios for updating a group's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it honors REDMINE_MCP_READ_ONLY, which provides a behavioral constraint. However, with no annotations provided, the description should disclose more, such as permissions required, side effects, or error conditions. The read-only note is helpful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences, with no unnecessary words. The purpose is front-loaded, and the behavioral note follows efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple tool and an output schema, the description need not explain return values, but it lacks essential context such as how to obtain valid user_id and group_id, and whether adding a duplicate user causes an error. The zero schema coverage and missing usage guidance make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does not define user_id or group_id, leaving the agent without context on what values to provide or where to find them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a user to a group,' which is a specific verb and resource. This distinguishes it from sibling tools like redmine_remove_group_user and redmine_create_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., whether the group and user must exist) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions honoring 'REDMINE_MCP_READ_ONLY', which hints at conditional behavior, but does not explain side effects, error conditions, or permission requirements. The tool is a mutation, yet no detail is given about the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and focuses on the core purpose. The first sentence is front-loaded with the essential action. The second sentence about the read-only flag adds some behavioral context but could be integrated. Overall, it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and 0% schema coverage, the description is too brief. It fails to cover return values, error scenarios, authorization needs, or how this tool relates to siblings. The presence of an output schema is not utilized in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It only implies the role of parameters via the purpose statement, but does not explain what 'group_id' and 'user_id' represent, how to obtain them, or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a user from a group'), using a specific verb and resource. It distinguishes this tool from the sibling 'redmine_add_group_user' which performs the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'redmine_add_group_user'. There are no instructions on prerequisites, such as the user needing to be a member of the group, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it updates a version (implying mutation) and returns the refreshed version. It also mentions the partial update behavior and the REDMINE_MCP_READ_ONLY flag. However, it lacks details on authentication, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, front-loading the main purpose. Every sentence adds value (purpose, partial update nature, return value, read-only flag). There is no trivial information, but it could be structured better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 0% schema coverage, and no output schema description (though output schema exists), the description is incomplete. It does not explain which fields are required (only version_id is required per schema), nor does it provide examples or constraints. The output schema is not described but exists separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter meanings or formats. The only hint is 'Partial — only supplied fields are sent,' which implies that the properties are updatable fields, but it does not compensate for the lack of individual parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a version,' which identifies the specific verb and resource. It returns the refreshed version, adding clarity. However, it does not explicitly differentiate from other update tools like redmine_update_issue, though the context of versions is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it notes that only supplied fields are sent (indicating partial updates) and that it honors REDMINE_MCP_READ_ONLY. It does not specify when to use this tool versus alternatives (e.g., redmine_create_version) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses 'partial' update and honoring read-only flag, but omits details like success/error responses, permissions, or side effects. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Purpose is front-loaded. However, brevity sacrifices important information given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description does not cover return values. Lacks safety/permission context for a mutation tool with 7 parameters and no schema descriptions. Insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no value for parameters beyond generic 'partial' statement. None of the 7 parameters are explained, leaving the agent to rely solely on titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update a time entry' with verb and resource. Distinguishes from sibling tools like redmine_create_time_entry and redmine_delete_time_entry by specifying 'partial — only supplied fields are sent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for modifying existing time entries, but no explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned. The description lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Permanent' and mentions the read-only flag. It lacks details like required permissions, side effects on related data, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loading the core action and permanence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation, the description is incomplete. It does not explain the return value (though an output schema exists), confirm deletion is irreversible beyond a single word, or cover edge cases like non-existent IDs. Given the simplicity, more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (news_id) with 0% coverage. The description does not add any meaning, format, or context for this parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'news entry', and adds 'Permanent' to indicate irreversibility. Among sibling tools like redmine_update_news and other delete tools, it is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Honors REDMINE_MCP_READ_ONLY', which gives a condition for when the tool might be disabled. However, it does not explicitly state when to use it versus alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses two key behaviors: partial update (only supplied fields are sent) and honoring the REDMINE_MCP_READ_ONLY environment variable for read-only mode. This adds significant context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the purpose. However, it omits essential details about parameters, making it under-specified. Conciseness is good but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema coverage, and no annotations, the description is incomplete. It covers basic behavior but lacks parameter descriptions, prerequisites, or error handling. An output schema exists but is not referenced. The description does not fully compensate for missing structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not explain any parameter. It only notes that only supplied fields are sent, but fails to define the meaning of title, news_id, summary, or description. The description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'a news entry'. It specifies partial update behavior, distinguishing it from create or delete operations. Sibling tools include redmine_create_news and redmine_delete_news, so the purpose is specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies usage for modifying an existing news entry, but lacks when-not-to conditions, prerequisites, or comparisons with other update tools. The description does not leverage sibling context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions that inherited memberships can't be deleted and that it honors a read-only flag, but lacks details on side effects, error handling, or idempotency. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose and key limitation. No unnecessary words; efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but description doesn't explain return values. For a simple deletion, the description covers essential purpose and a constraint, but lacks details on response behavior or error cases. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'membership_id' has no description in schema (0% coverage). Description does not elaborate on its meaning, format, or constraints, forcing reliance on the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action 'remove' and resource 'project membership'. Distinguishes from siblings by specifying inheritance constraint which differentiates from other membership tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs. alternatives. Only mentions a limitation (inherited memberships cannot be deleted) but does not provide context for when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds two behavioral traits: deletion is permanent, and the tool honors the REDMINE_MCP_READ_ONLY flag. However, it does not disclose side effects (e.g., cascade deletion of replies), permission requirements, or error states. Since no annotations are provided, the description carries the full burden, and it partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a line, no fluff. It could benefit from a slightly more structured format (e.g., bullet points for key facts), but overall it is efficiently written and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation (one required param, output schema present), the description is minimally complete. It covers permanence and read-only mode, but omits details like error handling, permission requirements, or the impact on related entities. For such a straightforward tool, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is message_id (integer). Schema coverage is 0%, and the description does not elaborate on its meaning, format, or constraints. The parameter name is self-explanatory, but the description should at least confirm that it refers to the ID of the forum message to delete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete a forum message' with the qualifier 'Permanent,' clearly indicating the action and resource. It distinguishes from sibling tools like redmine_create_message or redmine_reply_message, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the tool name implies deletion, the description lacks context such as prerequisites, alternative approaches (e.g., using redmine_delete_issue for issues), or conditions under which deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose side effects (e.g., whether creation triggers notifications), permissions required, or what happens on success. The mention of 'Honors REDMINE_MCP_READ_ONLY' is a constraint but does not describe behavioral traits like mutation or its consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear opening sentence and a well-organized list of arguments. No redundant information, though the list format is straightforward and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite covering parameters well, the description lacks key context: it does not mention return values (even though an output schema exists), error conditions, or integration with other tools. For a creation tool, knowing the response format (e.g., returns new project object) is important.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description completely compensates by explaining every parameter: required fields (name, identifier with format), optional fields with defaults (is_public, parent_id), and examples (enabled_module_names). This is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a new project,' which is a clear verb+resource statement. It distinguishes this tool from sibling tools like redmine_delete_project, redmine_update_project, and other create tools (e.g., redmine_create_issue) by focusing on project creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. With many sibling tools for project management (update, delete, archive), the description should clarify that this is only for creation and not for modifications, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses two key behaviors: read-only and admin-only access. It does not cover other aspects like rate limits or data freshness, but the provided info is sufficient for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the purpose, and lists key return fields. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately covers the main points: admin restriction, read-only nature, and sample return fields. It could mention pagination or ordering, but for a simple read-only list, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description need not add parameter info. The baseline is 4, and the description meets it without adding redundant detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists custom field definitions and names the resource. It specifies 'admin only', which adds context. However, it does not differentiate from sibling list_* tools, which all follow a similar pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'admin only', indicating a prerequisite. There is no mention of when to use this tool versus alternatives (e.g., other list tools), nor any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Read-only' and 'Requires admin privileges', but does not disclose pagination behavior, rate limits, or data format. With no annotations, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single sentence plus parameter list. Could integrate 'Read-only' and 'admin only' more efficiently, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, auth, and parameters well. Lacks usage guidelines and behavioral details, but output schema exists to explain returns. Adequate but missing context about siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description compensates fully by explaining each parameter, including valid values for status and defaults. Highly informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource and scope 'List users (admin only)', but lacks differentiation from siblings beyond name. Parameter details reinforce purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives like list_groups or list_projects. Only mentions 'admin only' for auth context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It mentions 'Honors REDMINE_MCP_READ_ONLY,' implying conditional behavior, but does not disclose permission requirements, side effects, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two sentences and args list, front-loaded with purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return value explanation is unnecessary. However, description lacks prerequisites (e.g., existence of board/topic), error conditions, or detailed behavioral context for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It lists all three parameters with brief explanations (e.g., 'the parent message/topic id' for topic_id), adding some meaning beyond the schema but not enough to fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reply to an existing forum topic,' specifying the verb and resource. This distinguishes it from sibling tools like redmine_create_message, which creates new topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (board_id must belong to topic) but does not explicitly state when to use this tool vs alternatives like redmine_create_message. No when-not or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the read-only flag but does not disclose other behavioral traits such as whether the action is reversible, error handling, or side effects beyond basic mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, then a compact args list, and one line for the read-only flag. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and the presence of an output schema, the description covers purpose, parameters, and a behavioral constraint. However, it does not describe return values or error conditions, leaving some gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining each parameter: project_id (id or slug), user_id (user or group id), role_ids (list of role ids, required non-empty). This adds meaningful context beyond the schema's type-only fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add a member to a project,' which is a clear, specific verb+resource. It distinguishes from siblings like redmine_remove_membership and redmine_update_membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes parameter requirements (role_ids is required and non-empty) and notes the REDMINE_MCP_READ_ONLY constraint, but it does not provide guidance on when to use this tool versus alternatives like redmine_add_group_user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose permissions, immediate effect, or whether notifications are sent. It only mentions a read-only flag, which is minimal for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: six lines, front-loaded purpose, clear bullet-like listing of parameters. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (though not shown), the description is adequate but misses potential constraints or validation details. Suitable for a simple creation tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by clarifying that 'project' accepts numeric id or slug, and explains optional vs required fields. Covers all 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a news entry on a project.' This is a specific verb and resource, distinguishing it from sibling tools like redmine_create_issue and redmine_create_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions that it honors REDMINE_MCP_READ_ONLY, implying it won't work in read-only mode, but does not provide explicit when-to-use or alternative comparisons like redmine_update_news.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares 'Read-only' which is a behavioral trait, but no mention of auth, rate limits, or side effects. With no annotations, more context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded with purpose, then parameter details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values are fine, but lacks details on error handling, pagination, or ordering. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'issue_id' parameter as a numeric Redmine issue ID, adding semantics beyond the schema type (integer). Although schema coverage is 0%, this compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns structured journal entries for an issue, with a specific verb and resource. It is distinct from siblings like 'redmine_get_issue' (issue details) and writing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'redmine_update_journal' or searching. Lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions honoring REDMINE_MCP_READ_ONLY, a useful behavioral trait. However, it does not elaborate on side effects (e.g., replacing roles), error states, or permission requirements, leaving gaps given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a structured Args block, front-loading the key action. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with an output schema, the description covers purpose, parameter sources, and read-only behavior. It is nearly complete, but missing explicit mention of role replacement behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds critical meaning: membership_id is numeric and sourced from list_memberships, role_ids is required and non-empty. This significantly aids agent understanding, though role_ids format (integer list) is implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update a membership's roles,' clearly indicating the verb and resource. This distinguishes it from add/remove membership tools, though it could be more specific about replacing roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying roles of an existing membership, but does not explicitly contrast with sibling tools like redmine_add_membership or redmine_remove_membership, nor does it provide when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is read-only and returns role with permissions, but it does not disclose error behavior, authentication requirements, or rate limits. For a simple fetch, it is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first defines the action and output, the second declares read-only. No unnecessary words, information is front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with an output schema (not shown), the description adequately covers the main purpose and output. It does not cover error scenarios or prerequisites, but given the low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (role_id) with 0% description coverage. The description mentions 'by id' but does not explicitly describe the parameter or add constraints beyond the schema. Since the parameter is simple and self-evident from the tool name and description, the added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a role by id, including its permissions list.' It specifies the action (fetch), the resource (role), and the output (permissions list). It is distinct from sibling tools like redmine_list_roles by focusing on a single role by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description indicates it is read-only and fetches a single role, it does not provide explicit guidance on when to use this tool versus alternatives like redmine_list_roles to list all roles. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It correctly marks the tool as 'Read-only' and specifies the return structure. However, it omits details like pagination, error handling, or rate limits, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences plus a structured args/return block. Every sentence is meaningful and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the existence of an output schema, the description covers the essential behavior: listing boards with a specified project ID and returning a defined structure. It could mention pagination or ordering, but these are implicit for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, so the description must clarify parameter meaning. It describes project_id as 'numeric id or identifier slug', adding valuable context beyond the schema's string type. This is sufficient for one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'forum boards for a project', making the tool's purpose unambiguous. It is distinct from sibling list tools like redmine_list_projects or redmine_list_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The description only specifies that it lists boards for a project, without contextual flags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels the operation as 'Read-only', which is valuable since no annotations are provided. However, it lacks additional behavioral context such as required permissions, rate limits, or data freshness, though for a simple list operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. It front-loads the purpose and includes the parameter clarification and safety note with zero fluff, making it efficient for parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is only one required parameter and an output schema exists, the description covers the essential aspects: purpose, parameter semantics, and safety. It could mention the output format or that it returns a list, but the output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds significant value by clarifying that project_id accepts a 'numeric id or identifier slug', which is not present in the schema's string type alone. This helps the agent format the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List issue categories for a project', specifying the verb 'List' and the resource 'issue categories' within a project scope. This differentiates it from other list tools and makes the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like redmine_list_custom_fields or redmine_list_enumerations. It does not mention contexts, prerequisites, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Read-only' and specifies the return format (id and name), which are important behavioral traits. However, it does not mention error conditions (e.g., issue not found) or permissions, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the main action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return format (id, name) and states read-only. Given an output schema exists, the description is largely complete, but lacks error handling or prerequisite info (e.g., issue must exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 0%, the description adds context that the tool is for an issue, implying issue_id identifies the issue. This minimally compensates; the parameter is simple and self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the current watcher list for an issue' with specific verb and resource, and distinguishes from sibling tools like redmine_add_watcher and redmine_remove_watcher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like redmine_add_watcher or redmine_remove_watcher. The read-only hint is implicit but not directly stated as a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole behavioral source. It mentions honoring REDMINE_MCP_READ_ONLY, which adds a safety constraint, but does not disclose behaviors like file size limits, overwrite policy, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a brief purpose line followed by a clean parameter list. It is well-structured and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the parameter descriptions, the tool is fairly well-covered. However, missing details on error conditions, file size limits, or what happens if the file already exists leave some gaps. The read-only behavior note is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter's meaning and optionality. It adds valuable context such as path restriction for file_path and version association.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Upload' and the specific resource 'file to a project's Files section'. It distinguishes this tool from siblings like redmine_upload_attachment which likely targets other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as redmine_upload_attachment. It implies usage for project files but lacks conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Read-only' and describes the output fields (id, issue_id, issue_to_id, relation_type, delay). However, it does not disclose potential behavioral traits like pagination, rate limits, or authentication requirements. Since no annotations are provided, the description carries the full burden, and this information is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one required parameter and an output schema (not shown but present), the description covers the essential elements: what the tool does, the parameter, and the structure of the response. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context to the issue_id parameter by stating 'numeric Redmine issue id', which is slightly more informative than the schema's 'Issue Id' (type integer). With schema coverage at 0%, the description partially compensates but does not fully explain the parameter's format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all relations on an issue (both directions)', specifying the verb 'list', resource 'relations', and scope 'on an issue'. This distinguishes it from sibling tools like redmine_add_relation and redmine_remove_relation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing relations before modifying, but does not explicitly state when to use this tool vs alternatives like redmine_add_relation or redmine_remove_relation. There is no guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses reversibility and honors read-only flag, but does not detail side effects or data changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: two sentences for purpose and parameter, no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a one-parameter tool with output schema. Covers version, reversibility, and a configuration note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by specifying 'numeric id or identifier slug' for project_id, adding meaning beyond the string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool archives a project, specifies the Redmine version (5.0+), and notes reversibility. It distinguishes from siblings like 'delete' or 'unarchive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions reversibility and the read-only flag, but does not explicitly provide when-to-use vs alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'Honors REDMINE_MCP_READ_ONLY' and 'admin only', which are behavioral traits. However, it does not disclose error handling, idempotency, or return behavior. No annotations exist to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence description plus bullet list of arguments. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and existence of output schema, description covers permissions, parameters, and a behavioral flag. Missing error handling but sufficient for a simple create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description clarifies that 'name' is required and 'user_ids' is an optional list of initial members, adding meaning beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a group' with verb and resource, and 'admin only' adds scope. Distinguishes from sibling tools like redmine_update_group or redmine_delete_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when creating a new group (admin only), but lacks explicit alternatives or when-not-to-use instructions. No mention of when to use redmine_update_group instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions 'Honors REDMINE_MCP_READ_ONLY' which gives a behavioral insight, but does not disclose other aspects like required permissions, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and an Arg list. It front-loads the purpose and efficiently covers parameters without unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and the read-only behavior. An output schema exists to handle return values, so the description is adequate for a simple creation tool. Could mention success output briefly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning: project_id as numeric id or slug, name as required, assigned_to_id as optional with 0 meaning none. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create an issue category on a project,' which is a specific verb+resource. This distinguishes it from sibling tools like 'redmine_create_issue' or 'redmine_create_project.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose but lacks explicit guidance on when to use it versus alternatives (e.g., redmine_update_issue_category). No when-not-to or contrast with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that deletion is permanent and honors a read-only mode. It also explains the reassign_to_id parameter behavior. This adds value beyond the schema and no annotations are present to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. The purpose is front-loaded, and the parameter details are clearly structured in a list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema exists), the description covers the action and key parameter behavior. It lacks prerequisites or error handling, but is sufficient for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides essential meaning: category_id is numeric, reassign_to_id is optional with a special value '0' for no reassignment. This clarifies usage beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an issue category. Permanent.' which is a specific verb+resource combination. The name itself is also clear, and it distinguishes from siblings like update or create issue category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool over alternatives (e.g., update_issue_category). It mentions 'Honors REDMINE_MCP_READ_ONLY' but that is a constraint, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates that the tool creates a version (mutation) and mentions 'Honors REDMINE_MCP_READ_ONLY,' which hints at a read-only gate. However, it does not detail authentication requirements, success/failure responses, or other behavioral traits like rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with an 'Args' header and a clear bullet-like list. Every line adds value, and there is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, and an output schema, the description covers the parameters well and mentions the read-only flag. The return value is not explained, but the output schema handles that. It could be more complete by describing error states, but it is sufficiently informative overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It thoroughly explains each parameter: project id/slug, name required uniqueness, optional description, status enum, due_date format, sharing enum, and optional wiki_page_title. This adds substantial meaning beyond the schema's basic type and title fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a version on a project.' It is a specific verb-resource pair. Among siblings like redmine_get_version, redmine_update_version, redmine_delete_version, and redmine_list_versions, this tool is uniquely identified as creation, making differentiation straightforward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives; however, the context of sibling tools implies that this is for creating versions while others handle update, delete, or retrieval. No prerequisites or usage conditions are mentioned beyond honoring REDMINE_MCP_READ_ONLY, which is a behavioral flag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses permanent deletion and respect for read-only configuration, which are critical behavioral traits. Additional details like permission requirements could further improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence states the core action, the second adds an important constraint. Every word is meaningful and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers permanence and configuration awareness. However, it omits error conditions, return value (output schema exists but not described), and prerequisites like authentication or permissions. Still, it is sufficient for a simple deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the tool description adds no meaning to the 'time_entry_id' parameter beyond its name. The parameter is obvious, but for a 0% coverage tool, more detail (e.g., format, source) would be expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and resource (time entry), and uses 'Permanent' to emphasize irreversibility. It distinguishes well from siblings like create/update time entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions permanence and read-only flag, giving usage context. It implies this tool is for irreversible deletion, but does not explicitly state when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states 'Read-only reference data', which informs the agent that the tool has no side effects. This is adequate for a simple list tool, though no mention of rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently conveying purpose and nature. No filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters and an output schema, the description is complete. It specifies 'all' statuses and the read-only nature. No further behavioral details are necessary given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is high (100% by default). The description adds no param details, but baseline is 4 per scoring rules for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all issue statuses including their is_closed flags. The verb and resource are specific, and it distinguishes itself from mutation tools by noting read-only reference data. It is unambiguous among sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus other list tools (e.g., redmine_list_trackers, redmine_list_custom_fields). It only states what it does, with no when-not-to or alternative considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only,' indicating no side effects. Since no annotations are provided, this conveys the behavioral trait adequately, though additional details (e.g., output format) are covered by the existing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words; each sentence adds value. The description is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output schema, the description is fully sufficient. It covers the purpose and safety without needing elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The baseline for 0 parameters is 4, and the description adds no further parameter information, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('roles'), clearly stating it retrieves all roles. It distinguishes from sibling tools like 'redmine_get_role' which targets a single role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus tools like 'redmine_get_role' for a specific role, or when filtering is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavior. It discloses limit capping at 100 and offset skipping, but does not mention read-only nature or ordering. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses a clear bullet-like structure, and each sentence provides unique information. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return format is covered. The description explains parameters well but could mention ordering or default pagination behavior. Still, it is sufficiently complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter description coverage. The description explains all 8 parameters with details (e.g., '0 for none', date format YYYY-MM-DD, cap at 100). This adds substantial value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List time entries with optional filters', using a specific verb and resource. It distinguishes well from sibling tools like create/delete/update time entries and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description details parameters but does not explicitly state when to use this tool versus alternatives (e.g., other list tools). The context of siblings implies purpose, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses a side effect: 'Cached entries are populated...' which adds behavioral context. However, it does not mention idempotency, authentication needs, or other traits beyond what is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. The purpose is stated first, followed by additional detail on output and side effects. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (context signal), the description explains return structure (id, name, default status, description) and notes cache side effect. For a simple, no-param list tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description naturally adds no param info. Baseline for 0 param is 4. The description does mention return fields, but that is not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all trackers configured on the Redmine server.' The verb 'list' and resource 'trackers' are specific. Among siblings, there is no other tool listing trackers, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to see all trackers but does not provide explicit guidance on when to use versus alternatives (e.g., redmine_describe_tracker for a single tracker). No when-not-to-use or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively covers key behaviors: substring search semantics, status token handling (open, closed, *), saved query merging, pagination with capped limit, and return shape. Non-critical aspects like error handling or auth are omitted, but the core transparency is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line summary followed by clear bullet points for each parameter and a return structure specification. No redundant information; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters and return value, with details on merging semantics and limit cap. However, it could mention default behavior when no parameters are provided or error cases (e.g., invalid query_id). Overall, fairly complete for a search tool with minimal complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining each parameter's purpose, format, Redmine-specific behavior (e.g., query_id merges other filters), and constraints (limit capped at 100). This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search/list issues with optional filters and pagination,' identifying the verb and resource. However, it does not explicitly differentiate from sibling tools like redmine_get_issue or redmine_search, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through parameter descriptions (e.g., search with subject substring, filter by project/status), but no direct guidance is given on when to choose this tool over alternatives like redmine_get_issue or redmine_list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool honors 'REDMINE_MCP_READ_ONLY', which is a behavioral flag that may prevent mutation in read-only mode. However, it does not mention other traits like required permissions, reversibility, or effects on child resources, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two lines plus args) with no unnecessary words. The primary action is front-loaded, followed by parameter details and a behavioral note. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description covers version requirements and a behavioral constraint. However, it omits the output format (though an output schema exists) and error conditions (e.g., what if project is not archived). Overall, it is mostly complete but could include a note on failure scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by stating that project_id can be a 'numeric id or identifier slug', adding meaning beyond the schema's plain string type. This is critical for correct invocation and is well-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Unarchive a previously archived project' with a specific verb and resource. It distinguishes itself from the sibling 'redmine_archive_project' by being the inverse operation. Additionally, it specifies a version requirement (Redmine 5.0+), adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context implies use when reactivating an archived project, but no explicit when-to-use or when-not-to-use guidance is provided. There is no comparison with siblings (e.g., redmine_archive_project) to clarify alternative usage, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses that the tool is a thin wrapper over `redmine_update_issue` and honors a read-only flag. It does not describe any side effects, permissions required, or the return value (though output schema exists). The disclosure is adequate but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a structured format with Args section. Every sentence adds value: defining the action, explaining parameters, noting the wrapper relationship, and mentioning the read-only flag. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params) and the presence of an output schema (not shown), the description covers the essential behavior: assignment, clearing, wrapper context, and read-only respect. It could additionally mention error conditions or expected output, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It clarifies both parameters: `issue_id` is numeric, `version_id` is numeric and passing 0 clears the version. This adds essential meaning beyond the schema's type/title. It does not explain where to find `issue_id` or `version_id`, but the context is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Assign (or clear) an issue's target version.' It specifies the resource (issue) and the field (target version). It also distinguishes itself from the sibling tool `redmine_update_issue` by noting it's a thin wrapper that specifically sets `fixed_version_id`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to pass `version_id` as 0 to clear the version, and notes that it honors `REDMINE_MCP_READ_ONLY`, indicating a read-only mode. However, it does not explicitly state when this tool should be used over the more general `redmine_update_issue` or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states that the tool creates a new forum topic and mentions it honors the REDMINE_MCP_READ_ONLY environment variable, which is a behavioral trait. However, it does not disclose other behaviors like authentication requirements or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence followed by a clear list of parameters. No unnecessary words, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be described. The description covers the tool's purpose, parameters, and a behavioral constraint (read-only honor). It is sufficient for a simple creation tool, though it lacks details on success/failure responses that might be in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for parameters (0% coverage), but the description lists all three parameters with functional explanations: board_id as numeric, subject as required, content as optional. This adds significant meaning beyond the schema's type and title alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new forum topic on a board' uses a specific verb and resource, clearly indicating the tool's function. This distinguishes it from siblings like redmine_reply_message (for replies) and redmine_create_news (news items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not provide guidance on when to use it over alternatives, nor does it specify prerequisites or exclusions. Usage is implied by the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states permanent deletion and honors read-only flag, which is critical behavioral info. No annotations present, so description carries this burden effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear front-loading and no waste; parameter noted concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter, and behavioral traits adequately; output schema likely covers return values, so no further detail needed for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds format details (numeric id or slug) to the project_id parameter, compensating for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a project permanently with all its data, distinguishing it from sibling tools like redmine_archive_project or redmine_delete_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns about destructiveness and mentions the read-only flag, but does not provide guidance on when to use this vs alternatives like redmine_archive_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses permanence, no soft-delete, the 422 error condition, and respect for read-only mode. These are key behavioral traits. It could also mention required permissions or cascade effects, but currently provides solid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: the first states core purpose, second gives error guidance, third notes read-only handling. Each sentence is essential and front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and an output schema, the description covers purpose, permanence, error handling, and a constraint. It lacks mention of prerequisites like version existence or permissions, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'version_id' is described as 'by id' in the description, but this adds minimal value beyond the schema. With 0% schema coverage, the description could elaborate more on how to obtain the id or its format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the action: 'Delete a version by id.' It also specifies it's permanent with no soft-delete, distinguishing it from other version operations like create or update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on handling a common error (422) and suggests a workaround using redmine_assign_issue_to_version. It also notes that it honors REDMINE_MCP_READ_ONLY. However, it does not explicitly contrast with other deletion tools or state prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the reactive learning of workflow graph from prior API calls, a key behavioral trait. No side effects or idempotency mentioned, but adequate for a read-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is reasonably concise with front-loaded purpose. The explanation of reactive learning adds value but could be slightly trimmed. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description doesn't need to detail return format. It covers tracked info components and learning mechanism. Some aspects like availability of statuses/priorities being static vs learned are implied but not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains both parameters: tracker with example format and include_observations with default and effect. Adds meaning beyond schema by describing the learned workflow graph context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an 'enriched schema' for one specific tracker, distinguishing it from sibling tools like redmine_list_trackers. It specifies the content: available statuses, priorities, and optional workflow graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for detailed tracker info but does not explicitly contrast with siblings or provide when-not-to-use guidance. No mention of alternatives like redmine_list_trackers for summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses important behavioral traits: validation of downloaded byte count, surfacing short reads as 'attachment_size_mismatch', path restrictions with symlink resolution, and read-only safety. It could mention authentication or rate limits, but overall it's transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an Args section and paragraphs. It is informative but slightly verbose; every sentence adds value. A more concise version could omit the docstring formatting, but it remains clear and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema present but not described), the description covers primary behaviors: parameter details, validation, and safety. It lacks explicit description of return values or output format, but the mention of error surfacing partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter: attachment_id (numeric, visible in issue payloads), save_to (path with parent directory must exist and be under allowed directories), overwrite (default false, refuses overwrite). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads an attachment by ID to a path-restricted location. It specifies the action (download), resource (attachment by id), and target (path-restricted). This distinguishes it from sibling tools like redmine_upload_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context like path restrictions and overwrite behavior but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or which sibling tools are better suited for different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares 'Read-only' and mentions the possible return value 'version_not_found', which is good for a read operation. With no annotations, it provides sufficient behavioral context for a simple fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the key action and output, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with an output schema present, the description covers the return fields and error case adequately. Could mention that the output schema contains the listed fields, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds 'by id' but the parameter name 'version_id' is already clear. Schema coverage is 0%, so the description could provide more detail about the parameter, but the parameter self-explains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool fetches one version by ID, distinguishing it from siblings like redmine_list_versions (multiple) and redmine_create_version (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need a specific version by ID, but does not explicitly state when not to use it or suggest alternatives like redmine_list_versions for searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only', which is a key behavioral trait. It also describes the return value (page details or wiki_page_not_found). No annotations provided, so the description carries the full burden, but it covers safety and non-destructive nature adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured with a brief introductory line and bullet-pointed parameter explanations. It is clear without being verbose, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no enums, output schema exists), the description covers the core functionality, parameter details, and return information. It is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema names: project is explained as numeric id or slug, title as URL-encoded automatically, version as historical version. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a wiki page' which is a specific verb+resource. It also mentions an optional historical version, distinguishing it from sibling tools like create_wiki_page, update_wiki_page, and delete_wiki_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While it implies use for fetching specific wiki pages, there is no mention of when not to use or reference to sibling tools for different operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool is 'Read-only,' which implies no side effects. However, with no annotations provided, the description carries the full burden and lacks further behavioral details such as authentication requirements, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first line states purpose, then a parameter explanation, then usage hint. Every sentence adds value with no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and a single optional parameter, the description covers the key aspects. Minor missing details like the definition of 'visible' queries could be added, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the parameter, but the tool description explains that project_id is optional, can be an id or slug, and that empty returns all visible queries. This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List available saved queries,' which is a specific verb and resource. It distinguishes from sibling tools like redmine_list_issues or redmine_search_issues by focusing on saved queries, and further clarifies that the returned IDs can be used with redmine_search_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on how to use the tool: listing queries and then using the IDs to execute them. However, it does not explicitly state when not to use this tool or compare it to alternatives like directly searching issues without a saved query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Read-only' and lists return fields, adding transparency. However, it does not mention potential pagination, response limits, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with no wasted words. It conveys the purpose, argument details, and return field overview in a few sentences, maintaining good readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, has output schema), the description covers the main aspects. It lacks details on error handling or pagination but is largely complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description adds value by specifying that 'project' accepts a 'numeric id or identifier slug,' clarifying the accepted format beyond the schema's string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all versions / milestones defined on a project,' providing a specific verb and resource. It clearly distinguishes from sibling tools like redmine_get_version (singular), redmine_create_version, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the required project parameter format (numeric id or slug). While it implies usage for listing all versions, it does not explicitly contrast with alternatives like redmine_get_version for single version retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses important behavioral details: error semantics (404 meaning watcher not on list vs issue not found) and honors a read-only flag ('REDMINE_MCP_READ_ONLY'). This adds valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and front-loaded with the main purpose. Every sentence serves a purpose: the one-liner for action, the args listing, and the error/flag note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with two parameters and no nested objects, the description covers the main purpose, parameter types, error handling, and a read-only mode. The output schema exists but is not shown, so return values are not described. Still, the description is largely complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides brief explanations for each parameter ('numeric Redmine issue id', 'numeric user id to remove'), which adds basic meaning but lacks constraints or additional context. This meets the baseline but does not excel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a user from an issue's watcher list') with a specific verb and resource. It distinguishes itself from sibling tools like 'redmine_add_watcher' and 'redmine_list_watchers' by name and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool (to remove a watcher), and the sibling list provides context. However, it does not explicitly state when not to use it or mention alternatives beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool is idempotent on the Redmine side and honors the REDMINE_MCP_READ_ONLY flag. Since no annotations are provided, this behavioral information is valuable and goes beyond what the schema offers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a clear one-sentence purpose, blank line, then parameter descriptions and additional behavioral notes. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers purpose, parameters, idempotency, and read-only behavior. With an output schema present, return values are not needed. However, it does not mention error behavior (e.g., if issue not found) or authentication requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clearly explains both parameters: 'issue_id' as 'numeric Redmine issue id' and 'user_id' as 'numeric user id to add to the watcher list'. This adds meaning beyond the schema's titles and compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a user as a watcher of an issue', specifying the verb 'add', the resource 'watcher', and the context 'issue'. This distinguishes it from sibling tools like 'remove_watcher' and 'list_watchers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions idempotency and read-only mode but does not provide explicit guidance on when to use this tool versus alternatives. It relies on the name and basic description to imply usage context. No 'when not to use' or alternatives listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: the deletion is permanent ('Permanently delete'), there is no soft-delete in Redmine, it honors the REDMINE_MCP_READ_ONLY environment variable, and it specifies the return format on success and failure. Since no annotations are provided, the description fully covers the behavioral burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. It uses only three short sentences plus a parameter list, with no extraneous information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the output schema exists (per context signals) and the tool is a straightforward delete operation, the description covers all necessary aspects: action, parameters, return values, and safety behavior. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful context: 'numeric id or identifier slug' for project and 'wiki page title' for title. While brief, it provides enough information beyond the bare schema types to guide the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete a wiki page (and all its historical versions)', specifying the verb (delete), resource (wiki page), and scope (including history), which distinguishes it from sibling tools like redmine_create_wiki_page or redmine_get_wiki_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or comparisons with other delete tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds caching behavior detail ('Cache-backed. First call populates the cache.') but does not explicitly state it is read-only or non-destructive, which would be helpful given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with purpose, no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter format, return content, and caching; output schema provides structured details, so description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains the 'project' parameter with format examples (numeric id or identifier slug), adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns a project description and lists specific contents (trackers, modules, issue categories), distinguishing it from sibling CRUD and list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for retrieving a single project's details, but does not explicitly state when not to use or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'Read-only', which is a key behavioral trait. However, with no annotations, more detail on auth or error outcomes would be beneficial. Minimal but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with argument list. No fluff, front-loaded purpose. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch with two params and an output schema, the description covers key aspects. Could mention return type or error handling, but output schema likely handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains both parameters: group_id as numeric integer, include with specific valid values (users, memberships). Adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Fetch' and resource 'group by id', distinct from siblings like redmine_get_user or redmine_list_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear (fetch single group), but no explicit exclusions or alternative tool mentions. The name itself conveys purpose, so it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description declares the tool is read-only and describes parameter behavior, but lacks details on auth, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with a clear purpose line, Args block, and final read-only note. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects for a get tool (parameters, read-only nature) and output schema exists, but the user_id type mismatch (string in schema, numeric in description) may cause minor confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the bare schema: explains user_id accepts numeric values or 'current', and include accepts comma-separated options like memberships and groups.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a user by id, or the current API user,' using a specific verb and resource, and distinguishes from sibling tools like redmine_list_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use (get specific user or current user) and explains default values, but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description declares read-only behavior and notes the page size limit (capped at 100). This provides useful transparency, though it could also mention ordering or other constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, starting with the purpose and listing parameters briefly. Every sentence adds value, and the 'Read-only' line is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers purpose, parameters, pagination, and read-only nature. With an output schema present, return value details are not needed. Missing details like default sorting or scope are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all three parameters: project_id as numeric id or slug, limit as page size capped at 100, offset as skipping N results. This adds meaning beyond the input schema, which has no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List project members (paginated).' which is a specific verb-resource pair. Among siblings like add_membership, update_membership, and remove_membership, it is distinct in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The 'Read-only' hint implies it is for viewing, but no comparison to similar list tools or mutation siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares 'Read-only' and explains pagination behavior (limit cap, offset) and return structure. With no annotations, this provides solid behavioral context, though error cases are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-sentence purpose, structured Args block, final line for returns. No fluff, all sentences essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, return shape, and read-only nature. Lacks error handling details, but for a simple list tool with output schema, this is near-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds full semantic value for all 3 parameters: project format (numeric/slug, empty=global), limit cap, offset behavior. Schema coverage is 0%, so description carries the entire burden and does so excellently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states action 'List news entries' with scoping options (global or project), clearly distinguishing from sibling tools like redmine_create_news or other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (listing news) and the difference between global and project-scoped, but lacks explicit when-not-to-use or comparison to alternatives like redmine_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It notes that parent/child is a field not a relation record, and honors read-only flag. Missing details on permissions, side effects, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~70 words), well-structured with args section, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 integer params and an output schema, the description covers core behavior, special unparent value, and field nature. Missing error conditions or permissions, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains both parameters: issue_id as 'issue whose parent is being set' and parent_issue_id as 'numeric id of the new parent. Pass 0 to unparent.' This adds essential meaning beyond schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set or clear an issue's parent' uses specific verb+resource, clearly indicating the tool's action on issues. It distinguishes from siblings like update_issue or relation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the special value 0 to unparent and mentions honoring REDMINE_MCP_READ_ONLY, providing clear context. However, it does not explicitly compare with alternative tools like update_issue that might also set parent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses critical behaviors: honors REDMINE_MCP_READ_ONLY (safety constraint), direct PUT method, no pre-fetch or workflow check, and details about note handling (empty rejection, newline literal requirement, Markdown rendering) and private permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a header and bullet-like Args section. While it is moderately long, every sentence adds value and there is no redundancy. Minor verbosity could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (implied by context signals) and the sibling tool list, the description provides sufficient context for an agent to select and use the tool. It covers the action, parameter semantics, and behavioral traits. Missing information on error handling or response format, but that is likely in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter: issue_id (numeric), note (constraints on empty, newline literal, Markdown), and private (boolean with permission note). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Append a comment (journal entry) to an existing issue.' It uses a specific verb ('append') and resource ('comment to an existing issue'), distinguishing it from siblings such as redmine_update_journal or redmine_close_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when-to-use or when-not-to-use guidance relative to alternatives. However, the context signals list many sibling tools, and the description mentions honoring REDMINE_MCP_READ_ONLY and being a direct PUT, which implies it is for simple comment addition without status changes. No explicit exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that the tool honors a read-only flag and that the delay parameter is only meaningful for certain relation types. This gives good insight into behavior, though it omits details on failure modes or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear parameter explanations and uses bullet-like formatting. It is slightly verbose due to the extensive listing of relation types, but every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are covered. Parameters are thoroughly explained. However, common error conditions and authentication requirements are not mentioned, which would be helpful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the description explains each parameter in depth: issue_id, target_issue_id, relation_type with a full list of valid values and aliases, and delay with its specific meaning for precedes/follows. This adds substantial value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a relation between two issues' and specifies the source issue, target issue, relation type, and delay. This distinguishes it from sibling tools like redmine_remove_relation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context by mentioning that it honors REDMINE_MCP_READ_ONLY and that cross-project relations require a specific Redmine setting. However, it does not explicitly state when not to use this tool vs alternatives like redmine_set_parent_issue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the destructive, irreversible nature, the safety gate parameter, the return confirmation, and the respect for a read-only mode. This covers behavioral traits beyond what annotations could specify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two introductory sentences and a clear argument list. Every sentence adds value and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter semantics, behavioral traits, and safety. It lacks explicit guidance on when to use this tool versus alternatives, but given the simple destructive operation and existence of an output schema, it is largely complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to both parameters: issue_id is clearly explained as a numeric Redmine issue id, and confirm_destructive is described as a safety gate that must be True to proceed. Since the input schema had no descriptions (0% coverage), this compensation is valuable, though it could provide more detail on issue_id format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete an issue' with a specific verb and resource. It distinguishes from sibling tools like redmine_delete_project or redmine_delete_group by focusing on issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a safety gate (confirm_destructive) and that it honors REDMINE_MCP_READ_ONLY, providing some context. However, it does not explicitly state when to use this tool versus alternatives (e.g., close_issue) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only — no validation, no caching.' This goes beyond what annotations would typically provide (annotations were absent) and clearly informs the agent about safety (no side effects) and behavior (no built-in caching).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for purpose, then a well-structured Args section. No superfluous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects), the presence of an output schema, and the coverage of read-only behavior and parameter semantics, the description is complete. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains both parameters: issue_id is a numeric Redmine issue id, and include is a comma-separated list with a documented default. It clarifies that an empty string uses the default includes, providing critical usage detail not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single issue.' This is a specific verb+resource pair that distinguishes it from sibling tools like redmine_list_issues (multiple issues) or redmine_update_issue (mutating).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While it's implicit for fetching a single issue by ID, the description lacks contextual advice such as 'Use this to retrieve a specific issue after searching with redmine_search_issues.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares 'Read-only,' which is a key behavioral trait. Without annotations, it carries the burden adequately, though it doesn't detail pagination or results format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with three lines, no unnecessary words. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description doesn't need to explain return values. It is complete for a simple list operation, though could mention what fields are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning: 'project_id: numeric id or identifier slug,' explaining the parameter format beyond the schema's simple 'Project Id' label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List files on a project's Files section,' specifying the action and resource. The tool name and verb 'list' align, distinguishing it from siblings like redmine_upload_project_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for use: list files for a project, with explicit argument format. It doesn't explicitly exclude alternatives like other list tools, but the unique purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool honors REDMINE_MCP_READ_ONLY, but does not detail success/failure behavior or permissions. Acceptable for a simple delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, parameter arg, and read-only note. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with an output schema, the description covers purpose, parameter source, and behavior flag. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds critical meaning: relation_id is from list_relations output and not an issue id. This fully compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a relation by its numeric id.' with a specific verb (delete) and resource (relation), distinguishing it from siblings like redmine_add_relation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context by specifying the parameter source ('from list_relations output') and a negative constraint ('NOT an issue id'), but lacks explicit when-not-to-use or alternative tools guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses sequential execution (no batch endpoint), honoring REDMINE_MCP_READ_ONLY, stop_on_error behavior, return format {total, succeeded, failed, skipped}, custom_fields merging, and default values. It could explicitly mention destructive nature (modifies issues) but the update context makes it clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence adds value. It uses a clear docstring-style structure with Args and Returns sections. For 15 parameters, the length is justified. Could be slightly more concise by grouping related fields, but overall well-organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no schema descriptions), the description is highly complete. It covers all parameters, constraints, behavioral notes, return format, and edge cases like stop_on_error. It omits error handling details beyond stop_on_error but is otherwise comprehensive for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add meaning for all 15 parameters. It does so exhaustively: explains issue_ids limit, semantics for each field (subject, status, etc.), references redmine_update_issue for some, details custom_fields format, difficulty convenience, held/held_until, dates, done_ratio, stop_on_error, and defaults. Fully compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Apply the same field updates to many issues in one call,' specifying the verb (apply updates) and resource (issues). It distinguishes from sibling tools like redmine_update_issue (single issue) and redmine_bulk_close by implying bulk update behavior. Also mentions constraints like ≤100 issue_ids and sequential execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use for bulk updates with same fields, lists constraints (≤100 ids, at least one field required), and mentions stop_on_error behavior. It references redmine_update_issue for field semantics, providing some comparison. However, it does not explicitly state when not to use this tool or compare directly to alternatives like redmine_bulk_create_issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: cache-aware id resolution, read-only flag honoring ('REDMINE_MCP_READ_ONLY'), side effects like difficulty no-oping on fleets without the field, and returns structured validation errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and then organized as an Args list. It is appropriately sized for 14 parameters, though some parameter explanations are verbose. Nearly every sentence adds value, with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, 3 required) and existing output schema, the description covers all parameters, return type, and the important read-only behavior. It also addresses edge cases (difficulty no-op, held_until condition) making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides extensive semantic detail for every parameter: formats (ISO-8601 for dates), sentinel values (-1 for done_ratio, 0 for assigned_to_id), conditional use (held_until only when held=True), and the custom_fields accepting list or string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create an issue' which is a clear verb+resource pair. It adds specificity with 'cache-aware id resolution,' distinguishing it from siblings like redmine_update_issue and redmine_close_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage through its name and the 'create' verb, but lacks direct guidance on scenarios or exclusions compared to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the tool is read-only, which is critical for agent decision-making. No additional details like rate limits or side effects are needed for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with no wasted words. Every part adds value: action, resource, access restriction, and read-only nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description covers purpose, access, and mutability. No additional info is necessary, as return values are documented in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters. Schema coverage is 100% (empty). Description does not need to add parameter information, so baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), resource ('all groups'), and constraints ('admin only', 'Read-only'). It distinguishes from siblings like redmine_get_group (single group) and redmine_create_group (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies 'admin only', indicating the intended user role. However, it does not explicitly mention when not to use or provide alternatives, though for a simple list operation this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly declares 'Read-only,' indicating no side effects. It also details return values and a common error scenario (404 for disabled boards module), providing behavioral context beyond the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, arguments, returns, and errors. It is clear and informative, though slightly verbose; a minor reduction could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for a list tool. It covers all parameters, return format, and error conditions. Given the presence of an output schema, the description still provides adequate context without redundancy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all three parameters. It provides extra context for board_id (how to find it via another tool) and notes that limit is capped server-side, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List forum messages on a board,' specifying the verb and resource. The name itself is specific, differentiating it from siblings like redmine_create_message or redmine_list_boards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidelines are implied rather than explicit. The description provides error handling for a 404 but does not discuss alternatives or when not to use this tool. For a simple list operation, implicit usage is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explains that omitted fields remain unchanged (partial update), returns the refreshed project, and honors the read-only mode. This provides good transparency without requiring additional detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line summary, then a structured args list, and a return statement. No unnecessary words. Front-loaded with the core action. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no schema descriptions, the description covers all essential aspects: what, how (partial), required param, optional fields, and return value. It lacks error information but is complete for typical usage. The read-only flag adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides a bullet list with concise explanations for all 9 parameters, including the type and special notes (e.g., parent_id '0 for unchanged'). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a project' and emphasizes partial updates. It lists the specific fields that can be updated, distinguishing it from create/delete tools. The purpose is unambiguous and directly addresses the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: partial update, only supplied fields are sent, and it requires project_id. It also mentions the read-only flag constraint. While it doesn't explicitly contrast with other update tools (e.g., update_issue), the context is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It explains stop_on_error behavior and honors REDMINE_MCP_READ_ONLY flag, indicating read-only mode may prevent changes. Describes return format. Missing details on destructive nature or permanence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short, well-structured with Args and returns. Every sentence adds value. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and an output schema, the description covers core behavior, input constraints, error handling, and read-only awareness. Enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description adds meaning for all parameters: issue_ids (list of numeric IDs, ≤100), note (optional shared comment), stop_on_error (halt on failures). This compensates fully for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (close), the resource (issues), and the scope (many in one call). It distinguishes from sibling tools like redmine_close_issue (single) and redmine_bulk_update_issues (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for bulk closing issues with optional notes and error handling. Mentions limit of ≤100 IDs per call. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the default closed status, note formatting requirements (newlines vs escape sequences), Markdown rendering, handling of workflow-disallowed closures with hints, and honor of REDMINE_MCP_READ_ONLY variable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a clear opening sentence and labeled parameter details. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (workflow interaction, read-only flag, note formatting) and presence of an output schema, the description covers all necessary behavioral context. It explains edge cases and environment influences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning: issue_id as numeric Redmine ID, note as optional journal entry with newline and Markdown specifics. This goes well beyond the schema's basic type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves an issue to its first 'is_closed' status, defaulting to id 5. This is a specific verb+resource combination, and the tool name + description distinguish it from siblings like redmine_bulk_close or redmine_delete_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. Usage is implied by the tool name and context, but no explicit guidance on when not to use it or when to prefer a sibling (e.g., bulk_close).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that no HTTP request is made, auth fingerprint is preserved, and details the effects of each scope option. While safety or reversibility is not discussed, the provided behavioral traits are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise—four sentences structured with a clear purpose, parameter details, and usage context. Every sentence adds value without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description fully covers behavior, parameter options, and usage context. It needs no additional information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by explaining each allowed value ('all', 'tracker:<id-or-name>', 'project:<id-or-slug>') and their specific effects, adding crucial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Drop cached entries for a scope,' using a specific verb and resource. It distinguishes itself from sibling CRUD tools by focusing on cache invalidation, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use after Redmine config changes (new trackers, edited workflow, moved roles),' providing clear context. Although no direct alternatives are listed, the tool is unique among siblings, and the description effectively guides when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as 'Read-only reference data', which is a clear behavioral trait indicating no side effects, compensating for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one short paragraph and a clear args list, front-loading the key information without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, read-only), the description covers purpose, parameter options, and behavior, making it complete for an AI agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by listing the specific valid values for enum_type (issue_priorities, time_entry_activities, document_categories), which the schema alone lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List enumeration values for a given type' with specific examples, distinguishing it from sibling list tools like redmine_list_projects by focusing on enumeration types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the tool is for reading enumeration values and lists valid enum_type options, providing clear context for when to use it, though no explicit when-not or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination behavior, client-side filtering, and return format. With no annotations, the description covers the key behavioral aspects. Could mention any authentication requirements, but not critical for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with a summary line, Args section, and Returns section. Every sentence is informative and there is no redundant information. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input parameters, behavior, and output format thoroughly. Given the tool's simplicity and the presence of an output schema (as implied by the description), the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (query, limit, offset) are fully explained with behavior (client-side filter, max page size 100, defaults). Schema has 0% coverage, so the description carries the full burden and does so excellently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List projects' with key features: paginated, optional substring filter. It distinguishes from sibling tools like 'redmine_describe_project' and 'redmine_search' by being the specific listing tool for projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on parameters and client-side filtering, but does not explicitly mention when to prefer this tool over alternatives like 'redmine_search' or other list tools. However, the filtering behavior is well explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: reactive workflow validation, cache pre-flight, read-only mode honoring, sentinel handling for unchanged parameters, and edge cases like clearing held or due_date. This is thorough and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite lengthy and dense, with a paragraph for each parameter. While the detail is necessary, it could be more structured (e.g., bullet points) to improve readability and scanability. The purpose is front-loaded, which is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, 1 required, no annotations), the description is highly complete. It covers all parameters, special behaviors, cache interactions, and even directs users to redmine_request for edge cases. An output schema exists, so return values are handled separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description explains each parameter in detail, including semantics for optional parameters, sentinel values, and special handling (e.g., status triggers pre-flight, difficulty enumeration, held clearing). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an issue, with reactive workflow validation on status changes,' specifying the verb and resource. It distinguishes from sibling tools like redmine_bulk_update_issues and redmine_close_issue by focusing on single-issue updates with workflow validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed context on when to use the tool, including special behaviors for status changes, cache pre-flight, and sentinel values. It also mentions when not to use it (e.g., clearing due_date requires redmine_request), though it does not explicitly compare to all siblings or provide a comprehensive 'when not to use' list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses optimistic locking, empty text rejection, return behavior (re-fetched after PUT), and honors read-only mode. Could mention error conditions beyond 409.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with bullet points for arguments, a note about return, and read-only flag. It is concise, front-loaded with purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, description doesn't need to detail returns, but it does. Covers all parameters, optimistic concurrency, error case (409), and read-only mode. Complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains all 6 parameters with details: project type, title, text constraints, version locking, optional parent_title and comments. Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update an existing wiki page' with optional optimistic concurrency, clearly specifying the verb and resource. It distinguishes from siblings like redmine_create_wiki_page and redmine_delete_wiki_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating existing pages, differentiating from creation or deletion via the name and context. However, it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits: permanent deletion and the need for admin privileges. It also notes compliance with the REDMINE_MCP_READ_ONLY flag, which is important for agents respecting read-only modes. No annotations were provided, so the description carries the full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that pack essential information. The first sentence covers the action and constraints, and the second provides a behavioral flag. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects for a deletion tool: what it does, who can use it (admin), its effect (permanent), and a behavioral flag. An output schema exists, so return values are not needed. It is fully complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (group_id), and the description does not explicitly mention it, but the tool name and action make it obvious that the parameter identifies the group to delete. The schema provides the type and title, so the description adds little value beyond that, but the context compensates. Given low schema coverage (0%), a 4 is justified because the intent is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a group', providing a specific verb and resource. It distinguishes from sibling tools like redmine_create_group and redmine_update_group by its focus on deletion. The additional constraints 'admin only' and 'Permanent' add clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear prerequisite ('admin only'), indicating when the tool is appropriate. It also notes 'Permanent' to warn about irreversibility. However, it does not explicitly mention when not to use it or suggest alternative tools for related operations (e.g., removing users from groups).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full responsibility. It discloses that the tool bypasses validation, workflow checks, and schema cache; that every response includes 'validation_skipped: true'; that it is gated behind 'REDMINE_MCP_ENABLE_PASSTHROUGH'; and that it respects 'REDMINE_MCP_READ_ONLY' for non-GET methods. This is comprehensive behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, bulleted parameter list, and context. It is not overly verbose, though the explanation of the dual form for body/params could be slightly more concise. Overall, it is efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as an escape hatch, the 4 parameters, and the existence of an output schema (not shown but flagged as present), the description is complete. It covers purpose, usage gating, parameter details, behavior, and response marker. No obvious gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate fully. It does: it explains 'method' as an HTTP verb with allowed values, 'path' as starting with '/' and being joined to REDMINE_URL, 'body' and 'params' as accepting both JSON string and object forms (with rationale for the dual form). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'generic passthrough to any Redmine REST endpoint', which is a specific verb-resource combination that distinguishes it from the many sibling tools that handle specific operations. It explicitly states it 'bypasses redmine-mcp's validation, workflow checks, and schema cache', making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong context: it is an escape hatch for unsupported endpoints, gated behind an environment variable, and honors the read-only flag. However, it does not explicitly state when to use this tool instead of a sibling, leaving it implied that it is for cases not covered by specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains search behavior (all_words, titles_only, open_issues, attachments mode), pagination, and returns format. It could mention ordering or rate limits, but is otherwise thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary then bullet-like Args section. It is reasonably concise given 9 parameters, though some wording could be tighter (e.g., 'Empty searches all' repeated for project and resource_types).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and presence of output schema, the description is complete. It covers all parameters, return format, and behavioral details. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates excellently. Each parameter is explained with allowed values, defaults, and behaviors (e.g., resource_types lists allowed types, attachments explains '0', '1', 'only', query is required and non-empty). This is well beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full-text search across all Redmine resource types' and lists the types. It distinguishes itself from the sibling tool `redmine_search_issues` by noting that it covers more resource types. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions that it complements `redmine_search_issues`, which only covers issues with structured filters, guiding the agent on when to use this tool. It also provides detailed parameter usage, such as project scoping and resource type filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly covers: in-place editing, the behavior of clearing notes (deletes journal if no other changes), input formatting rules (actual newlines, not escape sequences), Markdown rendering, read-only flag honoring, and permission model. This is comprehensive and leaves no ambiguity about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, followed by a requirements note, a prerequisite reference, parameter details in a bullet-like format, and additional context. It is concise overall, though the parameter details could be slightly more streamlined. However, every sentence serves a purpose, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with side effects, permissions, formatting rules, output schema exists so return value documentation not required), the description is remarkably complete. It covers prerequisites, required inputs, edge cases (empty notes, deletion), formatting, permissions, and read-only behavior. No additional information seems necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so excellently: for journal_id it notes it's numeric; for notes it explains it's replacement text, the impact of empty string (clear note and potentially delete journal), the requirement for actual newlines, and that Redmine renders notes as Markdown. This adds critical meaning beyond the bare schema with just types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Edit an existing journal entry's notes in place') and identifies the specific resource (journal entry). It distinguishes itself by referencing the need to use redmine_get_journals to find the journal_id, implying a prerequisite that sets it apart from other tools. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: Redmine 5.0+ and the need to obtain a journal_id via redmine_get_journals. It also mentions that the tool honors the REDMINE_MCP_READ_ONLY flag and describes permission requirements (user can only edit own notes unless they have edit_issue_notes permission). However, it does not directly contrast with sibling tools like redmine_add_comment or redmine_update_issue, which could be alternatives for adding comments vs. editing existing journal notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers all critical behavioral aspects: idempotency, duplicate handling strategies, pacing (sleep between POSTs), stop_on_error behavior, and honoring REDMINE_MCP_READ_ONLY. The return format is also detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and front-loaded purpose. Every sentence adds value; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema present), the description covers input format, behavior, error handling, and return values comprehensively. Agent can confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: issues (list of dicts with required/optional fields), on_duplicate (three options), pacing_seconds (default and rationale), stop_on_error (behavior). It adds depth beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Bulk-create issues with subject idempotency', specifying the core action and unique feature. It distinguishes from siblings like redmine_create_issue (single create) and redmine_bulk_update_issues (update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies bulk creation use case via the name and explanation of parameters. However, it does not explicitly state when not to use or compare with alternatives, though the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully carries the burden. It discloses several behavioral traits: hours are pre-validated client-side, spent_on defaults to today, comments max 1024 chars, user_id is admin-only override, project_id ignored when issue_id is non-zero, and it honors REDMINE_MCP_READ_ONLY.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary followed by a bulleted list of parameters. It is concise, front-loads the purpose, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 0% schema coverage and no annotations, the description covers all 7 parameters, explains their behavior, and mentions the global read-only flag. With an output schema present, the lack of return value explanation is acceptable. The description is complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds substantial meaning to each parameter: hours format and pre-validation, issue_id vs project_id logic, activity resolution, spent_on format and default, comments limit, and user_id role restriction. This goes well beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Log a time entry against an issue or project' using a specific verb and resource. It distinguishes itself from sibling tools like redmine_list_time_entries, redmine_update_time_entry, and redmine_delete_time_entry by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use the tool (to log time) and provides parameter-level guidance (e.g., use issue_id or project_id). However, it does not explicitly contrast with alternative tools or state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details path restriction (must be under allowed directories), symlink resolution, honoring read-only flag, and dual behavior based on issue_id (attach vs return token). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a clear purpose sentence followed by bullet-pointed args. Front-loaded and appropriately sized. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values are likely documented there. Description covers security (read-only, path restriction), dual behavior, and parameter usage. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring description to add meaning. It does: file_path explains path restriction, issue_id explains attachment vs token behavior, description explains it's only meaningful when attaching. Adds significant context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Upload a file (path-restricted) and optionally attach it to an issue.' The verb 'upload' and resource 'file' are specific. It distinguishes from sibling tools like 'redmine_upload_project_file' which uploads to project files, and 'redmine_download_attachment' for downloading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use: to upload a file and optionally attach to an issue. It mentions honoring REDMINE_MCP_READ_ONLY, implying a write operation that can be prevented. No explicit alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: pre-flight GET, rejection of empty text, existence check, error handling, and read-only flag honoring. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a leading sentence and bullet-pointed args. Every sentence adds value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a creation tool with 5 parameters; covers all relevant aspects including pre-flight, error cases, and optional fields. Output schema exists, so return details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description compensates by explaining each parameter's purpose, type (e.g., numeric id or slug), and special behaviors (URL encoding, markdown, optional hierarchy).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates a new wiki page and explicitly mentions it refuses to overwrite existing ones, distinguishing it from siblings like redmine_update_wiki_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (creating new pages) and when not (page already exists), including the pre-flight check and error return. Also notes the REDMINE_MCP_READ_ONLY constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![redmine-mcp-workflows MCP server](https://glama.ai/mcp/servers/Avicennasis/redmine-mcp-workflows/badges/card.svg)](https://glama.ai/mcp/servers/Avicennasis/redmine-mcp-workflows)

Score Badge

Copy to your README.md:

[![redmine-mcp-workflows MCP server](https://glama.ai/mcp/servers/Avicennasis/redmine-mcp-workflows/badges/score.svg)](https://glama.ai/mcp/servers/Avicennasis/redmine-mcp-workflows)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Avicennasis/redmine-mcp-workflows'

If you have feedback or need assistance with the MCP directory API, please join our Discord server