Skip to main content
Glama
Avicennasis

redmine-mcp-workflows

by Avicennasis

redmine_search_issues

Search and list Redmine issues using filters for subject, project, status, tracker, saved query, and custom fields, with sorting and pagination.

Instructions

Search/list issues with optional filters and pagination.

Args: query: substring on issue subject (Redmine subject=~ filter). Empty for unfiltered. project: optional numeric id or identifier slug. status: optional id, name, or one of Redmine's special tokens ("open", "closed", "*"). Lower-case tokens are passed through; named statuses (e.g. "Closed") resolve via the cache. tracker: optional tracker id or name ("Bug"), or a comma-separated list of either ("Bug,Feature"). Names resolve through the schema cache and are emitted as Redmine's tracker_id. An unresolvable name returns tracker_not_found rather than dropping the filter — without this parameter a query for "Bug tickets" is inexpressible and returns Features/NewApps/Prompts mixed in, with nothing in the response saying so. query_id: optional Redmine saved query id (numeric). 0 (default) means no saved query. It does NOT merge with custom_fields — the saved query's own filters win and yours are dropped silently — so passing both returns query_id_conflicts_with_custom_fields instead of a quietly unfiltered set. custom_fields: optional mapping of custom field -> value to filter on, sent as Redmine's cf_<id>=<value>. Keys may be numeric ids or field names ({"Github Org": "wgtunnel"}); names resolve through the schema cache. Accepts a dict or a JSON-encoded object. An unresolvable key returns custom_field_not_found rather than silently dropping the filter — Redmine ignores unknown filter params, so a dropped one would return everything in scope and look like a successful match. sort: optional Redmine sort spec, forwarded verbatim. Accepts field[:desc] and comma-separated lists, including custom fields as cf_<id> (e.g. "cf_5:desc"). limit: page size (capped at 100). offset: skip the first N results.

Returns {issues, total_count, limit, offset, query}. Each issue's project object carries identifier (slug) when the project is known to the cache, so consumers need not map name → slug.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNo
limitNo
queryNo
offsetNo
statusNo
projectNo
trackerNo
query_idNo
custom_fieldsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.1.0
    • addedInput schema / properties / custom_fields
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "string"
      +    }
      +  ],
      +  "default": "",
      +  "title": "Custom Fields"
      +}
    • addedInput schema / properties / sort
      Added value: +{
      +  "default": "",
      +  "title": "Sort",
      +  "type": "string"
      +}
    • addedInput schema / properties / tracker
      Added value: +{
      +  "default": "",
      +  "title": "Tracker",
      +  "type": "string"
      +}
  2. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so well: it names concrete failure modes (tracker_not_found, custom_field_not_found, query_id_conflicts_with_custom_fields) and warns that Redmine silently ignores unknown filters, which would otherwise look like a successful match. It stops short of stating auth/permission needs, but the pitfall disclosure is unusually strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line summary, then dense per-argument notes in a predictable order. It is long, but nearly every sentence adds operational detail (failure codes, silent-drop warnings) that earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter search tool with no annotations, the description covers filters, conversion rules, conflict handling, error codes, and briefly the return shape. With an output schema present, the return summary is a bonus rather than a requirement, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does for all nine parameters: substring semantics for query, id-or-slug for project, special tokens for status, comma-list/name resolution and the tracker_id emission for tracker, saved-query conflict rules for query_id, key resolution and cf_<id> mapping for custom_fields, and field[:desc]/cf_<id> syntax for sort.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (search/list issues) plus scope (optional filters and pagination), which cleanly separates it from single-issue siblings like redmine_get_issue and from narrower listers like redmine_my_issues or redmine_list_child_issues.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Filter semantics are explained in depth, but there is no explicit when-to-use/when-not guidance relative to the many sibling listing/search tools (e.g. redmine_search, redmine_my_issues, redmine_bulk_create_issues). Usage is implied rather than directed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools