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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

List the projects the API key can see, optionally filtered by name, status, parent, or visibility — the standard "what projects exist" orientation call.

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.

Query logged time by user, project, issue, date range, or activity — used for timesheet review ("what did I log this week") and billing/reporting.

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.

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.

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.

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").

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.

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.