Provides tools for managing Redmine issues, projects, time entries, and search, enabling AI agents to interact with a Redmine instance via the REST API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Redmine MCP Server Show me all open issues in project Alpha"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Redmine. Enables AI agents to work with issues using simple natural language commands.
Works just as well as a personal tool for a single developer — or deployed once and shared by the whole team.
┌──────────┐ MCP (stdio) ┌─────────────────────┐ REST/JSON ┌──────────┐
│ Agent │ ──────────────▶ │ Redmine MCP Server │ ────────────▶ │ Redmine │
│ (client) │ ◀────────────── │ (this project) │ ◀──────────── │ server │
└──────────┘ tool results └─────────────────────┘ HTTP └──────────┘"What issues are assigned to me? Sort them by priority."
"Create a bug in the Web project: login button doesn't respond on mobile, mark it urgent."
"Summarize issue #456 and all its subtasks."
"How many hours did I log this week, broken down by project?"
Related MCP server: Redmine MCP Server
Node.js 22+
A Redmine instance with the REST API enabled (Administration → Settings → API)
A Redmine API key — go to My account → API access key while signed in
Most MCP clients (e.g. Claude Desktop) launch the server for you — configure it once and forget it:
{
"mcpServers": {
"redmine": {
"command": "npx",
"args": ["-y", "@0xkillaflow/agama-redmine-mcp"],
"env": {
"REDMINE_URL": "https://redmine.example.com",
"REDMINE_API_KEY": "your-redmine-api-key"
}
}
}
}For Claude Desktop, this goes in claude_desktop_config.json (Settings → Developer → Edit
Config). Restart the client and the Redmine tools will appear in its tool list.
To run it standalone from a shell instead:
REDMINE_URL=https://redmine.example.com REDMINE_API_KEY=your-redmine-api-key \
npx -y @0xkillaflow/agama-redmine-mcpThe server speaks MCP over stdio and logs to stderr, so stdout stays clean for the protocol.
Set via environment variables, validated at startup. See .env.example for a
template.
Variable | Required | Default | Purpose |
| yes | — | Base URL of the Redmine instance |
| yes | — | API key for the acting user |
| no |
| Per-request timeout in milliseconds |
| no | empty | Directories the attachment tools may use |
| no |
|
|
| no |
|
|
REDMINE_ALLOWED_DIRECTORIES)The attachment tools are the only ones that touch your filesystem, and they may
only touch it inside this allowlist — a :-separated list of absolute directories
(; on Windows). It governs both directions: reads for
redmine_upload_attachment and writes for redmine_download_attachment.
REDMINE_ALLOWED_DIRECTORIES=/Users/you/redmine-files:/tmp/redmine-downloadsIt defaults to empty, which means no local file access at all — both tools
refuse every path until you opt in. That default is deliberate: an agent that can
be talked into uploading a file is an agent that can be talked into uploading
~/.ssh/id_rsa or the .env holding your API key. Allowlist the narrowest
directory that does the job. Paths are fully resolved (.. segments and symlinks
included) before the check, so a symlink inside an allowed directory cannot point
out of it, and downloads never overwrite an existing file.
Nineteen intent-shaped tools, each tagged with MCP safety annotations. Full reference:
docs/tools.md.
Tool | Kind | Description |
| read | Search/filter issues by status, assignee, tracker, dates… |
| read | Full issue detail, optionally with journals and attachments |
| write | Create an issue |
| write | Edit an issue's status, assignee, notes… |
| write · destructive | Permanently delete an issue — no undo, cascades |
| write | Add/remove a watcher (notification subscription) |
| read | Dependency links of an issue, or one relation by its id |
| write | Link two issues (blocks, precedes, duplicates, relates…) |
| write · destructive | Remove one link — narrow in scope and reversible |
| read | Free-text search across issues, wiki, news, projects |
| read | List visible projects |
| read | Full project detail, trackers/categories/activities |
| read | Query logged time |
| write | Log hours against an issue or project |
| read | "Who am I" — the API key's user, memberships, groups |
| read | Find users by name/status/group — admin-gated on most sites |
| read | Statuses, trackers, priorities, activities, doc categories |
| write | Upload a local file → token for an issue's |
| write | Save an attachment to a local directory (writes to disk) |
Heads up:
redmine_delete_issueis the tool that destroys data — Redmine has no trash, and the delete takes the issue's comments, time entries, attachments, and relations with it. It is annotateddestructiveHint: trueso an MCP client can require confirmation; if your client does not gate on that, treat every call as final.redmine_delete_issue_relationcarries the same annotation but is far narrower: it removes one link between two issues, andredmine_create_issue_relationputs it back in a single call.
Heads up: on write, Redmine silently ignores an unknown
tracker_id,status_id, orfixed_version_idinstead of erroring — always check the returned issue. The same applies tois_private, which is silently dropped if your role lacks the "set public/private" permission.
The server runs locally and acts as a single user: your REDMINE_API_KEY never leaves your
machine except as a request header to your own Redmine instance, and the server can do nothing
your account couldn't already do. Multi-user HTTP transport is planned but not yet implemented —
selecting MCP_TRANSPORT=http exits with a clear error.
Local file access is off by default and confined to
REDMINE_ALLOWED_DIRECTORIES when you enable it. Nothing
else in the server reads or writes your filesystem.
Symptom | Likely cause |
Client shows no tools | Something besides JSON-RPC is writing to stdout — check any wrapper |
Exits immediately on startup | A required env var is missing or invalid; the error names it |
| API key missing/wrong, or REST API disabled on the Redmine side |
| The key's user lacks permission for that action |
| The id doesn't exist or isn't visible to the key |
| Redmine rejected the write — check the field-level messages returned |
docs/architecture.md — design and request lifecycle
docs/tools.md — generated per-tool reference
docs/adding-a-tool.md — recipe for adding a new tool
CONTRIBUTING.md — dev setup and contribution guide
npm install # install dependencies
npm run dev # watch-run the stdio server
npm test # run the test suite
npm run build # bundle to dist/Create a new issue (bug, feature, task) in a project with subject, description, tracker, priority, assignee, dates, and custom fields. Returns the created issue with its id.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | One-line issue summary (required). | |
| uploads | No | Attachment upload tokens to link to the new issue. | |
| due_date | No | Due date, ISO "YYYY-MM-DD". | |
| status_id | No | Initial status id. NOTE: Redmine silently ignores an unknown id (falls back to the default status) instead of returning a 422 — verify the status on the returned issue. | |
| done_ratio | No | Percent done, 0–100 in steps of 10. | |
| is_private | No | Mark the issue private. NOTE: applying this depends on your Redmine role permission ("Set issues public/private"). Without it, Redmine silently ignores the flag (the issue stays public) instead of returning an error — verify is_private on the returned issue. | |
| project_id | Yes | Target project id (required). | |
| start_date | No | Start date, ISO "YYYY-MM-DD". | |
| tracker_id | No | Tracker id, e.g. Bug/Feature/Task. NOTE: Redmine silently ignores an unknown id (falls back to the project default) instead of returning a 422 — verify the tracker on the returned issue. | |
| category_id | No | Issue category id. | |
| description | No | Full description (Textile/Markdown per instance). | |
| priority_id | No | Priority id. | |
| custom_fields | No | Custom-field values as { id, value } entries; value may be a string or string[]. | |
| assigned_to_id | No | Assignee user id. | |
| estimated_hours | No | Estimated effort in hours. | |
| parent_issue_id | No | Parent issue id, to create this as a sub-task. | |
| fixed_version_id | No | Target version (milestone) id. NOTE: Redmine silently ignores an unknown id (or any id when the project has no versions) instead of returning a 422 — verify the version on the returned issue. | |
| watcher_user_ids | No | User ids to add as watchers. |
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.
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.
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.
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.
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.
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.
Link two issues with a typed relation — how dependencies are recorded when planning, e.g. "#42 cannot start until #17 ships". The relation is directional and reads as "issue_id issue_to_id", so state it once from the source issue: Redmine stores a single record and presents the inverse automatically on the other issue. Do NOT call this tool again with the ids swapped to "complete the pair" — that is either rejected as a duplicate or creates a second, redundant link. Use "relates" when no ordering is implied. delay (in days) applies only to "precedes"/"follows". Redmine rejects some relations on purpose — relating an issue to itself, a duplicate of an existing link, a circular "precedes" chain, or a cross-project link when the "cross_project_issue_relations" setting is off — and its message is passed back verbatim, so read it rather than retrying blindly. Read existing links first with redmine_list_issue_relations; undo one with redmine_delete_issue_relation.
| Name | Required | Description | Default |
|---|---|---|---|
| delay | No | Days between the predecessor finishing and the successor starting. Meaningful ONLY for "precedes" and "follows"; passing it with any other relation type is rejected. | |
| issue_id | Yes | Numeric id of the SOURCE issue — the one the relation is stated from. | |
| issue_to_id | Yes | Numeric id of the TARGET issue — the one the relation points at. | |
| relation_type | Yes | How the source relates to the target, read as "issue_id <relation_type> issue_to_id": "relates" — a plain, non-directional link, and the right default when unsure; "blocks" — this issue blocks the target, so the target cannot be finished until this one is; "blocked" — this issue is blocked by the target; "precedes" — this issue must finish before the target starts; "follows" — this issue starts only after the target finishes; "duplicates" — this issue is a duplicate of the target; "duplicated" — the target is a duplicate of this issue; "copied_to" — the target was copied from this issue; "copied_from" — this issue was copied from the target (Redmine normally creates the copy pair itself when an issue is copied). |
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.
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.
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.
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.
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.
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.
Log hours against an issue or project with an activity type and comment — e.g. "log 3.5 hours on #456 for implementing auth". Exactly one of issue_id or project_id is required.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | Yes | Hours to log, must be positive, e.g. 3.5 for "log 3.5 hours on issue #456". | |
| user_id | No | Log on behalf of another user id. Requires elevated permission — Redmine returns 403 otherwise. | |
| comments | No | Short note describing the work, e.g. "implemented auth". | |
| issue_id | No | Issue to book against. Provide exactly one of issue_id or project_id. | |
| spent_on | No | Date the time was spent, ISO "YYYY-MM-DD". Defaults to today. | |
| project_id | No | Project to book against. Provide exactly one of issue_id or project_id. | |
| activity_id | No | Activity id (e.g. Development, Design); required by some Redmine instances. | |
| custom_fields | No | Custom-field values as { id, value } entries. |
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.
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.
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.
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.
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.
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.
Permanently delete an issue. THIS CANNOT BE UNDONE: Redmine has no trash and no restore, and the delete cascades — the issue's journals (comments), logged time entries, attachments, and relations are destroyed with it, and on many configurations its sub-issues are deleted too. Always confirm with the user before calling, quoting the issue id and subject (use redmine_get_issue to read them back first). In most situations the right tool is redmine_update_issue instead: setting a closed or rejected status_id takes the issue out of the way while keeping its history and staying reversible. Reserve this tool for genuine mistakes — duplicates, spam, or an issue filed in the wrong place. Requires the "Delete issues" permission; without it Redmine answers with a permission error.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Numeric id of the issue to delete permanently. Deletion is irreversible and cascades: the issue's journals (comments), logged time entries, attachments, and relations go with it, and sub-issues may be deleted along with their parent. Confirm the id — and the intent — with the user before calling. |
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.
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.
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.
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.
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.
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.
Remove a relation (dependency link) between two issues — the cleanup path for a wrong link, e.g. a false "duplicates" or an inverted "blocks". Takes the RELATION id, not an issue id: call redmine_list_issue_relations with the issue_id first to find the relation and its id. Deleting removes the link in both directions at once (Redmine stores one record and derives the inverse), so there is no second side to clean up. Nothing but the link is touched — both issues, their history, and their other relations are untouched — and the link is restored by a single redmine_create_issue_relation call, so this is far less consequential than deleting an issue. A repeated call fails with a not-found error rather than succeeding quietly.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_relation_id | Yes | Numeric id of the RELATION to delete — the `id` field of a relation, NOT an issue id. Get it from `redmine_list_issue_relations` (call it with the issue_id first and pick the relation you mean). Passing an issue id here usually deletes a real but unrelated link rather than failing, so never guess this value. |
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.
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.
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.
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.
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.
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.
Download a Redmine attachment and save it into a local directory. Find the id with redmine_get_issue using include: ["attachments"]. The file is written into save_path under the attachment's own name unless you override filename. The destination must be inside the operator-configured REDMINE_ALLOWED_DIRECTORIES, and an existing file is never overwritten — the call fails instead, so pass a different filename or directory to retry. Returns where the file was saved, its name, and its size in bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Name to save the file under. Defaults to the attachment's own filename. Any directory part is stripped: only a bare filename is honoured. | |
| save_path | Yes | Destination **directory** — the filename is appended to it, so do not include one. It must resolve inside the operator-allowlisted REDMINE_ALLOWED_DIRECTORIES. | |
| attachment_id | Yes | Numeric id of the attachment. Get it from `redmine_get_issue` with `include: ["attachments"]`, which lists each attachment id, filename, and size. |
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.
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.
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.
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.
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.
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.
Identify who the API key belongs to, plus optional memberships and groups — the "who am I" call to make at the start of a session for default-assignee logic and permission-aware suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Associations to expand: "memberships" (the user's projects and roles) and/or "groups". |
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.
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.
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.
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.
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.
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.
Fetch full detail on a single issue, optionally expanded with journals, attachments, relations, children, watchers, and allowed status transitions. Reach for this before editing an issue to see current state and what is legal to change it to.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Associations to expand: "children", "attachments", "relations", "changesets", "journals" (notes/history), "watchers", "allowed_statuses" (legal next statuses). NOTE: "watchers" is permission-gated — Redmine omits the field entirely (not an empty array) unless your role has "View issue watchers", so its absence does not mean the issue has no watchers. | |
| issue_id | Yes | The numeric id of the issue to fetch. |
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.
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.
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.
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.
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.
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.
Show full detail for one project, optionally including its trackers, issue categories, time-entry activities, enabled modules, and issue custom fields — needed before creating issues or time entries in an unfamiliar project.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Associations to expand: "trackers", "issue_categories", "time_entry_activities", "enabled_modules", "issue_custom_fields". | |
| project_id | Yes | Project id (number) or identifier slug (string), e.g. 42 or "website" (required). |
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.
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.
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.
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.
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.
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.
Read the relations (dependency links) between issues — use it before reporting blockers or sequencing work. Pass exactly one of issue_id (all relations of that issue, returned as { relations: [...] }) or issue_relation_id (one relation by its own id). Each relation reads as "issue_id issue_to_id": issue_id is the SOURCE and issue_to_id the TARGET. Directions: "blocks" — the source blocks the target, so the target cannot be finished first; "blocked" — the source is blocked by the target; "precedes" — the source must finish before the target starts (with an optional delay in days); "follows" — the source starts after the target finishes; "duplicates"/"duplicated", "copied_to"/"copied_from" mirror each other the same way; "relates" is a plain, non-directional link. Redmine stores one record per link and derives the inverse, so an issue is listed as the source of some of its relations and the target of others — never assume issue_id equals the id you queried; compare both ids to work out which way the dependency points. The id of a relation is what redmine_delete_issue_relation takes.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | No | Issue whose relations should be listed. Returns every relation the issue takes part in, in either direction. Provide exactly one of issue_id or issue_relation_id. | |
| issue_relation_id | No | Numeric id of a single relation (the relation's own id, not an issue id) to read back. Provide exactly one of issue_id or issue_relation_id. |
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.
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.
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.
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.
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.
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.
Search and filter issues across one or all projects — the primary entry point for "what's on the board". Supports status/assignee/tracker/date/custom-field filters, saved queries, sorting, and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort column, optionally with ":desc", e.g. "priority:desc,updated_on". | |
| limit | No | Maximum number of issues to return (Redmine caps at 100). | |
| offset | No | Pagination offset (skip N issues). | |
| include | No | Associations to expand on each issue: "attachments" and/or "relations". | |
| subject | No | Filter by subject text (substring match). | |
| due_date | No | Due-date filter; same operator grammar as created_on. | |
| query_id | No | Run a saved query by its numeric id. | |
| author_id | No | Author (reporter) user id, or "me". | |
| status_id | No | Status filter. A status id, or a shortcut: "open" (any open status), "closed" (any closed status), or "*" (any status). Defaults to open issues. | |
| created_on | No | Creation-date filter. Accepts Redmine operators, e.g. ">=2024-01-01", "<=2024-12-31", or "><2024-01-01|2024-06-30" for a range. | |
| project_id | No | Project id or identifier slug to scope to, e.g. "42" or "website". | |
| tracker_id | No | Tracker id, e.g. "1" for Bug. | |
| updated_on | No | Last-updated-date filter; same operator grammar as created_on. | |
| category_id | No | Issue category id. | |
| custom_fields | No | Custom-field filters keyed by field id, e.g. { "5": "urgent" } (exact match). Only fields enabled as a filter in Redmine apply; others are silently ignored. | |
| assigned_to_id | No | Assignee user id, or "me" for the API key's own user. | |
| fixed_version_id | No | Target version (milestone) id. |
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.
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.
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.
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.
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.
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.
List the projects the API key can see, optionally filtered by name, status, parent, or visibility — the standard "what projects exist" orientation call.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by project name (substring match). | |
| limit | No | Maximum number of projects to return. | |
| offset | No | Pagination offset (skip N projects). | |
| status | No | Lifecycle filter: "active" (default), "closed", or "archived". | |
| include | No | Associations to expand: "trackers", "issue_categories", "time_entry_activities", "enabled_modules", "issue_custom_fields". | |
| is_public | No | Filter by public (true) vs private (false) projects. | |
| parent_id | No | Only projects under this parent project id. |
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.
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.
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.
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.
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.
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.
Look up the legal values behind the id parameters the write tools require — issue statuses, trackers, priorities, time-entry activities, or document categories — selected by kind. Call this before creating or updating an issue or time entry instead of guessing an id. These are the global, instance-wide lists; for what a single project actually has enabled, use redmine_get_project with include ("trackers", "issue_categories", "time_entry_activities").
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Which reference collection to return: "statuses" — issue statuses, for `status_id` on create/update issue; "trackers" — issue types (Bug, Feature, …), for `tracker_id`; "priorities" — issue priorities, for `priority_id`; "activities" — time-entry activities (Development, Design, …), for `activity_id`; "document_categories" — document categories (rarely needed). |
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.
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.
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.
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.
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.
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.
Query logged time by user, project, issue, date range, or activity — used for timesheet review ("what did I log this week") and billing/reporting.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of a spent-on date range, ISO "YYYY-MM-DD". | |
| from | No | Start of a spent-on date range, ISO "YYYY-MM-DD". | |
| sort | No | Sort column, optionally with ":desc", e.g. "spent_on:desc". | |
| limit | No | Maximum number of entries to return. | |
| offset | No | Pagination offset (skip N entries). | |
| user_id | No | User id whose entries to list, or "me". | |
| issue_id | No | Scope to a single issue id. | |
| spent_on | No | Exact spent-on date, ISO "YYYY-MM-DD". Use from/to for ranges. | |
| project_id | No | Scope to a project id or identifier slug. | |
| activity_id | No | Filter by activity id (e.g. Development, Design). |
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.
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.
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.
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.
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.
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.
Find Redmine users by name, status, or group — the way to turn a person's name into the numeric id that assigned_to_id, author_id, and watcher_user_ids require. Note that listing users requires admin permission on most Redmine instances; a non-admin API key gets a permission error, in which case ask the human for the id or use redmine_get_current_user for your own.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by login, first name, last name, or email (substring match, case-insensitive). | |
| limit | No | Maximum number of users to return. | |
| offset | No | Pagination offset (skip N users). | |
| status | No | Account status: 1 active, 2 registered, 3 locked. Defaults to active users only. | |
| group_id | No | Only users belonging to this group id. |
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.
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.
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.
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.
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.
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.
Add or remove a watcher on an existing issue — the notification subscription, e.g. "watch this bug for me" or "stop notifying John about #42". Pass the issue id, the user id, and action ("add" or "remove"). Get the user id from redmine_list_users (by name) or redmine_get_current_user (for yourself); read the current watchers with redmine_get_issue and include: ["watchers"]. Nothing is destroyed: removing a watcher only stops notifications and is reversed by adding them back. NOTE: managing watchers needs the separate "Manage watchers" Redmine permission, which an otherwise-capable API key often lacks — a permission error here means exactly that and does not mean the issue or user is missing, so do not retry with different ids.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | "add" — start notifying this user about the issue; "remove" — stop notifying them. Removing only ends the subscription; it changes nothing else on the issue and is undone by calling again with "add". | |
| user_id | Yes | Numeric id of the user to add or remove. Resolve a name to an id with `redmine_list_users`; for "me"/"myself" use `redmine_get_current_user`. Group ids are not accepted on most Redmine versions — pass a user. | |
| issue_id | Yes | Numeric id of the issue whose watcher list is being changed (required). |
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.
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.
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.
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.
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.
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.
Free-text search across issues, wiki pages, news, and projects in one call. Best first move for vague requests where the issue id or project is unknown; prefer redmine_list_issues when you already have concrete filter values.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Free-text query, e.g. "login button bug" (required). | |
| news | No | Include news in the results. | |
| limit | No | Maximum number of results to return. | |
| scope | No | Search scope: "all", "my_project", or "subprojects". | |
| issues | No | Include issues in the results. | |
| offset | No | Pagination offset (skip N results). | |
| projects | No | Include projects in the results. | |
| all_words | No | Require all query words to match (AND vs OR). | |
| wiki_pages | No | Include wiki pages in the results. | |
| open_issues | No | Restrict issue matches to open issues only. | |
| titles_only | No | Match only titles, not body text. |
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.
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.
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.
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.
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.
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.
Edit an issue: change status, reassign, reprioritize, adjust dates/done_ratio, and add a comment (notes) in the same call. Returns the re-fetched, updated issue for confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Comment/journal note to record with this change. | |
| subject | No | New one-line summary. | |
| uploads | No | Attachment upload tokens to link. | |
| due_date | No | New due date, ISO "YYYY-MM-DD". | |
| issue_id | Yes | The numeric id of the issue to update (required). | |
| status_id | No | New status id (see allowed_statuses). NOTE: Redmine silently ignores an unknown id (keeps the current status) instead of returning a 422 — verify the status on the re-fetched issue. | |
| done_ratio | No | Percent done, 0–100 in steps of 10. | |
| is_private | No | Toggle issue privacy. NOTE: applying this depends on your Redmine role permission ("Set issues public/private"). Without it, Redmine silently ignores the flag (privacy unchanged) instead of returning an error — verify is_private on the re-fetched issue. | |
| start_date | No | New start date, ISO "YYYY-MM-DD". | |
| tracker_id | No | New tracker id. NOTE: Redmine silently ignores an unknown id (keeps the current tracker) instead of returning a 422 — verify the tracker on the re-fetched issue. | |
| category_id | No | New issue category id. | |
| description | No | New description. | |
| priority_id | No | New priority id. | |
| custom_fields | No | Custom-field values as { id, value } entries. | |
| private_notes | No | Mark the note as private. | |
| assigned_to_id | No | Reassign to this user id. | |
| estimated_hours | No | Estimated effort in hours. | |
| parent_issue_id | No | New parent issue id. | |
| fixed_version_id | No | New target version id. NOTE: Redmine silently ignores an unknown id (or any id when the project has no versions), keeping the current value, instead of returning a 422 — verify the version on the re-fetched issue. | |
| watcher_user_ids | No | Replacement set of watcher user ids. |
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.
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.
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.
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.
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.
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.
Upload a local file to Redmine and get back an upload token. This is the first half of a two-step flow and does nothing visible on its own: the token is not attached to anything until you pass it to redmine_create_issue or redmine_update_issue in their uploads array (e.g. uploads: [{ token, filename, description }]) — the returned object is already shaped for exactly that. Tokens expire, so make the second call promptly. The file must sit inside the operator-configured REDMINE_ALLOWED_DIRECTORIES, and Redmine may reject files over its own attachment size limit.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the local file to upload. It must resolve to a location inside one of the directories the operator allowlisted in REDMINE_ALLOWED_DIRECTORIES; anything else — including a symlink pointing out of them — is refused. If no directory is allowlisted, file access is disabled entirely. | |
| description | No | Optional caption for the attachment. It is not stored by the upload itself — it is returned so you can pass it along in the `uploads` entry. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.1.0redmine_create_issueredmine_create_issue_relationredmine_create_time_entryredmine_delete_issueredmine_delete_issue_relationredmine_download_attachmentredmine_get_current_userredmine_get_issueredmine_get_projectredmine_list_issue_relationsredmine_list_issuesredmine_list_projectsredmine_list_reference_dataredmine_list_time_entriesredmine_list_usersredmine_manage_issue_watchersredmine_searchredmine_update_issueredmine_upload_attachmentEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Give your AI agents the tools to build, manage, and run automation workflows.
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
AI-native project management for tasks, docs, collaboration, and agents.
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
