Redmine MCP Server

Server Quality Checklist

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

Latest release: v2.1.0
Disambiguation5/5
Each tool targets a distinct Redmine operation (e.g., CRUD issues, relations, watchers, search, projects, time entries, users, attachments). There is no ambiguity between similar tools like list_issues and search - one is for structured filtering, the other for free-text across multiple entity types.
Naming Consistency4/5
All tools follow a consistent 'redmine_verb_noun' pattern, e.g., redmine_create_issue, redmine_list_projects. Minor deviations: redmine_search lacks a noun complement, and redmine_manage_issue_watchers uses 'manage' instead of a more specific verb, but overall the pattern is predictable.
Tool Count4/5
With 19 tools, the set is on the higher end of the recommended range for a focused server. However, Redmine's feature breadth (issues, projects, time tracking, users, attachments, search) justifies the count. The tools are well-scoped without being excessive.
Completeness4/5
The tool surface covers the core Redmine lifecycle: CRUD for issues, relations (create/list/delete), watchers, time entries (create/list), projects (list/get), users (list/get current), attachments (upload/download), and reference data. Minor gaps exist (e.g., no project update/delete, no time entry update/delete), but these are less critical for typical use.
Average 4.4/5 across 19 of 19 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on July 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutation (readOnlyHint=false) and open-world. The description adds minimal behavioral context (returns created issue with id). It does not disclose potential silent failures or permission requirements, which are partly noted in schema parameter descriptions but lacking in the main 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 18 parameters (complex) and no output schema. The description mentions return of created issue with id, but does not specify the full return structure or behavior. For a tool of this complexity, more detail about the response would be helpful.
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%, so each parameter has a description. The main description enumerates some fields but adds no extra meaning beyond what the schema provides. Baseline 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 action ('create'), the resource ('issue'), and enumerates key fields (subject, description, tracker, priority, etc.). It distinguishes from sibling tools like redmine_update_issue and redmine_delete_issue by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (creation), but does not explicitly state when not to use or mention alternatives. Given multiple sibling tools for updates, deletes, etc., explicit guidance is lacking.
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?
Annotation contradiction: idempotentHint is true, but description states 'an existing file is never overwritten — the call fails instead', meaning the call is not idempotent (first call succeeds, subsequent calls fail). Otherwise, description adds useful behavioral details about allowed directories, overwrite behavior, and return values.
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?
6 sentences, well-structured with purpose first, then prerequisite, filename override, destination constraints and failure condition, then return values. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 3 parameters fully, explains constraints (allowed directories, overwrite), explains how to get attachment id via another tool, and describes return values (saved path, name, size) despite no output schema. Complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning: for attachment_id, explains how to find it; for save_path, clarifies it's a directory and filename is appended; for filename, explains default and stripping of directory parts. This enhances usability beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (download and save), resource (Redmine attachment), and distinguishes from sibling upload tool. Also provides prerequisite (find id via redmine_get_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?
Provides clear context: need to find attachment id via redmine_get_issue with include: attachments. Explains destination constraints and overwrite policy. Does not explicitly exclude alternative tools, but given the sibling list, it is the only download 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?
Annotations indicate this is a write operation (readOnlyHint=false) and openWorldHint=true. The description consistently describes it as 'Log hours' and adds the permission requirement for user_id, which goes beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with an example, containing no redundant information. Every word serves a purpose.
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 description covers core usage but omits what the tool returns (likely the created time entry). Given no output schema, this is a gap. It also does not mention default values like spent_on defaulting to today, which is in the schema but not highlighted.
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 well-documented. The description adds the mutual exclusivity rule for issue_id/project_id, but otherwise does not provide additional 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 verb 'Log hours' and the resources 'issue or project' with an illustrative example. It distinguishes itself from siblings like redmine_list_time_entries by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the requirement for exactly one of issue_id or project_id, and provides an example scenario. While it does not list alternatives, the context of logging hours versus listing them is clear from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds value by detailing the optional associations that can be expanded (trackers, categories, etc.), which is beyond what annotations provide.
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?
A single sentence that efficiently communicates purpose, optionality, and use case. No wasted words; front-loaded with the primary action.
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 covers the primary inputs and their purpose. It could mention that the response includes full project details, but the optional includes are listed. The openWorldHint mitigates the need for exhaustive output documentation.
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 has 100% coverage with descriptions for both parameters. The description repeats the include options in prose but does not add new semantic meaning or usage details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows full detail for one project, optionally including specific associations. It distinguishes from sibling tools like redmine_list_projects by emphasizing per-project detail and prerequisites for creating issues/time entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is 'needed before creating issues or time entries in an unfamiliar project,' providing clear usage context. It does not explicitly state when not to use or name alternatives, but the sibling list includes list_projects for broader queries.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read behavior. The description adds value by detailing the capabilities (filters, sorting, pagination), which helps the agent understand scope without repeating safety info. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys purpose and capabilities. No unnecessary words; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters and no output schema, the description covers the core filtering features and mentions sorting/pagination. It does not detail return values or pagination mechanics, but the agent can infer from limit/offset parameters. Adequate for a list tool with good annotations.
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%, so the baseline is 3. The description provides a high-level overview of filter categories (status, assignee, tracker, date, custom-field) but does not add new meaning beyond the schema. It is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search and filter issues' and resource 'issues', with scope 'across one or all projects'. It distinguishes itself from siblings like redmine_get_issue (single) and redmine_create_issue by calling it the 'primary entry point' for overview. The list of supported filters reinforces its 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?
The description implies this tool is for 'what's on the board' and lists filters, making it clear when to use it for listing issues. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for most agents.
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?
Annotations already indicate readOnly and openWorld. The description adds that it lists projects the API key can see, clarifying authorization scope. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-front-loaded sentence that efficiently conveys purpose and filtering options without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 7 optional parameters and no output schema, the description covers the main orientation purpose. It slightly misses pagination details, but these are in the schema.
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%, so baseline is 3. The description mentions some filters (name, status, parent, visibility) but not all (e.g., limit, offset, include). It adds little 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 it lists projects visible to the API key, with optional filters. It distinguishes itself from sibling 'get_project' by being a list operation.
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 implies this is the standard orientation call for listing projects, but does not explicitly state when not to use it or name alternatives. However, sibling tools provide context.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds behavioral context by naming specific use cases, which aligns with the read-only nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and purpose, with no unnecessary words. Every part 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?
For a read-only tool with 10 optional parameters and no output schema, the description covers the primary use cases and filtering dimensions. It does not explicitly mention pagination or result format, but the parameters limit/offset hint at it and the schema descriptions add detail. Overall, sufficiently complete given the annotations.
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 10 parameters well. The description mentions filtering by user, project, issue, date range, and activity, which maps to existing parameters but does not add new semantic detail beyond what the schema provides. 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 verb 'Query' and the resource 'logged time', listing filtering dimensions (user, project, issue, date range, activity) and explicit use cases (timesheet review, billing/reporting). It clearly distinguishes from siblings like redmine_create_time_entry and redmine_list_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context ('used for timesheet review and billing/reporting'), making it clear when to use this tool. It does not explicitly state when not to use it or name alternative tools, but the use cases and sibling differentiation are adequate.
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?
Beyond readOnlyHint annotation, description adds critical behavioral info about the include parameter (watchers is permission-gated) and the purpose of fetching state for edits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly-written sentences with no wasted words. First sentence states purpose, second provides usage guidance.
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?
Adequately describes the operation for a simple read tool with clear annotations. Lacks mention of return format but for a single-object fetch it is implied. Missing error conditions but acceptable given schema constraints.
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 description adds minimal parameter-specific value beyond restating the include options. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full detail on a single issue with optional expansions, distinguishing it from siblings like list_issues (multiple) and update_issue (edit).
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?
Explicit guidance to use before editing to see current state and legal transitions. Does not explicitly exclude other use cases but provides clear context.
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?
Annotations declare readOnlyHint and openWorldHint. Description adds crucial behavioral context: requires admin permission on most instances, and describes error scenario. Does not mention pagination or return format, but permission info is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences packed with essential information: purpose, usage, permission warning, and alternatives. Front-loaded with the key action and resource.
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 5-parameter tool with no output schema, the description covers purpose, permission, and error handling. Could mention return format or pagination, but overall sufficient for agent decision-making.
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%, so baseline 3. The description does not add much detail beyond what schema provides for each parameter; it mentions name filter and group_id but without extra semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool finds Redmine users by name, status, or group. Explains its purpose: converting a person's name into numeric IDs required by other fields like assigned_to_id. Differentiates from sibling tools like redmine_get_current_user.
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?
Explicitly states when to use (to get numeric IDs) and when not (non-admin will get permission error). Provides alternative actions: ask human for ID or use redmine_get_current_user for own user.
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?
Annotations declare readOnlyHint=true and openWorldHint=true; the description adds that the tool can optionally expand 'memberships' and 'groups', and frames it as a safe identity check, which enriches transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the main purpose, adds context, and uses no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description fully covers the purpose, usage context, and parameter details, leaving no gaps for the agent.
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 fully covers the 'include' parameter with enum documentation, so baseline is 3. The description adds meaning by explaining the optional expansion as 'memberships (the user's projects and roles) and groups', providing extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'identify' and the resource 'current user', and distinguishes it from sibling tools by calling it the 'who am I' call for session start, default-assignee logic, and permission-aware suggestions.
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 says to use it 'at the start of a session for default-assignee logic and permission-aware suggestions,' providing clear context. It does not mention when not to use or alternatives, but the usage is well-defined.
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?
Annotations already declare readOnlyHint and openWorldHint. Description adds that this is a multi-resource search best for vague queries, which complements the annotations without contradicting them.
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: first states function, second gives usage guidance. No fluff, well-structured 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?
Given the tool's complexity (11 params, no output schema, annotations present), the description fully explains the tool's role and when to use it, making it complete 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 has 100% coverage with descriptions for all parameters. The description adds no extra parameter details beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states free-text search across multiple resource types (issues, wiki, news, projects) in one call, and explicitly distinguishes from sibling tool redmine_list_issues.
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?
Explicitly advises using this tool as first move for vague requests when IDs or projects are unknown, and recommends redmine_list_issues when concrete filters are available.
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?
Adds behavioral context beyond annotations: directional relation, automatic inverse, duplicate prevention, and error handling (Redmine rejects certain relations and passes messages verbatim). Annotations already indicate non-readonly, non-idempotent, and non-destructive, and the description aligns with this.
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 dense but well-structured: starts with purpose, then directionality, warnings, parameter specifics, and error handling. Every sentence adds value, though slightly long. Front-loaded with the most important usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, behavior, parameter details, and error handling comprehensively. However, lacks explicit description of the success response (the created relation object). Given no output schema, this is a minor gap. Overall very complete for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant meaning beyond the schema: details each relation_type enum value, explains delay applicability only to precedes/follows, and provides an example. This helps the agent understand parameter usage clearly.
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 creates a typed relation between two issues, including an example and explanation of directionality. It distinguishes itself from sibling tools like redmine_list_issue_relations and redmine_delete_issue_relation by explicitly mentioning reading and deleting relations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (link issues for planning), when-not-to-use (do not call again with swapped ids to avoid duplicates), and suggests alternatives (read existing links first with redmine_list_issue_relations, undo with redmine_delete_issue_relation). Also advises reading error messages instead of retrying.
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?
Annotations already provide readOnlyHint=true, confirming no data modification. The description adds significant behavioral detail: the directional nature of relations (source/target), the fact that Redmine stores one record per link and derives inverses, and the warning that issue_id in the response may not equal the queried id. It also explains the response structure and relation types, all contributing to high transparency with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-organized, front-loading the purpose and usage before delving into detailed behavioral specifics. Every sentence provides necessary information, though some minor trimming could be possible without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of relation directionality, the absence of an output schema, and the presence of annotations (readOnlyHint, openWorldHint), the description is remarkably complete. It covers what the tool returns, how to parse relations, the meaning of each relation type, and the important caveat about source/target ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions in the input schema, but the description adds value by clarifying that exactly one parameter must be provided and explaining what each parameter returns (all relations vs. a single relation by id). This goes beyond the schema's built-in descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool reads relations (dependency links) between issues, and it distinguishes itself from sibling tools like redmine_create_issue_relation and redmine_delete_issue_relation by being a read operation. It provides a specific use case ('use it before reporting blockers or sequencing work'), making the purpose explicit and actionable.
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 advises passing exactly one of issue_id or issue_relation_id, and relates the tool to redmine_delete_issue_relation by stating that the id returned is what the delete tool takes. However, it does not explicitly mention when not to use this tool or compare it to other list tools like redmine_list_issues, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Nothing is destroyed: removing a watcher only stops notifications and is reversed by adding them back.' It also warns about the separate 'Manage watchers' permission and clarifies that a permission error does not mean missing ids. This adds critical context beyond the annotations (idempotentHint, destructiveHint).
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 a single paragraph but is well-structured: purpose first, then parameter usage, then behavior, then a note. It is concise but dense with information; slight restructuring could improve readability, but it earns its sentences.
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 covers the action and error case (permission) well. It does not describe the response format, but for a mutation tool this is acceptable. It is nearly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds practical guidance: for user_id it tells how to resolve names, for action it explains the effect of each value, and it notes that group ids are not accepted. This goes beyond the schema's minimal parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Add or remove a watcher on an existing issue — the notification subscription', clearly stating the verb and resource. Examples like 'watch this bug for me' differentiate it from sibling tools that manage issues, relations, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to obtain user IDs (from redmine_list_users or redmine_get_current_user) and how to read current watchers (redmine_get_issue with include: ['watchers']). It does not explicitly state when not to use, but the context implies when alternatives are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns the re-fetched issue for confirmation, and includes critical warnings about silent failures for several parameters (status_id, is_private, tracker_id, fixed_version_id). This goes well beyond the annotations (readOnlyHint=false, openWorldHint=true).
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, front-loaded with the main action and key change types, and includes the return value. Every sentence adds value, 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?
Given 20 parameters and no output schema, the description covers the main categories of changes and crucial behavioral quirks. It mentions the return of the re-fetched issue for confirmation, but could also note the required issue_id and potential error scenarios (though schema handles required).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter descriptions, so baseline is 3. The description adds high-level grouping and important cautions about silent ignores, providing extra context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Edit') and resource ('issue'), lists several change types (status, reassign, dates, done_ratio, notes), and clearly distinguishes from sibling tools like create_issue, delete_issue, and get_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 implies use for modifying existing issues but lacks explicit guidance on when to choose this over siblings (e.g., create_issue for new, delete_issue for removal). The context is clear but not explicitly contrasted.
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?
Annotations already set readOnlyHint=true and openWorldHint=true, so the description mostly reinforces that it's a safe read operation. It adds useful behavioral context about the scope (instance-wide vs. project-specific) and what parameters the values map to, but doesn't add significant new behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences—no wasted words. First sentence defines purpose and options, second gives usage advice and alternative. Well-structured, front-loaded, and every sentence is essential.
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 single-parameter tool with 100% schema coverage and clear annotations, the description is complete: it covers purpose, parameters, usage, and alternatives. No output schema exists, but the tool's output (reference data list) is standard and needs no further explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema by mapping each enum value to the specific id parameter it serves (e.g., 'statuses' for 'status_id', 'trackers' for 'tracker_id'), and explains the usage context for each kind. Since schema coverage is 100%, the description compensates with rich semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists legal values for id parameters in write tools, specifying the exact kinds (statuses, trackers, etc.) and how they are selected by the 'kind' parameter. It also distinguishes itself from the sibling tool 'redmine_get_project' by clarifying scope (global vs. project-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call this before creating/updating issues or time entries to avoid guessing IDs, and provides an explicit alternative ('use redmine_get_project with include') for project-specific lists. This gives clear when-to-use and when-not-to-use guidance.
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?
Beyond annotations (non-readOnly, non-destructive), the description adds critical context: the operation is invisible on its own, tokens expire, file path must be in REDMINE_ALLOWED_DIRECTORIES, and Redmine may reject oversized files. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loaded with the primary action, then flows naturally into usage details, token expiry, and constraints. Every sentence serves a purpose with 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?
Given the tool is part of a two-step flow and has no output schema, the description covers the token's purpose, expiry, and integration with sibling tools. It hints at size limits but doesn't explain how to check them, leaving minor room for improvement. Otherwise, it is well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that file_path must be local and in allowed directories, and that description is optional and returned for passing along in the uploads array. It also clarifies how the returned object is shaped. This goes beyond the schema, earning a 4.
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 'Upload a local file to Redmine and get back an upload token' as the core action, and explains it is the first half of a two-step flow, distinguishing it from sibling tools that attach the token (redmine_create_issue, redmine_update_issue).
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?
Explicitly states when to use (before create/update issue), warns that the token does nothing on its own, advises to make the second call promptly due to token expiry, and mentions constraints like allowed directories and size limits. Provides clear when-not-to-use 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?
Description fully details irreversible deletion, cascading effects (journals, time entries, attachments, relations, sub-issues), and permission requirements. This goes beyond annotations (destructiveHint=true) to provide critical context for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: starts with the core irreversible action, then cascading details, then usage guidelines and alternatives. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and presence of annotations, the description is complete. It covers permission requirements, irreversible consequences, and recommends safer alternatives.
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 only parameter `issue_id` is fully described in the schema, but the description adds actionable guidance: confirm with the user and read the issue back first. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state the tool deletes an issue permanently. It distinguishes itself from the sibling tool `redmine_update_issue`, which is recommended as a safer alternative.
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?
Explicitly states when to use (genuine mistakes, duplicates, spam) and when not to (prefer `redmine_update_issue`). Requires user confirmation before calling, with steps to confirm the issue id and subject.
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?
Beyond destructiveHint=true, describes bidirectional removal, no side effects on issues, restore method, and repeat-call behavior, all adding context not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Slightly long but every sentence is informative; front-loaded with purpose, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single param, no output schema, and annotations, the description covers purpose, usage, behavioral details, error handling, and recovery completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with schema coverage 100%; description warns against passing issue id, explains how to obtain relation id, adding crucial guidance 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?
Clearly states it removes a relation (dependency link) between issues, distinguishes from delete_issue and create_issue_relation, and specifies it takes relation id not issue id.
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?
Explicitly describes when to use (cleanup of wrong links like false duplicates) and provides prerequisite step: call list_issue_relations to find the id.
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

Redmine MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Redmine MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/0xkillaflow/agama-redmine-mcp/badges/card.svg)](https://glama.ai/mcp/servers/0xkillaflow/agama-redmine-mcp)

Score Badge

Copy to your README.md:

[![Redmine MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/0xkillaflow/agama-redmine-mcp/badges/score.svg)](https://glama.ai/mcp/servers/0xkillaflow/agama-redmine-mcp)

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/0xkillaflow/agama-redmine-mcp'

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