mcp-redmine

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation3/5
Most tools have distinct purposes, but redmine_get_users and redmine_find_user overlap in resolving user IDs, and redmine_my_dashboard partially duplicates redmine_search_issues for personal queries. These overlaps create mild selection ambiguity.
Naming Consistency4/5
All tools share the redmine_ prefix and nearly all follow a verb_noun pattern (get_issue, create_issue, list_projects). The exception is redmine_my_dashboard, which uses a possessive instead of a verb, breaking the pattern slightly.
Tool Count3/5
With 18 tools, the server falls in the borderline heavy range (16-25). The count is justified by the broad domain coverage (issues, users, time, wiki, projects), but it feels slightly oversized for a focused MCP.
Completeness4/5
The core issue workflow is well covered: create, retrieve, update, add notes, search, and log time are all present. However, missing delete operations for issues or notes, no attachment upload, and read-only wiki access represent minor but notable gaps.
Average 4/5 across 18 of 18 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention pagination, return format, authentication, rate limits, or any side effects. The description only restates the basic function, leaving the agent uninformed about important behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence that immediately identifies the tool's purpose and primary filters. Every word earns its place, and there is no redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must compensate. It does not explain what the returned time entries look like, how pagination works, or any other runtime context. The schema covers parameters but not the tool's operational behavior, leaving the description incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description does not add additional semantic meaning beyond what the schema provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets time entries, with specific scoping filters for user or issue. It distinguishes from sibling logging tools (redmine_log_time) and other getters, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'useful for tracking and reporting' provides a general use case, but there is no explicit when-to-use guidance, exclusionary criteria, or mention of sibling alternatives. This makes the usage context implied 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 full burden. It implies a mutation (logging time) but does not disclose side effects, permissions, reversibility, or the response format. The 'meaningful comment' note is a quality expectation, not a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. The first sentence states the core action, and the second adds useful guidance on comments. Both sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a write operation with no output schema and no annotations, the description is under-specified. It does not explain how the system responds, what prerequisites exist, or what happens on failure. It only covers the basic action and a comment quality tip.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description does not add meaningful semantics beyond the schema; the comment guidance maps to the existing 'comments' field, but adds no new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Log') and resource ('time spent on an issue'), clearly distinguishing this from sibling tools like redmine_get_time_entries. It also adds an actionable instruction for the comment quality, making the purpose crisp 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusion criteria. It only implies usage by naming the action, but provides no explicit guidance or context.
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 fails to disclose behavioral traits such as required permissions, return values, or side effects of creating an issue. The only additional guidance is about structuring the description content, which duplicates the schema's description parameter and does not reveal tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the core purpose front-loaded in the first sentence. The second sentence provides practical formatting advice, but it repeats the schema, so slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters and no output schema, the description is minimal. It does not mention what the tool returns after creation, any prerequisites, or error handling, leaving the agent uninformed about post-creation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter descriptions, so the baseline is 3. The tool description merely restates the formatting guidance for the description parameter already present in the schema, adding no new semantics for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Redmine issue,' identifying the action (create) and resource (Redmine issue). The word 'new' distinguishes it from update operations like redmine_update_issue, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this tool is for creating new issues, but it does not explicitly discuss alternatives or when not to use it. The context is clear enough for a straightforward create operation, though exclusions are not 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?
With no annotations, the description must disclose behavioral traits itself. It states 'List all' but the schema includes a limit parameter defaulting to 100, so 'all' is misleading without mentioning pagination or limits. No return format, pagination behavior, or permission details are disclosed, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, resource, scope, and output traits without wasted words. It earns its place and is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, few annotations), the description is mostly sufficient but has a clear gap: the 'all' claim contradicts the limit parameter, and pagination/limit behavior is not explained. This incompleteness prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter (limit), so the baseline is 3. The description adds no extra meaning about the parameter and even undermines understanding by saying 'all' while the schema caps results. No additional parameter context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('Redmine projects') and defines the scope ('you have access to') plus the included fields ('identifiers and status'). This distinguishes it from sibling tools that target issues, wiki pages, or users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (listing accessible projects) but provides no explicit guidance on when to prefer this over sibling tools, nor does it mention exclusions or alternatives. It's adequate for a simple list operation but lacks explicit decision support.
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 must carry the burden. 'Search' implies a read-only operation and 'finding user IDs' hints at the return content, but it does not disclose output structure, pagination, or any other behavioral traits beyond the schema's mention of partial matching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded action and a useful application note. No wasted words; every part contributes to understanding the tool's purpose and use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, and the schema covers them well. However, there is no output schema, and the description does not specify the structure of the returned user objects or how the limit affects results. The existence of a similar sibling tool also remains unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the 'name' parameter's purpose but does not add significant meaning beyond what the schema already provides, and it does not mention the 'limit' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Redmine users by name, with a specific verb and resource. However, it does not differentiate from the sibling tool 'redmine_find_user', which appears to serve a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool ('when assigning issues or @mentioning colleagues'), but does not mention when not to use it or any alternatives. The presence of 'redmine_find_user' as a sibling makes this omission noticeable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It indicates a write operation ('Add') and provides communication style guidance, but it does not disclose potential side effects like status changes via optional params or any permissions/notifications. It is adequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose, use cases, style guide. It is front-loaded with the primary action and has no wasteful content. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully covers parameters and the tool is a note-adding mutation, the description is fairly complete for the task. It could be improved by mentioning alternatives like redmine_update_issue for field changes, but overall it provides sufficient context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters in detail. The description adds no extra parameter meaning beyond the schema; it only references style guidelines for the 'notes' parameter, which the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add a comment/note to an existing Redmine issue' with a specific verb and resource, and lists example use cases. However, it does not explicitly differentiate from sibling tools like redmine_update_issue or redmine_edit_journal, so it lacks overt sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says this is 'the primary way to post updates, progress reports, investigation findings, or review feedback,' which gives clear contextual use. But it does not explicitly state when not to use it or mention alternatives, so there are no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it lists all priorities with IDs, which implies a read operation, but provides no details on response format, ordering, pagination, or authentication. For a simple list tool this is adequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the action and resource, making it very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema, the description should explain the return values more explicitly. It says 'with their IDs' but does not mention whether names are included, leaving some ambiguity. Overall, it is incomplete for an agent to fully anticipate the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed. The empty schema is fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('issue priorities'), and adds a detail ('with their IDs') that distinguishes it from sibling tools like get_trackers or get_statuses. It 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the purpose: one would use this tool to obtain available issue priorities. However, there is no explicit when-to-use, when-not-to-use, or mention of alternatives, so it does not fully meet the higher bar.
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 burden of disclosing behavior. It states the side effect of writing to the local filesystem and that it returns a local file path. It does not detail error handling, overwrite behavior, or directory creation, which are potential concerns for a download tool, but the essential behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes a practical tip and return value. Every sentence contributes meaning, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with two parameters and no output schema, the description provides the purpose, prerequisite, and return value. While it lacks error-handling details or caution about file system side effects, the complexity is low and the description is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive descriptions for both parameters (100% coverage), so the baseline is 3. The description adds a workflow hint about using redmine_get_issue to find attachment IDs, which gives context for attachment_id but does not significantly enrich parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a file attachment from Redmine to the local filesystem, using a specific verb-resource-destination structure. This distinguishes it from sibling tools like redmine_get_issue (which retrieves issue data) and other Redmine management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Use redmine_get_issue first to see available attachments and their IDs,' providing a clear prerequisite and workflow for obtaining the required attachment_id. It does not mention alternatives or exclusions, but the context is sufficient for an agent to understand when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the constraint 'Only the notes text can be changed' and the version requirement 'Requires Redmine 5.0+'. However, it does not mention permissions, reversibility, or what happens if the journal doesn't exist, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then prerequisite, then constraints. No wasted words; every sentence provides necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no annotations or output schema, the description covers the essential workflow (how to get ID), the limitation (only notes), and a compatibility note. It lacks error handling or response details, but those are not critical for this scope, so it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already documents them well. The description adds a workflow hint about using redmine_get_issue to obtain journal_id, but this is also in the schema ('visible in redmine_get_issue output'). No significant parameter meaning added beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it edits existing journal text on a Redmine issue, using the specific verb 'edit' and identifying the resource as a journal. It distinguishes from siblings by noting 'Only the notes text can be changed', which differentiates from broader update_issue or add_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite guidance: 'Use redmine_get_issue first to find the journal ID you want to edit.' It implies this tool is for modifying existing notes rather than adding or updating entire issues. Lacks explicit exclusions but gives clear context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should fully convey behavioral traits. The verb 'List' implies a read-only operation, but the description does not explicitly confirm safety, nor does it indicate the response format or potential edge cases. It is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and followed by a practical use case. Every sentence contributes value; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no input schema and no output schema, the description covers what it does and when to use it. It could be slightly more specific about the return structure (e.g., an array of tracker objects), but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds context by mentioning 'with their IDs' and the goal of finding tracker_id, which helps interpret the tool's output. No parameter explanations are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'List' and resource 'available issue trackers with their IDs', distinguishing it from sibling tools like get_statuses or get_priorities. It also notes the practical purpose of finding a tracker_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Use this to find the right tracker_id.' This gives clear context for usage, though it does not mention exclusions or alternative tools explicitly.
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 provided, the description carries the full burden of behavioral disclosure. It reveals that the tool returns page metadata (author, dates, parent page) and raw page content, and importantly notes that the instance uses standard Markdown instead of textile. This gives the agent a clear picture of the output format. It does not mention permissions, error behavior, or pagination, but for a read-only get operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of just three sentences. It is front-loaded with the primary purpose, followed by return value details and usage guidance. Every sentence adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description appropriately explains what the tool returns (metadata and raw content) and includes a note about Markdown formatting. It also provides prerequisite guidance. While it could mention error scenarios or the exact response structure, the information included is sufficient for a simple page-fetching tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds a small amount of extra context by suggesting using redmine_list_wiki_pages to find page titles, which aids the 'page_title' parameter. However, it does not provide additional semantic detail beyond what the schema already offers, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the full content of a specific wiki page in a Redmine project.' It uses a specific verb (Get), names the resource (wiki page), and mentions the project context. It also distinguishes itself from sibling tools that list pages or handle other entity types, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage guideline: 'Use redmine_list_wiki_pages first to find page titles.' This tells the agent the prerequisite workflow and indirectly indicates when to use the sibling listing tool. However, it does not explicitly state when not to use this tool or compare it to other get tools, so it stops short of full alternatives coverage.
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 provided, the description carries the full burden. It clearly indicates read-only behavior ('get a quick overview') and specifies the data scope. It lacks details like pagination or output format, but for a simple dashboard these are not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences: the first states the purpose and content, the second gives usage guidance. It is front-loaded with key information and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only dashboard with one parameter and no output schema, the description covers the essential behavior and usage. It could mention the output structure, but the description adequately explains what the user gets from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter include_closed already has a description in the schema. The tool description adds no extra parameter semantics, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a quick overview of your Redmine workload' and enumerates specific contents (issues assigned, recently updated, overdue). This distinguishes it from sibling tools like search_issues (general search) and get_issue (single issue).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this as the first tool when starting a work session to see what needs attention.' It tells when to use it but does not mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool updates without necessarily adding a note, which is a useful behavioral trait. However, it does not mention potential side effects like overwriting unspecified fields, permission requirements, or response behavior, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and followed by a clear alternative. Every word earns its place with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters and no output schema. The description provides clear purpose and usage guidance, which covers the key context for selection. However, it omits any mention of return value or typical response, which would be helpful given the absence of an output schema. Still, the description is adequate for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists a few fields already in the schema (status, assignee, priority, due date) but adds no extra semantic meaning beyond the schema's own parameter descriptions. It does not compensate for any missing detail because none is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates issue fields (status, assignee, priority, due date, etc.) and explicitly distinguishes it from redmine_add_note. The verb 'update' plus specific resource examples make the purpose unambiguous and well-differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use redmine_add_note if you want to post a comment. Use this for pure metadata changes.' This clearly tells the agent when to choose this tool versus the alternative, which is excellent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'List all' implies a read-only operation, and the mention of IDs clarifies the return content. However, it does not explicitly state non-mutation or other behavioral details like ordering or pagination, which is acceptable for a simple list but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the operation and output, the second provides the practical use case. Very concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully covers what the tool does and why to use it. It provides sufficient context without needing additional detail about parameters or return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects that with no properties. Per the rubric, 0 params baseline is 4. The description adds no parameter details because none exist, so the baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('issue statuses') and clearly states the output includes IDs. It also distinguishes itself from siblings by linking to the update use case, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Use this to find the right status_id for updates.' While it doesn't name alternatives or exclusions, the guidance is clear and actionable for a simple lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It discloses that the operation returns a hierarchical tree with page titles, versions, and last-updated dates, which is the key behavioral output. It implies a read-only operation through the word 'discover.' While it doesn't mention auth or rate limits, these are less critical for a simple listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences. The first sentence delivers the core purpose, the second adds return format and a usage tip. No wasted words, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and no annotations, the description is complete. It covers what the tool does, what it returns (hierarchical tree with specific fields), and when to use it. The sibling redmine_get_wiki_page provides clear differentiation without needing explicit exclusions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter project_id, which already includes a clear description ('Project identifier (e.g. 'panama', 'largescale') or numeric ID'). The tool description adds little beyond reinforcing that the listing is scoped to a Redmine project, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all wiki pages in a Redmine project.' It specifies the resource (wiki pages), the scope (project), and the action (list). It also distinguishes from the sibling redmine_get_wiki_page by emphasizing the hierarchical list and discovery use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to discover available documentation before reading specific pages.' This implies when to use (before redmine_get_wiki_page) and gives a clear context. It does not explicitly state when not to use, but the guidance is strong enough for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations so description carries burden. Discloses default inclusion of journals/attachments and the context-bloat risk, guiding safe usage for large tickets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with 5 params and no output schema, description covers key return elements (description, metadata, journals, attachments) and usage context; lacks explicit note on child issues/relations but 'full details' implies them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% gives baseline 3; description adds rationale for include_journals=False ('blow up your context') and recurring incident example, exceeding schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' with specific resource and scope ('full details... including description, metadata, journals, attachments'). Distinguished from sibling search/wiki tools by focus on full issue history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case ('understand the full history before updating') and a conditional flag for long histories. No explicit exclusions/alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the underlying behavior: scanning recent issues, matching authors/assignees, returning IDs sorted by frequency, and clarifying that it is a workaround rather than a direct query. It does not explicitly state that it is read-only or how it handles no matches, but the 'scanning' language implies a non-destructive operation and the sorting rationale adds useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core function, then the rationale, then usage guidance. Every sentence earns its place—no fluff, no repetition of schema details. It is well-structured and easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (user IDs sorted by frequency) and how to use the result. It references a sibling tool (redmine_search_issues) for follow-up, providing helpful integration context. It does not describe edge cases like no matches or multiple matches, but for a simple tool with detailed schema annotations, this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of both parameters, including case-insensitive substring matching and scan_pages explanation. The description adds value beyond the schema by giving concrete name fragment examples and explaining the sorting criterion ('most active match comes first'), which helps the agent understand the output ordering and parameter tuning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find a Redmine user ID by scanning recent issues for matching authors and assignees. It specifies the resource (user ID) and the method (scanning issues), and distinguishes itself from sibling tools like redmine_get_users by positioning itself as a workaround for admin restrictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'Use this as a workaround for /users.json admin restrictions' and provides a concrete example of input ('Toyoda', 'yoshikuni', 'Murata'). It also gives clear guidance on what to do with the result: 'pass it to redmine_search_issues as author/assigned_to/updated_by', which serves as an alternative/downstream usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the 500 error when using display names for author/assigned_to/updated_by, which is a critical behavioral trait, and explains the correct input format ('me' or numeric ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose, filter list, pagination, summary-list pointer, and a crucial caveat. No redundant words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter search tool with no output schema, the description covers key behaviors: summary list, pagination via total_count, and the critical input constraint. It provides enough context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 15 params with descriptions, so baseline is 3. The description adds a warning that display names will fail (Redmine API returns 500) and reinforces the need to resolve via find_user, which goes beyond the schema's wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search Redmine issues with flexible filters' and enumerates the filter dimensions, clearly distinguishing it as a search tool. It also differentiates from redmine_get_issue by noting it returns a summary list, making the resource and verb explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to redmine_get_issue for full details and to redmine_find_user for resolving names to IDs, offering clear alternative paths. It also explains pagination via offset and total_count.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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