redmine-mcp-stateless

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Most tools have distinct purposes, but list_issues and list_issues_with_journals have significant overlap in functionality and parameters, which could cause confusion. The other tools are clearly differentiated by their target resources and actions.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern with snake_case throughout. The naming is predictable and readable, with clear action-resource pairs like create_issue, list_projects, and update_journal.
Tool Count5/5
With 13 tools, this server is well-scoped for Redmine issue and project management. The count is appropriate, covering core operations without being overwhelming, and each tool serves a clear purpose in the domain.
Completeness4/5
The toolset provides strong coverage for issue and project management, including CRUD operations for issues, listing resources, and search. A minor gap is the lack of project creation/deletion tools, but agents can still perform core workflows effectively.
Average 3.4/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on July 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
This repository includes a glama.json configuration file.
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 provided, the description carries full burden for behavioral disclosure. It states 'Creates a new issue' which implies a write/mutation operation, but doesn't disclose any behavioral traits: no information about permissions required, whether creation is idempotent, what happens on failure, rate limits, or what the output contains. The description adds minimal value beyond the obvious implication of creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose first. The parameter list is structured but could be more concise by grouping optional parameters. Every sentence (and the parameter list) serves a purpose, though the parameter explanations are minimal.
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 7 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally complete. It identifies the tool's purpose and parameters but lacks crucial context: no behavioral traits, no usage guidance, incomplete parameter semantics. The output schema may cover return values, but the description doesn't reference this, leaving gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides only titles without descriptions. The description lists all 7 parameters with brief labels, adding basic semantic meaning beyond the schema's titles. However, it doesn't explain what each parameter represents (e.g., what a 'tracker_id' is, what values are valid for 'priority_id'), provide examples, or clarify that most parameters are optional with null defaults. This partially compensates for the schema gap but inadequately.
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 'Creates a new issue' which is a specific verb+resource combination. It distinguishes from sibling tools like 'get_issue', 'update_issue', and 'list_issues' by specifying creation rather than retrieval or modification. However, it doesn't explicitly differentiate from other creation tools (none exist in siblings) or provide additional context about what an 'issue' represents in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing valid project_id), when not to use it, or relationships to sibling tools like 'update_issue' for modifications or 'list_issues' for viewing existing issues. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns project details, implying a read-only operation, but does not cover aspects like authentication needs, error handling, rate limits, or what specific details are included in the return. This leaves significant gaps in understanding the tool's 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 concise and front-loaded, with the main purpose stated first followed by parameter details. It avoids unnecessary words, but the parameter section could be more integrated into the flow rather than a separate 'Args' block, slightly affecting structure.
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 low complexity (one parameter) and the presence of an output schema, the description is somewhat complete but lacks depth. It covers the basic purpose and parameter, but without annotations and with minimal behavioral details, it falls short of providing a full understanding for effective tool 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?
The description adds minimal semantics beyond the input schema, which has 0% description coverage. It specifies that 'project_id' is a 'Project ID or identifier', but this is basic and does not elaborate on format, constraints, or examples. With one parameter and low schema coverage, the description provides some value but is insufficient for full clarity.
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's purpose with a specific verb ('Returns') and resource ('details of the specified project'), making it easy to understand what it does. However, it does not explicitly differentiate from sibling tools like 'list_projects', which returns multiple projects rather than details of a single one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'list_projects' for listing multiple projects or 'get_issue' for related resources, leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'max 100' for the limit parameter, which is useful, but doesn't cover other important aspects like authentication requirements, rate limits, pagination behavior, or what happens when parameters are omitted. The description is insufficient for a tool with 5 parameters and no annotation coverage.
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 efficiently structured with a brief purpose statement followed by parameter explanations. Each sentence adds value, though the initial 'Returns a list of issues' could be more specific. The parameter documentation is clear and well-organized.
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 that there's an output schema (which reduces the need to describe return values), 5 parameters with 0% schema coverage, and no annotations, the description does provide some parameter semantics but lacks important behavioral context. It's minimally adequate but has clear gaps in usage guidance and behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides valuable parameter semantics that aren't in the schema. It explains what each parameter does (e.g., 'all projects if omitted' for project_id, 'open/closed/*' for status_id, 'max 100' for limit) and adds meaning beyond the bare schema. However, it doesn't fully document all parameter behaviors (like what 'null' means for each parameter).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns a list of issues' which is a clear verb+resource combination, but it doesn't distinguish this tool from sibling tools like 'search_issues_full' or 'list_issues_with_journals'. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'search_issues_full' or 'list_issues_with_journals'. The description only lists parameters without context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Updates an issue' which implies a mutation operation, but doesn't disclose permissions needed, whether changes are reversible, rate limits, or what happens when null values are provided. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose first, followed by a structured parameter list. Every sentence earns its place, though the parameter explanations could be more detailed. No wasted words, but the structure is basic.
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 7 parameters with 0% schema coverage and no annotations, the description provides basic parameter semantics but lacks behavioral context for a mutation tool. The presence of an output schema reduces the need to explain return values, but the description should do more to cover permissions, validation, and sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides a parameter list with brief explanations (e.g., 'Issue number', 'New subject', 'Comment') which adds meaningful semantics beyond the schema's titles. However, it doesn't explain ID relationships (e.g., what status_id values are valid) or provide examples, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Updates an issue' which clearly indicates the verb and resource, but it's vague about what specific fields can be updated and doesn't distinguish this tool from sibling tools like 'update_journal' or explain how it differs from 'create_issue'. It provides basic purpose but lacks specificity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'create_issue', 'get_issue', or 'update_journal'. The description doesn't mention prerequisites (e.g., needing an existing issue), context for updates, or exclusions. Usage is implied through parameter names but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns 'a list of issues with all comments' and includes pagination parameters (limit/offset), but doesn't disclose important behavioral traits like whether this is a read-only operation, authentication requirements, rate limits, error conditions, or what happens when parameters are omitted. The description adds minimal context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief use case, then parameter documentation in a clear Args section. Every sentence earns its place, though the structure could be slightly more polished (e.g., separating the use case from the parameter documentation more clearly).
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 has 5 parameters, no annotations, and an output schema exists, the description is moderately complete. It documents all parameters well but lacks behavioral context (permissions, side effects, error handling). The existence of an output schema means the description doesn't need to explain return values, but for a list operation with filtering capabilities, more guidance on usage versus siblings would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by documenting all 5 parameters with clear semantics: it explains what each parameter represents (e.g., 'Assignee ID (obtain via list_users)', 'Status ID or "open" / "closed" / "*"'), provides practical guidance on defaults and constraints (e.g., 'all projects if omitted', 'max 100'), and clarifies parameter behavior beyond what the schema provides.
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 'Returns a list of issues with all comments' and mentions it's 'Useful for reviewing progress per assignee', providing a specific verb+resource+scope. However, it doesn't explicitly differentiate from sibling tools like 'list_issues' or 'search_issues_full', which likely offer different filtering or output capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_issues' or 'search_issues_full'. It mentions the tool is 'useful for reviewing progress per assignee', which implies a use case but doesn't offer explicit when/when-not instructions or name alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Returns'), but doesn't mention pagination, sorting, authentication requirements, rate limits, or what data is included in the returned list. This leaves significant gaps for a tool that likely returns multiple items.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and front-loads the essential information about what the tool does.
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 has an output schema (which should document return values) and no parameters, the description is minimally complete. However, as a list operation with no annotations, it should ideally mention basic behavioral aspects like whether it returns all projects or has pagination. The presence of an output schema prevents this from being a complete failure.
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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate for parameter gaps, and it correctly implies no filtering parameters by not mentioning any. A baseline of 4 is appropriate for parameterless tools.
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 verb ('Returns') and resource ('list of Redmine projects'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'get_project' or 'list_issues', which would require specifying this is for listing all projects without filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_project' (for single project details) or 'list_issues' (for issues within projects), leaving the agent to infer usage context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states it 'returns a list' without detailing aspects like pagination, rate limits, authentication needs, or whether it's a read-only operation. This is inadequate for a tool with zero annotation coverage, as it leaves critical behavioral traits unspecified.
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, efficient sentence with no wasted words. It's front-loaded with the core action ('Returns a list'), making it easy to parse quickly, and every part of the sentence contributes directly to understanding the tool's 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?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate but lacks depth. It doesn't explain what 'issue statuses' entail (e.g., open, closed, in progress) or how the output is structured, relying entirely on the output schema. For a list tool with no annotations, more context on behavior would improve completeness.
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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools, as there's nothing to compensate for.
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's purpose with a specific verb ('Returns') and resource ('list of available issue statuses'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_priorities' or 'list_trackers', which have similar naming patterns but return different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., for issue management workflows), or comparisons to siblings like 'list_issues' or 'search_issues_full', leaving the agent to infer usage based on naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool returns, without mentioning any behavioral traits like pagination, sorting, filtering capabilities, authentication requirements, rate limits, or whether it's a read-only operation. This leaves significant gaps in understanding how the tool behaves in practice.
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, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list tool. Every part of the sentence earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate but incomplete. It states what is returned but doesn't provide context about what 'trackers' are in this system (e.g., issue trackers, project trackers) or how this fits with sibling tools. The output schema will handle return values, but the description could better integrate with the broader toolset.
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 schema description coverage is 100% (though empty). The description doesn't need to explain parameters, and it correctly doesn't mention any. Since there are no parameters to document, this earns a high baseline score, as the description doesn't create confusion about nonexistent inputs.
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's purpose with a specific verb ('Returns') and resource ('list of available trackers'), making it immediately understandable. However, it doesn't differentiate this tool from its sibling list tools (like list_issues, list_projects, list_users), which all follow the same 'list [resource]' pattern, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like list_issues and list_projects available, there's no indication of whether this is for general tracking metadata, specific project contexts, or other use cases. It lacks any when/when-not statements or references to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns details including comments and attachments, which is useful, but it doesn't cover other important traits like whether it's a read-only operation (implied but not stated), authentication needs, rate limits, error handling, or pagination for large comments/attachments. For a tool with no annotations, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second provides parameter details. There's no wasted text, though it could be slightly more structured (e.g., bullet points). Every sentence earns its place by adding clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which likely covers return values), the description is mostly complete. It covers the purpose and parameter semantics adequately. However, with no annotations, it lacks behavioral context like safety or performance traits, which slightly reduces completeness for an agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema: it explains that 'issue_id' is an 'Issue number', clarifying the parameter's purpose. Since schema description coverage is 0% (the schema only provides a title 'Issue Id' and type 'integer'), this compensation is valuable. However, it doesn't detail format constraints or examples, keeping it from a perfect score.
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's purpose: 'Returns details of the specified issue, including comments and attachments.' It specifies the verb ('returns details') and resource ('issue'), and distinguishes it from siblings like list_issues (which lists multiple issues) and create_issue/update_issue (which modify issues). However, it doesn't explicitly differentiate from get_project or search_issues_full, which are also read operations on related resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need details of a specific issue (vs. list_issues for multiple issues), but it doesn't provide explicit guidance on when to use this tool versus alternatives like search_issues_full or list_issues_with_journals. No exclusions or prerequisites are mentioned, leaving some ambiguity in 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the Redmine version requirement, which is useful context. However, it doesn't describe key behavioral traits such as whether this is a mutation (implied by 'Edits'), what permissions are needed, if changes are reversible, or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by prerequisite and parameter details in a structured format. Every sentence adds value without redundancy, making it efficient and easy to parse for an agent.
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 that there is an output schema (which reduces the need to describe return values) and no annotations, the description provides basic purpose and parameter semantics. However, as a mutation tool with no annotations, it lacks details on behavioral aspects like error handling or side effects, making it minimally adequate but incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'journal_id' is a 'Comment ID (journals[].id from get_issue response)', clarifying its source and format, and 'notes' is 'New comment content', defining its purpose. This compensates well for the lack of schema descriptions, though it doesn't cover all potential nuances like character limits.
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's purpose: 'Edits a journal (comment) on an issue.' It specifies the verb ('Edits'), resource ('journal'), and clarifies that a journal is a comment. However, it doesn't explicitly differentiate from sibling tools like update_issue, which might also modify issue-related data, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'Requires Redmine 5.0+', which indicates a prerequisite. It doesn't explicitly say when to use this tool versus alternatives like update_issue or how it relates to other journal-related operations, so usage is implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context about privilege requirements ('May require Redmine administrator privileges'), which is valuable behavioral information not in the schema. However, it doesn't describe other behavioral aspects like pagination, rate limits, sorting options, or what fields are returned in the user list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first states the core functionality, the second provides important contextual guidance. There's zero waste or redundancy, and the information is front-loaded with the primary purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, read-only operation), the presence of an output schema, and 100% schema coverage, the description is reasonably complete. It covers the purpose, a key use case, and important privilege requirements. However, for a tool with no annotations, it could benefit from mentioning what information is returned in the user list or any limitations.
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since there are none, and the schema already fully documents the empty parameter set. No additional parameter semantics are needed or provided.
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's purpose: 'Returns a list of Redmine users' with the specific resource (Redmine users) and verb (returns/list). It distinguishes from siblings like list_issues or list_projects by specifying the resource type. However, it doesn't explicitly differentiate from potential user-related tools that might exist in other contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Useful for looking up assignee IDs by name' which explains a primary use case. It also mentions privilege requirements: 'May require Redmine administrator privileges' which is valuable guidance. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a read operation (search) and specifies the scope of search (subject, description, comments) and return format (description and all comments). However, it lacks details on permissions, rate limits, pagination, or error handling, which are important for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by parameter details in a structured format. Every sentence adds value: the first defines the tool, the second clarifies search scope, and the parameter explanations are necessary for understanding defaults. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is mostly complete. It covers purpose, usage, and parameters well. Since an output schema exists, it doesn't need to explain return values in detail, but could benefit from more behavioral context like error cases or performance notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'query' as the search keyword, 'project_id' for filtering by project (with default behavior), and 'limit' for maximum results (with default behavior). This goes beyond the schema's basic titles, providing practical usage 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 specific action ('Full-text search for issues by keyword') and resource ('issues'), distinguishing it from siblings like 'list_issues' by specifying it searches across subject, description, and all comments. It explicitly mentions what it returns ('Returns results with description and all comments'), 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 clear context for when to use this tool ('Full-text search for issues by keyword') and implies alternatives by specifying what it searches across, but does not explicitly name when-not-to-use cases or direct alternatives like 'list_issues'. It gives practical guidance on optional parameters, aiding usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return type ('list of available issue priorities') but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or whether the list is static or dynamic. The description adds basic context but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides essential usage guidance. No wasted words, and the information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is reasonably complete. It explains what the tool does and when to use it. However, with no annotations, it could benefit from mentioning authentication or behavioral constraints for a fully complete picture.
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 0 parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, and it appropriately focuses on the tool's purpose and usage. A baseline of 4 is appropriate for parameterless tools with complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Returns') and resource ('list of available issue priorities'). It distinguishes from siblings by specifying its unique role in providing priority data for use with create_issue/update_issue, unlike list_issues or list_statuses which handle different entities.
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 this tool: 'Used for priority_id in create_issue / update_issue.' This provides clear context for its application and distinguishes it from alternatives like list_statuses or list_trackers that serve different purposes in the issue management workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/daiji-sshr/redmine-mcp-stateless'

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