Redmine MCP Server
Server Quality Checklist
Latest release: v1.3.0
- Disambiguation5/5
Each tool targets a distinct resource-action pair (e.g., issues, wiki pages, time entries, users, attachments, projects). Overlap is minimal—the only compound tool, redmine_create_or_update_wiki_page, clearly handles both create and update. The catch-all redmine_custom_request is explicitly generic and optional, so it does not create ambiguity.
Naming Consistency5/5All tools follow a consistent redmine_<verb>_<resource> pattern in snake_case. Verbs are uniformly list, get, create, update, delete, with one exception (redmine_create_or_update_wiki_page) that uses a compound verb but remains readable and consistent in style. The single non-verb-noun tool, redmine_custom_request, is a deliberate generic fallback and does not break the established convention.
Tool Count2/5At 33 tools, the surface is oversized for a typical MCP server, exceeding the 25-tool threshold that indicates 'too many.' While Redmine is a feature-rich system, many tools could be consolidated (e.g., time entry activities and statuses/priorities/trackers could be grouped), and the breadth makes the server harder to navigate.
Completeness4/5The tool set covers the major Redmine domains: issues (CRUD plus statuses, priorities, trackers), projects (list/get only), wiki pages (CRUD), time entries (full CRUD plus activities), users (read-only), attachments (get/update/delete), and files (upload/create/list). Notable gaps are the absence of project create/update/delete and user management, but the presence of redmine_custom_request mitigates these limitations for advanced use.
Average 3.3/5 across 33 of 33 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 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 Apache 2.0.
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.jsonto 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the creation action without mentioning required permissions, side effects, response format, or error behavior, leaving the agent uninformed about the operation's specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct at one sentence, but it is under-specified for a complex tool with 18 parameters. It omits important supplementary guidance that could be presented concisely, such as required fields or special use cases, making it more under-specified than appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the tool's complexity, the minimal description fails to cover essential behavioral context like response format, validation requirements, or the need to use redmine_upload_file for attachments. The schema covers parameters but not the overall tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 18 parameters have descriptions in the schema (100% coverage), so the schema provides complete parameter semantics. The description itself adds no additional parameter context beyond what the schema already documents, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new issue in Redmine' essentially restates the tool name 'redmine_create_issue', offering no additional detail about scope or distinct functionality compared to sibling issue tools. It is a tautological expansion of the name rather than a clarifying statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus redmine_update_issue or redmine_delete_issue, nor any prerequisites such as having a project_id or uploading files first. The only usage hint appears in the uploads parameter description, not in the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates that a new time entry is created, offering no information about side effects, permission requirements, constraints on parameters, or what the response will contain. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (6 words) and front-loaded, but it is under-specified and adds no value beyond the tool name. The brevity is not a virtue here because it omits crucial context, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a create tool with 8 parameters, nested objects, and no output schema or annotations. The single-sentence description is wholly insufficient to orient an agent on how to correctly invoke this tool. Even with the schema's parameter details, crucial context about when to use it and what to expect is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 8 parameters, so the baseline is 3. The description itself does not add any parameter information or compensate for gaps, but since the schema is fully self-sufficient, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (time entry), which distinguishes it from sibling update/delete/list operations by name. However, it adds no additional context beyond the tool name itself, so it doesn't fully earn the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this vs. alternatives like redmine_update_time_entry or redmine_list_time_entries. There is no mention of prerequisites, such as the need for an issue_id or project_id, nor any indication of typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 only states 'Delete a wiki page' without revealing whether the deletion is permanent, requires special permissions, affects subpages, or returns a confirmation. This is a significant omission for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient and front-loaded, but it is too terse to provide any value beyond the tool name. It is not verbose, but it also does not include any helpful extra context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, this description is incomplete. It lacks crucial context about reversibility, permissions, and side effects, leaving the agent without a full understanding of what the deletion entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes both parameters fully (100% coverage), so the description adds no additional meaning beyond the schema. The baseline of 3 applies because the structured data already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (wiki page), making the tool's primary purpose evident. However, it does not distinguish this tool from sibling delete tools like redmine_delete_issue or redmine_delete_time_entry, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as redmine_create_or_update_wiki_page or redmine_get_wiki_page. It does not mention any prerequisites, scenarios for use, 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the purpose and offers no information about update behavior (e.g., whether unspecified fields are preserved, if permissions are needed, or what response is returned). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff or redundancy, making it highly concise. It front-loads the core purpose effectively. While more detail would be useful, conciseness itself is handled well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 19 parameters, nested objects, and no output schema or annotations, the description must provide substantial context about update semantics, required fields, and side effects. The single-sentence description provides almost no such context, leaving the agent without critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds no parameter-specific information beyond the schema, but since the schema already documents each of the 19 parameters, no deduction is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing issue in Redmine' clearly specifies the verb (update) and the resource (issue), and explicitly states that it operates on existing issues. This distinguishes it from siblings like redmine_create_issue and 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 Guidelines2/5Does 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 such as redmine_create_issue or redmine_update_journal. The description does not mention prerequisites, partial update semantics, or cases where another tool would be more 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?
With no annotations, the description carries the full burden of disclosing behavior. It omits that the tool can perform destructive operations (PUT, DELETE), requires authentication, or returns raw responses. This is a significant gap for a generic request tool that can mutate Redmine data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded and contains no fluff, making it appropriately sized for a simple tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic, powerful tool with no annotations or output schema, the description is incomplete. It fails to mention the base URL, authentication requirements, possible dangers of arbitrary requests, or how to interpret responses. This would leave an agent under-informed when deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all parameters (method enum, path example, data, params), so the baseline is 3. The description itself adds no additional parameter information, so the baseline stands.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool makes a custom API request to Redmine, with a specific verb and resource. It implies a generic catch-all role, distinguishing it from the specific sibling tools, though it doesn't explicitly say 'use for operations without a dedicated tool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling tools. The word 'custom' hints at using it for unsupported operations, but there are no explicit exclusions, prerequisites, or examples of appropriate use cases.
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 carries the full burden of behavioral disclosure. It implies a read-only operation by saying 'list', but does not disclose pagination behavior, default limits, ordering, or scope of users returned (e.g., active/inactive). Significant behavioral traits are left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is easy to process. It is not verbose, but it is also extremely terse, omitting potentially useful details. However, conciseness is not penalized for brevity alone; it remains efficient and uncluttered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about return format, pagination, and use cases. It only states the basic action, leaving gaps for an agent to know how to invoke the tool and interpret results, especially for a list operation with four parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters (name, limit, offset, group_id), and the description adds no additional parameter context. Since the schema already documents each parameter clearly, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'list' and the resource 'users' in Redmine, indicating it returns a collection of users. It does not explicitly distinguish from sibling tool redmine_get_user, but the plural 'users' implies a list versus a single user, so the purpose is clear but lacks detailed scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like redmine_get_user, nor any mention of filtering strategies or pagination. The description simply states the action without contextual advice on 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.
- 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 of disclosing behavior. The description merely says 'Search' without noting that the operation is read-only, how pagination works, what the default search scope is, or what the response format looks like. For a complex search tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Search Redmine for issues, wiki pages, and more'. It contains no filler and immediately communicates the core action. It is concise and well-structured, earning the maximum score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 output schema, no annotations), the description is too minimal. It omits critical context such as default behaviors (whether all content types are searched by default), pagination usage, how boolean flags interact, and what the returned results contain. This description is insufficient for an agent to invoke the tool correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage), so the schema already provides clear parameter semantics. The description adds minimal value by mentioning 'issues, wiki pages' but does not elaborate on any parameter behavior or relationships beyond what the schema states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search Redmine for issues, wiki pages, and more'. It uses an action verb and resource, distinguishing it from the sibling CRUD tools (e.g., create/delete operations). However, the phrase 'and more' is vague and does not enumerate all searchable content types, slightly reducing precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this search tool versus the many list/get tools in the sibling set. The description implies a search use case but doesn't state when it's preferable to redmine_list_issues or redmine_list_projects, nor does it provide exclusion criteria or alternative recommendations.
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 carries the full burden. It only says 'create or update' but does not disclose whether the operation is idempotent, how overwriting works, any authorization requirements, or what the response contains. This is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. However, it is so brief that it omits important context, making it efficient but somewhat under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description only states the basic purpose and leaves out critical details such as how the page is identified (project_id and title), the role of comments and parent_title, or what the API returns after success. This is insufficient for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully described in the schema. The tool description adds no additional parameter context beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create or update) and the resource (wiki page). It distinguishes from sibling tools like redmine_delete_wiki_page, redmine_get_wiki_page, and redmine_list_wiki_pages by emphasizing the upsert behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, such as needing to check whether the page exists, or when creation vs. update is appropriate.
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. The verb 'Get' implies a read-only operation, but the description does not mention potential errors (e.g., not found), response format, or any side effects. It offers basic clarity but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the action and resource, making it easy to parse quickly. However, it is minimal and could be expanded with useful context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of an output schema, the description fails to explain what 'detailed information' entails or how the 'include' parameter affects the response. Given the tool's complexity (2 params, optional include), the description is vague and does not fully equip an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('id' and 'include'), so the schema already documents what each parameter does. The description adds no additional meaning beyond the schema, such as parameter syntax or usage nuances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific project' clearly states the action (get) and resource (specific project), distinguishing it from listing tools. However, it does not explicitly differentiate from sibling tools like redmine_get_project_versions, relying on the word 'specific' to imply a single entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as redmine_list_projects for listing all projects or redmine_get_project_versions for versions. There are no exclusions or context clues beyond the general scope implied by 'specific project.'
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 present, so the description carries full responsibility. It only says 'Get content' without disclosing expected return format, error behavior (e.g., page not found), auth requirements, or how version affects results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence with no wasted words. It is suitably front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with fully documented parameters, the description is minimally sufficient. However, with no output schema, it would benefit from mentioning return content or version behavior. It omits contextual details like optional version usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds no additional parameter meaning; baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get content') and resource ('specific wiki page'), which distinguishes it from sibling tools like create/update/delete/list. It doesn't name an alternative explicitly but the verb+resource makes the purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as list_wiki_pages or create_or_update_wiki_page. There are no prerequisites, exclusions, or context cues.
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 behavior on its own. It only says 'Delete a time entry,' which adds no beyond the tool name. It fails to mention irreversibility, permissions, or any side effects of deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is well-structured and front-loaded, though it could arguably provide more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool with full schema coverage, so the description need not explain return values. However, for a destructive operation with no annotations, the lack of any behavioral details (e.g., permanence, permissions) leaves the description only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% ('Time entry ID to delete'), so the description does not need to detail parameters. The description itself adds no parameter semantics beyond what the schema already provides, yielding the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a time entry' clearly specifies the verb (delete) and the resource (time entry), which distinguishes it from sibling tools like redmine_delete_issue and redmine_delete_wiki_page. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any prerequisites or conditions. The name implies the action, but there is no 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.
- 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 of disclosing behavior. It does not mention what 'detailed information' includes, how errors are handled (e.g., invalid ID), whether authentication is required, or the effect of the 'include' parameter on the response. The description is purely declarative without behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is front-loaded with the verb and resource, and every word earns its place. Despite being minimal, it is appropriately sized for a straightforward get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the absence of an output schema means the description should clarify what 'detailed information' entails. It does not mention the response structure, the behavior of the 'include' parameter, or error conditions. This leaves the agent with incomplete information for invoking the tool successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (id and include) with clear descriptions, and schema coverage is 100%. The description does not add extra meaning beyond the schema, so the baseline of 3 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information for a specific user, using a specific verb ('Get') and resource ('specific user'). This distinguishes it from sibling tools like redmine_list_users (which lists users) and redmine_get_current_user (which targets the authenticated user).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_users or redmine_get_current_user, nor does it explain the optional 'include' parameter for extending the response. There is no context about prerequisites or typical use cases.
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 carries full burden. It only states 'List files' with no disclosure of requiring authentication, pagination behavior, or what data is returned for each file. It does not contradict annotations since none exist, but it is minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It communicates the core action efficiently, though it could be expanded with useful context without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no output schema, the description should explain what the response contains (e.g., file metadata, URLs) and any relevant constraints like ordering or access. It lacks this, making it under-specified for an agent needing to consume the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes project_id with 'Project ID or identifier' at 100% coverage. The description's phrase 'for a specific project' echoes the schema and adds no new semantics about parameter format, required permissions, or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'files' with a scope 'for a specific project'. This clearly distinguishes it from file mutation tools like redmine_create_file and retrieval tools like redmine_get_attachment, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as redmine_get_attachment or redmine_list_wiki_pages. The description does not state that it should be used for project-scoped file listing, nor does it mention any limitations or exclusions.
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 carries full responsibility for behavioral disclosure, yet it only states that the tool lists time entries with optional filters. It does not mention pagination, default limits, sorting, authentication requirements, or any other operational behavior. The schema reveals limit/offset parameters, but the description itself adds no behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the core action and scope with no redundant wording. It is front-loaded and every word contributes to the meaning, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 optional parameters, no annotations, and no output schema, the description is under-specified. It lacks information about return structure, pagination behavior, filter combinations, or default values, leaving significant gaps for an agent deciding how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description is not required to document each parameter. The phrase 'optional filters' loosely encompasses the parameters but adds no meaning beyond what the schema already provides. This meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('time entries') with an explicit scope ('optional filters'), clearly distinguishing it from get_time_entry (single entry) and other list tools. It is unambiguous and immediately identifies 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as redmine_get_time_entry, redmine_create_time_entry, or redmine_list_time_entry_activities. There are no exclusions, prerequisites, or usage contexts provided beyond the basic listing action.
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 of disclosure. While 'Delete' signals a destructive operation, it does not mention irreversibility, permission requirements, or potential cascading effects. The description adds no context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple one-parameter delete operation, and the schema fully documents the parameter. However, with no annotations or output schema, the description is minimally viable but lacks any behavioral caveats (e.g., permanence, permissions) that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'id' parameter fully documented as 'Issue ID to delete'. The description adds no additional semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an issue from Redmine' clearly identifies the action (delete) and the resource (issue). It distinguishes from sibling tools like redmine_delete_wiki_page and redmine_delete_time_entry by explicitly naming the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as redmine_update_issue or redmine_get_issue. It lacks exclusions, prerequisites, or alternative recommendations, making the usage context implicit at best.
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 of behavioral disclosure. It only states the basic action and does not mention any behavioral traits such as pagination behavior, authentication requirements, or whether the list includes only non-archived projects. The presence of limit and offset parameters is not addressed in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fits on one line. It is front-loaded with the verb and resource, contains no unnecessary words, and is entirely relevant. This is an exemplary model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents its parameters, so the description does not need to explain them. However, the phrase 'all available' conflicts with the pagination parameters (limit/offset) and the description does not clarify this tension. It also does not provide context about the return format or how to use this tool in conjunction with sibling tools, making it minimally complete but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (limit and offset), covering 100% of the parameter semantics. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available Redmine projects' clearly states the verb (list), resource (Redmine projects), and scope (all available). It effectively distinguishes this tool from sibling redmine_get_project, which targets a single project. This is 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 Guidelines2/5Does 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_get_project. It does not mention criteria for selecting this tool, exclusions, or any related tools for filtering or searching. There is no explicit usage context beyond the basic action.
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 only states that an existing attachment is updated but does not disclose behavioral traits such as whether the update is partial (only supplied fields), whether it mutates the attachment record, what side effects occur, if the operation is idempotent, or what response is returned. The description does not contradict any annotations, but it lacks meaningful behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the action and resource, and its brevity is effective for a simple update tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description is minimally adequate. However, with no output schema and no annotations, the description should ideally mention what the tool returns on success (e.g., updated attachment object or no content) and perhaps clarify that it only updates metadata, not the file content. The name 'update_attachment' could be misconstrued, but the description's explicit mention of 'filename or description' mitigates that risk. Overall, the description falls short of fully complete for an agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents id, filename, and description. The description adds the context that the update specifically targets filename and/or description, but it does not provide additional semantic detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('existing attachment') and clearly scopes the operation to 'filename or description'. This clearly distinguishes it from sibling tools like get_attachment and delete_attachment. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, such as when to prefer get_attachment or delete_attachment. It also does not mention any prerequisites like the attachment needing to exist or permissions required. There is no explicit setting of context or exclusions.
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 must carry the full burden of behavioral disclosure, but it only states the action. It does not mention whether updates are partial or full, return values, error handling, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste, making it concise and easy to parse. However, it is so minimal that it sacrifices useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, including a nested object, and no output schema. The description is too sparse to cover update semantics, validation, or response format, leaving the agent uncertain about behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters are documented in the schema with descriptions, so the schema provides full coverage. The tool description adds no extra semantic context beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update an existing time entry' with a specific verb and resource, clearly distinguishing it from sibling tools for creating, deleting, or viewing 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when modifying an existing time entry, but provides no explicit guidance on when to use this versus other time-entry tools. No alternatives or exclusions are mentioned.
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 of behavioral disclosure. It states the action but does not indicate whether the operation is reversible, whether it modifies the file's state, or any permission requirements. This leaves the agent without information about side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loaded with the action. Every word is essential and the description is easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple operation but lacks context about the prerequisite upload step and the resulting state changes. The schema covers parameter details, but the description could mention the expected workflow (upload first, then add) for better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds the context that the file is 'previously uploaded', which aligns with the token parameter, but it does not enrich the meaning of individual parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Add' with a specific resource ('previously uploaded file') and target ('project'), clearly distinguishing it from upload and list operations. It is concise and unambiguous, leaving no doubt about 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously uploaded' implies that the file must already exist via the upload tool, and the token parameter from redmine_upload_file reinforces this workflow. However, there is no explicit 'when to use' or 'when not to use' guidance or comparison with other tools like redmine_list_files.
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 of behavioral disclosure. It merely says 'Delete an attachment from Redmine' without indicating that deletion is permanent, whether special permissions are required, or if there are cascading effects. For a destructive operation, this is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource. It contains no unnecessary words or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), and the description provides the core action and resource. However, it omits details about return values, error handling, or irreversible effects, which are relevant for a delete operation. It is minimally adequate but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the only parameter (id), with description 'Attachment ID to delete'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate. The parameter semantics are fully handled by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (attachment from Redmine), which is specific and distinguishes it from siblings like redmine_get_attachment and redmine_update_attachment. The verb+resource structure is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use when you want to delete an attachment) but does not explicitly state when to use this tool over alternatives or mention any prerequisites or exclusions. It lacks explicit guidance on when not to use, but the intent is clear from the name and description.
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?
Since no annotations are present, the description carries the full burden of behavioral disclosure, but it only states the basic listing action. It does not mention return format, sorting, pagination, or permissions, leaving the agent to infer the operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the action and resource. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core function, but since there is no output schema, it could have enriched the context by describing what the returned data contains (e.g., priority IDs and names). The tool is simple, so the omission is a moderate gap rather than a critical one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies because the input schema is empty and the description adds no unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available issue priorities' uses a specific verb (List) and resource (issue priorities), clearly distinguishing it from sibling tools like redmine_list_statuses and redmine_list_trackers. The scope 'all available' adds completeness without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. The description simply states the action without any context, exclusions, or references to related operations like creating issues or using priority IDs.
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 only states the operation and does not disclose behavioral traits such as read-only nature, return format, pagination, or any prerequisites. Since no annotations are provided, the description carries the full burden but provides minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately sized for a simple parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description tells what the tool does but lacks any elaboration on output structure, usage context, or relationship to siblings. For a simple parameterless list operation it is minimally viable, but the absence of annotations or output schema means more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (empty). Per the baseline rule for 0 params, the description does not need to add parameter meaning. It correctly avoids inventing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available time entry activities' uses a specific verb (list) and resource (time entry activities), clearly distinguishing it from sibling tools like 'redmine_list_time_entries' which lists actual time entries rather than activity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The sibling list contains similar list operations (e.g., list_time_entries, list_statuses), but the description does not clarify the specific use case or relationship between them.
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 burden. It only says 'list,' implying a read operation, but does not disclose pagination, response format, permissions, or whether it returns full content or just titles. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and immediately communicates the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter, the description is adequate but lacks details about the returned data structure or any edge cases. Since there is no output schema, some information about what the list contains would improve completeness. However, the low complexity keeps it at a baseline 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter project_id described as 'Project ID or identifier.' The description adds no additional parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource+scope: 'List all wiki pages for a project.' This distinguishes it from sibling tools like redmine_get_wiki_page (single page) and redmine_delete_wiki_page, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use when you need all wiki pages for a project. However, there is no explicit guidance on when not to use this tool or which alternatives to choose, such as redmine_get_wiki_page for a single page.
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 responsibility for behavioral disclosure. It only states 'Update', which indicates mutation, but gives no information about permissions, idempotency, error behavior, or side effects. This is insufficient for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words or unnecessary details, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with full schema coverage, the description is minimally adequate but lacks contextual depth such as return value expectations or behavioral caveats. Without an output schema or annotations, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all three parameters with descriptive text. The description adds no additional semantic meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (update) on a specific resource (existing journal/comment on an issue), which distinguishes it from sibling tools like redmine_update_issue and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing journal (comment)' implies this tool is for modifying an already-created comment, but there are no explicit usage guidelines, exclusions, or references to alternative tools for creating a new journal.
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 full burden. It only states the basic operation without disclosing return format, pagination, or whether archived/inactive versions are included. The 'versions/milestones' synonym adds slight clarity but no substantive behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the function with no wasted words. It is appropriately concise for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations). The description adequately states what it retrieves and its scope. It could explicitly say 'returns all versions', but the plural 'versions' implies a list, which is sufficient for a minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (project_id described as 'Project ID or identifier'). The description says 'for a specific project', which adds no meaning beyond the parameter name and schema. Baseline 3 applies because the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get versions/milestones for a specific project' uses a specific verb (Get), names the resource (versions/milestones), and scopes it to a project. This clearly distinguishes it from sibling tools like redmine_get_project and no other tool targets versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a project's versions/milestones are needed but provides no explicit when-to-use, when-not-to-use, or alternative mentions. Since no sibling tool overlaps this functionality, context is implicit rather than explicit.
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 only says 'Get detailed information' and does not disclose permissions, error behaviors, or what constitutes 'detailed' in the return. This leaves significant room for assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-resource getter with one parameter and no output schema, this description covers the essential context. It could be improved by noting the distinction from list_time_entries, but it is not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter (id) with its meaning, and the description adds no further semantic detail. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (specific time entry), and implies single-resource retrieval. It distinguishes from list_time_entries by using 'specific', making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when detailed information about one known time entry is needed, but provides no explicit guidance on alternatives or exclusions. The sibling list_time_entries is not mentioned, so the agent must infer the distinction.
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 carry the burden of behavioral disclosure. It only says 'get detailed information', which is vague about whether it returns metadata (e.g., filename, size, author) or the actual file content. It does not mention permissions, return format, or error behavior, leaving critical ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the action ('Get') and resource ('attachment'). There is no wasted wording, and the key detail 'specific' is included to clarify that it refers to one attachment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema, no annotations), but the description lacks essential context about what 'detailed information' includes or what the response looks like. An agent cannot infer whether it receives metadata or file content, which is a notable gap for a get operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'id' as 'Attachment ID' (100% coverage), so schema does the heavy lifting. The description adds no additional parameter context, which is acceptable given the schema's clarity, but it does not enhance semantics either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific attachment, using the specific verb 'get' and resource 'attachment'. It distinguishes from sibling tools like redmine_update_attachment and redmine_delete_attachment by focusing on reading, not modifying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when you need detailed info about an attachment, identified by its ID. It does not explicitly mention alternatives or exclusions, but the context is unambiguous and the sibling set makes the read-only purpose self-evident.
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 indicates a read-only operation ('Get information') but lacks detail on authentication requirements, response structure, or possible errors. This is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the essential action and resource. No filler or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is minimally adequate. However, the vague term 'information' does not specify the response format or which user fields are returned, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and therefore 100% schema description coverage. According to the rubric, the baseline is 3, and the description adds no parameter semantics because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Get information about the currently authenticated user'. This distinguishes it from sibling tool redmine_get_user, which likely targets a specific user 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the phrase 'currently authenticated user' but provides no explicit when-to-use or alternative guidance. It does not mention when to use this tool vs redmine_get_user or any other sibling.
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. 'List issues' implies a read-only operation, and 'optional filters' indicates filtering capability, but no additional behavior (pagination, defaults, response format, rate limits) is disclosed. For a simple list tool this is minimally acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource. Every word adds value and there is no wasted text. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no annotations, and no output schema, the description is minimal but covers the basic purpose. It does not explain return values or pagination behavior, but the full schema coverage compensates for parameter semantics. Overall it is a minimum viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema documents all 10 parameters. The description only adds the generic phrase 'optional filters' but does not explain any specific parameter meaning or usage, so no added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('List issues') and notes 'optional filters', making it clear this tool returns multiple issues. It distinguishes itself from siblings like redmine_get_issue (single issue) and mutation tools (create/update/delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with optional filters' implies this is for querying issues with criteria, but there is no explicit guidance on when to prefer this over redmine_search or redmine_get_issue. No exclusions or alternatives are mentioned, so usage context is only implied.
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 full responsibility for disclosing behavior. It merely states the action without mentioning return format, pagination, sorting, or whether all trackers (including inactive ones) are returned. For a simple list tool, the description is thin on behavioral context beyond the obvious read-only nature hinted by 'List'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It fully conveys the core action in a compact form, fitting the tool's simple nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is minimally adequate but leaves gaps around return structure and any inherent filtering or scope. It does not explain what fields a tracker record contains or how the result might be consumed, which could require an agent to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. Per the scoring rule, a tool with 0 parameters receives a baseline of 4; the description adds no parameter information because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available issue trackers' uses a specific verb ('List') and a clear resource ('issue trackers'), making its purpose immediately obvious. It naturally distinguishes itself from sibling tools like redmine_list_statuses and redmine_list_priorities by naming the specific resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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, but the clear resource name implies the use case. Since there are many list tools among siblings, explicit guidance (e.g., 'Use when you need tracker IDs for creating/updating issues') would improve clarity, but the intent is still reasonably inferable.
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 implies a read-only operation with no side effects. It does not explicitly mention any behavioral traits like permissions, response format, or ordering, but the simplicity of the tool reduces the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. Every word contributes to the meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema and no annotations, the description is adequate but could be slightly more explicit about the return type or that it returns a list of all statuses. Still, it is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully documents all inputs. The description adds no parameter-specific details, but the baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available issue statuses' clearly states the action (list) and the specific resource (issue statuses). It distinguishes itself from sibling tools like redmine_list_priorities and redmine_list_trackers by explicitly focusing on statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this tool when you need to retrieve all issue statuses. However, no explicit alternatives or when-not-to-use guidance is provided, which prevents a higher score.
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 full burden. It discloses the upload operation and token output, but lacks details on authentication requirements, file size limits, or token expiration. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler. Every word adds value, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description sufficiently explains the purpose and downstream usage. It does not over-explain but provides the necessary context for the token workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already documented. The description adds no extra parameter-specific details, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a file to Redmine and returns an upload token. It distinguishes itself from siblings by explaining the token's role with redmine_create_file or issue attachments, making its specific purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: before using redmine_create_file or when attaching files to issues. It provides a clear usage context but does not explicitly list exclusions or alternative tools, though the intended workflow is evident.
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 must disclose behavior directly. It reveals that journals are off by default to save tokens, that a total count is always returned, and that pagination is available via journals_* params. This adds meaningful behavioral insight beyond the simple 'get,' especially the token-saving default and count 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the purpose, the second explains the key behavioral default. No filler or redundant information; front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers the most important behavioral aspects (default journal behavior, count, pagination, truncation options in schema). It doesn't enumerate every parameter, but the schema does the heavy lifting. It provides a complete functional picture for a read tool, though it doesn't specify return structure beyond the total count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 8 parameters with rich descriptions (100% coverage), so the baseline is 3. The description adds value by grouping the journals_* parameters as a family, explaining their purpose (comments) and the default off state, which helps the agent understand the schema's parameters as a cohesive mechanism. It also introduces the term 'comments' as an alias for 'journals.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get a specific issue,' which is a specific verb + resource pair that clearly identifies the tool as retrieving a single issue by ID. This differentiates it from sibling redmine_list_issues (plural) and the mutation tools. It also adds the journals behavior detail, but the core purpose is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the context for fetching one issue and provides guidance on the default comment behavior and how to enable/page through journals. It does not explicitly name alternatives like redmine_list_issues, but the singular 'specific issue' implies when this tool is appropriate; thus it's clear context without exclusions.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/gmlee-ncurity/redmine-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server