redmine-mcp-stdio

Q: What can you do with this server?

This server provides an MCP interface to Redmine, enabling AI assistants and MCP clients (Cursor, VS Code, Claude, Cline, etc.) to interact with issues, projects, and time entries. Issue Management * List/filter issues – Browse by project, status, assignee, or free-text search, with pagination or bulk fetch (up to 500) * Get issue – Retrieve full details including journal history and attachments * Create issue – Open a new issue with subject, description, tracker, priority, status, and assignee * Update issue – Modify any fields (subject, status, priority, assignee, done ratio, description) with an optional journal note * Add comment – Append a note to an existing issue's journal Project Management * List projects – Retrieve all accessible projects * Get project – Fetch detailed info including versions and members Time Tracking * Log time – Record a time entry against an issue or project, with hours, activity type, date, and optional comment * List time entries – Query entries filtered by issue, project, user, and/or date range Reference / Lookup * List enumerations – Fetch IDs and names for trackers, issue statuses, priorities, and time-entry activities (useful for supplying correct IDs to other tools)

Q: Which integrations are available for this server?

Allows interaction with Redmine, providing tools for managing issues, projects, time entries, and enumerations such as trackers, statuses, priorities, and activities.

Q: How do I use redmine-mcp-stdio?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@redmine-mcp-stdio list all open issues assigned to me" 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.

by andrelaptenok

Overview Schema Related Servers Score Discussions

TypeScript

Local

redmine-mcp-stdio

A local Model Context Protocol server (stdio) for Redmine. Point an MCP client at it (Cursor, VS Code, Claude, Codex, Windsurf, Cline, Zed, JetBrains AI and others) and work with Redmine issues, projects and time entries straight from the editor.

npm npm downloads license node

Tools

Tool	What it does	Key parameters
`list_issues`	List/filter issues, paginated	`project_id`, `status_id`, `assigned_to_id`, `query`, `limit`, `offset`, `all`
`get_issue`	Full details of one issue + comments/history + attachments	`id`, `include_journals` (default `true`)
`list_projects`	Accessible projects	`limit`
`get_project`	Project details, versions and members	`id`
`create_issue`	Create an issue	`project_id`, `subject`, `description`, `tracker_id`, `priority_id`, `assigned_to_id`, `status_id`
`update_issue`	Update issue fields	`id` + any of `subject`, `status_id`, `priority_id`, `assigned_to_id`, `done_ratio`, `notes`
`add_comment`	Add a note to an issue	`id`, `notes`
`log_time`	Log a time entry on an issue/project	`issue_id` or `project_id`, `hours`, `activity_id`, `comments`, `spent_on`
`list_time_entries`	List time entries, filtered	`issue_id`, `project_id`, `user_id`, `from`, `to`, `limit`, `offset`
`list_enumerations`	IDs of trackers/statuses/priorities/activities	none
`search`	Full-text search (issues, wiki, news, …)	`q`, `project_id`, `types`, `titles_only`, `open_issues`, `limit`, `offset`
`get_current_user`	Account behind the API key (id, login, name)	none

Every tool ships MCP tool annotations (readOnlyHint, destructiveHint, …), so clients can auto-approve read-only calls.

Related MCP server: Redmine MCP Server

Install

No manual install needed. The client launches the server on demand with npx, which downloads it on first run and caches it after. Just add the config for your client under Connect.

Prefer to run from a local clone? See Development.

Get a Redmine API key

My account > API access key > Show.

If there's no such section, an admin must enable the REST API in Administration > Settings > API.
The key must belong to a user with permission to view (and, for writes, create/edit) issues.

⚠️ Never commit your API key. Copy .env.example to .env for local use; .env is gitignored.

Connect

The server reads REDMINE_URL and REDMINE_API_KEY from the environment. Provide them via the client's MCP config env block.

Cursor

Edit ~/.cursor/mcp.json (global) or .cursor/mcp.json in a project root:

{
  "mcpServers": {
    "redmine": {
      "command": "npx",
      "args": ["-y", "redmine-mcp-stdio"],
      "env": {
        "REDMINE_URL": "https://redmine.your-company.com",
        "REDMINE_API_KEY": "your_key"
      }
    }
  }
}

Reload Cursor and enable the server in Settings > MCP.

VS Code (GitHub Copilot)

Edit .vscode/mcp.json in your workspace (or your user mcp.json). Note the top-level key is servers, not mcpServers:

{
  "servers": {
    "redmine": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "redmine-mcp-stdio"],
      "env": {
        "REDMINE_URL": "https://redmine.your-company.com",
        "REDMINE_API_KEY": "your_key"
      }
    }
  }
}

Claude Code

claude mcp add redmine \
  --env REDMINE_URL=https://redmine.your-company.com \
  --env REDMINE_API_KEY=your_key \
  -- npx -y redmine-mcp-stdio

Or edit ~/.claude.json / the project .mcp.json directly (same shape as Claude Desktop below).

Claude Desktop

Edit claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "redmine": {
      "command": "npx",
      "args": ["-y", "redmine-mcp-stdio"],
      "env": {
        "REDMINE_URL": "https://redmine.your-company.com",
        "REDMINE_API_KEY": "your_key"
      }
    }
  }
}

Restart Claude Desktop afterwards.

Codex CLI

Add a server table to ~/.codex/config.toml:

[mcp_servers.redmine]
command = "npx"
args = ["-y", "redmine-mcp-stdio"]
env = { REDMINE_URL = "https://redmine.your-company.com", REDMINE_API_KEY = "your_key" }

If node is installed via nvm, use the full path from which npx as command.

Windsurf

Edit ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "redmine": {
      "command": "npx",
      "args": ["-y", "redmine-mcp-stdio"],
      "env": {
        "REDMINE_URL": "https://redmine.your-company.com",
        "REDMINE_API_KEY": "your_key"
      }
    }
  }
}

In Cascade, open MCP servers > Manage > View raw config, paste, then refresh. Supports ${env:VAR} interpolation if you'd rather not inline the key.

Cline

In the Cline pane, click the MCP Servers icon and choose Configure MCP Servers to open cline_mcp_settings.json:

{
  "mcpServers": {
    "redmine": {
      "command": "npx",
      "args": ["-y", "redmine-mcp-stdio"],
      "env": {
        "REDMINE_URL": "https://redmine.your-company.com",
        "REDMINE_API_KEY": "your_key"
      }
    }
  }
}

Zed

Zed calls MCP servers context servers. Open the command palette and run zed: open settings, then add to settings.json (note "source": "custom"):

{
  "context_servers": {
    "redmine": {
      "source": "custom",
      "command": "npx",
      "args": ["-y", "redmine-mcp-stdio"],
      "env": {
        "REDMINE_URL": "https://redmine.your-company.com",
        "REDMINE_API_KEY": "your_key"
      }
    }
  }
}

Zed restarts the server on save, so no editor reload is needed.

JetBrains AI Assistant (2025.2+)

Settings > Tools > AI Assistant > Model Context Protocol (MCP) > Add:

Type: stdio
Command: npx (if node is installed via nvm, use the full path from which npx)
Arguments: -y redmine-mcp-stdio
Environment:
- REDMINE_URL=https://redmine.your-company.com
- REDMINE_API_KEY=your_key

Enable "Automatically enable new and changed MCP servers", then Apply. Click the status icon and you should see 12 tools. Invoke them in chat with /.

Verify locally (optional)

REDMINE_URL=https://redmine.your-company.com REDMINE_API_KEY=your_key npx -y redmine-mcp-stdio

The process should start and wait silently on stdio (Ctrl+C to exit).

Troubleshooting

Failed to connect / server won't start: the command must resolve in the client's environment. If node is installed via nvm, a bare npx may not be found. Use the full path from which npx as the command.
Missing REDMINE_URL or REDMINE_API_KEY: the env block wasn't passed. Double-check it's in the MCP config, not your shell.
Redmine 401 / 403: bad API key, or the key's user lacks permission for that action.
Redmine 404: the issue/project id doesn't exist, or REDMINE_URL points at the wrong host.

Configuration

Variable	Required	Default	Description
`REDMINE_URL`	yes	n/a	Base URL of your Redmine instance (http/https)
`REDMINE_API_KEY`	yes	n/a	Personal API access key
`REDMINE_TIMEOUT_MS`	no	`10000`	Per-request timeout in milliseconds
`REDMINE_MAX_RETRIES`	no	`2`	Retries on `429`/`5xx` with exponential backoff

Architecture

The code is organized in layers, with a single HTTP client injected into each tool group so that tools never touch transport or process.env directly:

src/
  index.ts            entry point: load config, build client, register tools, serve stdio
  config.ts           env parsing + validation (Zod) into a typed RedmineConfig
  version.ts          single source of the version string
  redmine/
    client.ts         RedmineClient: auth, timeout, retry, host pinning, secret redaction
    errors.ts         RedmineError / ConfigError + HTTP error normalization
    paths.ts          safe path-segment encoding + project-id validation
    types.ts          Redmine API response types
  tools/
    register.ts       wires every tool group onto the server
    issues.ts         list/get/create/update issues + add_comment
    projects.ts       list/get projects (versions, members)
    time-entries.ts   log_time, list_time_entries
    enumerations.ts   trackers / statuses / priorities / activities
    search.ts         full-text search across issues, wiki, news, ...
    users.ts          get_current_user
    helpers.ts        guard(), ok()/fail(), ToolResult
  format.ts           pure presentation helpers

Development

npm run build       # compile src/ to build/
npm run typecheck   # tsc --noEmit (strict)
npm run lint        # eslint
npm run format      # prettier --write
npm test            # build, then run the vitest suite
npm run check       # typecheck + lint + format:check + test (what CI runs)

See CHANGELOG.md for releases.

Security

The API key is never logged and is redacted from error output; requests are pinned to the configured host, path parameters are encoded, and every call is bounded by a timeout and a response-size cap. Details and reporting: SECURITY.md.

License

MIT. See LICENSE.

Available Tools

12 tools

add_commentAdd commentB

Add a comment (note) to a Redmine issue

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`notes`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description confirms a write operation but adds no extra behavioral context such as whether the issue must exist, whether duplicate comments are allowed, or any return behavior. It is consistent with annotations but does not significantly augment them.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that directly states the tool's core function. There is no superfluous information, making it highly concise and efficient.

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

Completeness2/5

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

Given the tool's simplicity and the presence of annotations, the description fails to cover essential context: it does not explain the parameters, which are critical for correct usage. For a tool with no output schema and 0% parameter coverage, the description should at least clarify that 'id' refers to the issue ID and that 'notes' is the comment text.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not clarify the meaning of either parameter. 'id' is not explicitly stated as the issue ID, and 'notes' is not explained (e.g., content format, length limits). This leaves the agent with insufficient information to correctly populate the parameters.

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

Purpose5/5

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

The description clearly states the verb 'Add', the resource 'comment (note)', and the context 'to a Redmine issue'. It effectively distinguishes from sibling tools like create_issue or update_issue by specifying that it adds a comment to an existing issue.

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

Usage Guidelines3/5

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

The description implies the tool is used when you want to add a comment to an issue, but it does not explicitly state when to use it versus alternatives (e.g., using update_issue to add a comment). No exclusions or prerequisites are mentioned.

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

create_issueCreate issueC

Create a new Redmine issue

ParametersJSON Schema

Name	Required	Description
`subject`	Yes	Issue title
`status_id`	No
`project_id`	Yes	Project identifier or numeric id
`tracker_id`	No
`description`	No
`priority_id`	No
`assigned_to_id`	No

TDQS

C2.4/5.0

Behavior2/5

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

Annotations indicate not read-only, not destructive, but the description does not add behavioral context beyond that. No mention of side effects, permissions, rate limits, or error conditions. Given that annotations already exist, the description adds minimal value.

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

Conciseness3/5

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

The description is a single sentence with no waste, but it is overly minimal. It lacks structure and does not provide sufficient detail. While concise, it sacrifices informativeness.

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

Completeness2/5

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

Given the complexity (7 parameters, no output schema), the description is incomplete. It does not explain return values, error states, or usage context. The agent lacks key information to correctly invoke the tool.

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

Parameters1/5

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

Schema description coverage is only 29% (2 of 7 parameters have descriptions). The description does not explain any parameter semantics; it does not compensate for the low coverage. The agent must rely solely on the schema, which lacks descriptions for most parameters.

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

Purpose4/5

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

The description 'Create a new Redmine issue' clearly states the action (create) and resource (Redmine issue). It distinguishes from sibling tools like update_issue, list_issues, and add_comment, but lacks specificity about the scope of creation.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. For example, it doesn't mention whether it requires authentication or which fields are crucial. No when-not-to-use or alternative tools mentioned.

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

get_current_userGet current userA

Read-only

Get the Redmine account behind the configured API key: numeric id, login and name. Use the id (or the literal 'me') wherever a user id is expected.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations provide readOnlyHint=true; description adds details on returned fields (id, login, name). No contradictions, adds value beyond annotations.

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

Conciseness5/5

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

Two concise sentences: first states purpose and output, second gives usage tip. No fluff, front-loaded.

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

Completeness5/5

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

For a simple tool with no parameters or output schema, the description fully explains what it returns and how to use the result. Complete.

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

Parameters4/5

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

No parameters, schema coverage 100%. Description doesn't add parameter info but understands baseline 4 for zero parameters.

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

Purpose5/5

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

The description clearly states it retrieves the current Redmine user's account info (numeric id, login, name). This is specific and distinct from sibling tools like get_issue or get_project.

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

Usage Guidelines4/5

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

Provides explicit guidance on using the returned id or 'me' wherever a user id is expected. No mention of when not to use or alternatives, but context is clear.

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

get_issueGet issueA

Read-only

Get full details of one Redmine issue by id, including attachments and, by default, comments/history (journals)

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Issue id
`include_journals`	No	Include comments and field-change history

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so no destructive behavior. Description adds context about including attachments and by default journals, which goes beyond the annotation.

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

Conciseness5/5

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

Single sentence, no wasted words, front-loaded with the action and resource.

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

Completeness4/5

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

Given the simple tool (2 params, no output schema), the description adequately covers what the tool returns (details, attachments, journals). Could mention potential empty response, but adequate for a get operation.

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

Parameters3/5

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

Schema coverage is 100%, and the description reinforces the include_journals default ('by default, comments/history'), but adds no new semantic meaning beyond the schema.

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

Purpose5/5

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

The description clearly states 'Get full details of one Redmine issue by id', which is a specific verb-resource combination. It distinguishes from siblings like list_issues (multiple issues) and update_issue (modify).

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

Usage Guidelines4/5

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

The description implies use for retrieving a single issue's full details, but does not explicitly state when to use alternatives like list_issues for multiple issues. Lacks exclusion guidance.

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

get_projectGet projectA

Read-only

Get a project's details, versions and members

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Project identifier or numeric id

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description's behavioral disclosure is minimal. It confirms the tool reads a project's details, versions, and members, but lacks information about error handling, authentication requirements, or rate limits. The description adds no significant value beyond the annotations.

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

Conciseness5/5

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

The description is a single sentence that front-loads the purpose with no unnecessary words. Every part of the sentence adds value.

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

Completeness4/5

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

Given that there is no output schema, the description gives a reasonable hint of what is returned (details, versions, members). For a simple get tool, this is largely sufficient, though it could be more explicit about what 'details' entails.

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

Parameters3/5

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

The input schema covers the single parameter 'id' with a description 'Project identifier or numeric id'. The tool description does not add extra semantic meaning, so with 100% schema coverage, the baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states what the tool does: 'Get a project's details, versions and members'. The verb 'get' and resource 'project' are specific, and it distinguishes from sibling tools like list_projects (which lists projects) and get_issue (which gets issues).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. For example, it does not mention that to list all projects one should use list_projects, or that this tool is for retrieving a single project's details. The agent must infer this from the name and siblings.

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

list_enumerationsList enumerationsA

Read-only

List trackers, statuses, priorities and time-entry activities with their IDs

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds value by specifying exactly which enumerations are returned and that IDs are included. It does not contradict annotations and provides concrete behavioral context beyond the annotations.

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

Conciseness5/5

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

The description is a single, lean sentence (12 words) that immediately conveys the tool's purpose. It uses the active verb 'list' upfront and specifies the exact resources, with no wasted words.

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

Completeness3/5

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

Given the tool's simplicity (no parameters, no output schema), the description covers the essential purpose. However, it does not describe the output format or include examples, which could be helpful for an AI agent to understand the returned structure. It is functional but not enriching.

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

Parameters4/5

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

There are zero parameters, so the schema fully covers parameter semantics. The description does not need to add parameter information, and it correctly omits any mention of parameters.

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

Purpose5/5

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

The description clearly states the tool lists specific enumeration types (trackers, statuses, priorities, time-entry activities) with their IDs, using the verb 'list'. This distinguishes it from sibling tools like list_issues and list_projects that list entities rather than lookup values.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or context, such as needing enumeration IDs for creating or updating issues. Usage is only implied.

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

list_issuesList issuesC

Read-only

List Redmine issues with optional filters and pagination

ParametersJSON Schema

Name	Required	Description
`all`	No	Fetch every matching issue (up to 500), ignoring limit/offset
`limit`	No
`query`	No	Substring match in subject only; scans up to 500 issues. For full-text search (descriptions, comments, wiki) use the search tool
`offset`	No	Number of issues to skip
`status_id`	No	open, closed, * or a status id
`project_id`	No	Project identifier or numeric id
`assigned_to_id`	No	User id or 'me'

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, so the description adds minimal behavioral context. It does not mention that the tool scans up to 500 issues, pagination behavior, or any other traits beyond what is implicit in the schema.

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

Conciseness5/5

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

The description is a single sentence that directly states the tool's purpose. It is efficient and front-loaded with no unnecessary words.

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

Completeness2/5

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

Given the tool has 7 parameters and no output schema, the description is too sparse. It omits what the output looks like, sort order, and the practical limit of 500 issues (though implied in parameter descriptions). A more complete description would cover these aspects.

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

Parameters3/5

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

With 86% schema description coverage, the schema already explains most parameters. The description only mentions 'optional filters and pagination' generically, adding no extra meaning 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.

Purpose4/5

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

The description clearly states the tool lists Redmine issues with optional filters and pagination. It uses a specific verb and resource, but does not explicitly distinguish from sibling tools like 'get_issue' or 'search'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'search' for full-text or 'get_issue' for a single issue. The 'query' parameter description does mention using 'search' for full-text, but this is not in the main tool description.

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

list_projectsList projectsB

Read-only

List accessible Redmine projects

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true. The description adds that the tool lists 'accessible' projects (scope). However, it does not disclose pagination behavior (despite the limit parameter) or additional constraints. With annotations, this is acceptable but minimal.

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

Conciseness4/5

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

The description is a single concise sentence with no fluff. It is appropriately sized for a simple tool, though it could benefit from slightly more detail.

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

Completeness2/5

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

Given the simplicity (1 optional param, no output schema, read-only), the description could mention the return format (array of project objects) or default ordering. Without this, the agent may need to infer behavior. The description is incomplete for a fully self-contained tool.

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

Parameters2/5

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

Schema description coverage is 0%. The description does not add any meaning for the 'limit' parameter beyond the schema's default/min/max. For a single optional parameter, the description should at least hint at its purpose (e.g., 'limits the number of projects returned').

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

Purpose5/5

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

The description clearly states the verb 'List' and the resource 'accessible Redmine projects', which is specific and distinct from sibling tools like 'get_project' (singular) and 'list_issues'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus siblings (e.g., use 'get_project' for a single project). No prerequisites or exclusions are mentioned.

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

list_time_entriesList time entriesB

Read-only

List time entries, filtered by issue, project, user or date range

ParametersJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD
`from`	No	Start date YYYY-MM-DD
`limit`	No
`offset`	No
`user_id`	No	User id or 'me'
`issue_id`	No
`project_id`	No

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds context about filtering capabilities but does not disclose pagination behavior (limit/offset) or output format. For a tool with annotations, this is adequate but not rich.

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

Conciseness5/5

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

Single, front-loaded sentence with no wasted words. The core action and filters are immediately clear.

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

Completeness3/5

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

Given 7 parameters, 43% schema coverage, no output schema, and read-only annotations, the description should explain more about pagination, output format, and filter combination logic. It provides the essential purpose but lacks completeness for complex usage.

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

Parameters3/5

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

Schema description coverage is 43% (3 of 7 parameters described). The description adds meaning by listing filter categories (issue, project, user, date range) which map to the relevant parameters, but it does not cover pagination parameters (limit, offset) or clarify parameter interactions. The description partially compensates for the schema gap.

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

Purpose4/5

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

The description clearly states the action ('List') and resource ('time entries') and specifies the filtering dimensions (issue, project, user, date range). It distinguishes from siblings like 'log_time' (which logs new entries) and 'list_issues' (different resource).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage for retrieving filtered time entries, but does not mention when not to use it or provide comparisons to siblings like 'log_time' or 'list_issues'.

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

log_timeLog timeA

Log a time entry against an issue or a project

ParametersJSON Schema

Name	Required	Description
`hours`	Yes	Hours spent
`comments`	No
`issue_id`	No	Issue to log against
`spent_on`	No	Date YYYY-MM-DD (defaults to today)
`project_id`	No	Project to log against (if no issue_id)
`activity_id`	No	Time entry activity id

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already indicate this is a mutation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds no additional behavioral context beyond what annotations provide, so score is neutral.

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?

A single, well-structured sentence that is efficient and to the point. No wasted words, though it could be slightly more descriptive without becoming verbose.

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

Completeness2/5

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

For a tool with 6 parameters and no output schema, the description is too brief. It does not explain what the tool returns upon success or failure, any required permissions, or the role of activity_id. The description is incomplete for effective use.

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

Parameters3/5

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

Schema description coverage is 83%, so the schema already documents most parameters. The description's mention of 'against an issue or a project' adds marginal context for issue_id and project_id, but does not provide significant additional meaning beyond the schema.

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

Purpose5/5

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

The description clearly states the action ('log') and the resource ('time entry') and distinguishes it from sibling tools like list_time_entries. It specifies the targets ('issue or a project'), making the purpose immediately clear.

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

Usage Guidelines3/5

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

The description mentions logging against an issue or a project but provides no guidance on when to use this tool versus alternatives like list_time_entries, nor does it clarify conditions for using issue_id vs project_id. Usage context is implied but not explicit.

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

searchSearch RedmineA

Read-only

Full-text search across Redmine: issues (subjects, descriptions, comments), wiki pages, news and more. Prefer this over list_issues when looking for text.

ParametersJSON Schema

Name	Required	Description
`q`	Yes	Search query
`limit`	No
`types`	No	Restrict to these result types (default: all types)
`offset`	No	Number of results to skip
`project_id`	No	Limit the search to one project (identifier or numeric id)
`open_issues`	No	Match only open issues
`titles_only`	No	Match only in titles/subjects

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description's job is lighter. It adds context about the scope (full-text across multiple types) but does not disclose behavior like pagination, result ordering, or potential performance implications. Adequate but not rich.

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

Conciseness5/5

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

Two sentences with no extraneous words. The key information (purpose, usage guidance) is front-loaded and earns its place. Extremely concise.

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

Completeness4/5

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

Given the tool's complexity (7 parameters, multiple search types) and lack of output schema, a more detailed description of return structure or pagination would be beneficial. However, with good annotations and schema coverage, the description is mostly complete for decision-making.

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

Parameters3/5

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

Schema description coverage is high (86%), so the existing schema already documents parameters well. The description does not add additional meaning beyond what's in the schema, maintaining the baseline score.

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

Purpose5/5

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

The description clearly states 'full-text search' (specific verb) across specific resources like issues, wiki pages, news, etc. It also explicitly distinguishes from sibling tool list_issues, making the purpose unambiguous.

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

Usage Guidelines4/5

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

The description provides a clear usage guideline by stating 'Prefer this over list_issues when looking for text,' which helps the agent choose between similar tools. However, it does not specify when NOT to use (e.g., for exact ID lookups), leaving room for improvement.

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

update_issueUpdate issueC

Destructive

Update fields of an existing Redmine issue

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Issue id to update
`notes`	No	Comment added to the issue journal
`subject`	No
`status_id`	No
`done_ratio`	No
`description`	No
`priority_id`	No
`assigned_to_id`	No

TDQS

C2.7/5.0

Behavior2/5

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

The annotations already indicate destructiveHint=true, which is consistent with the 'Update' verb. However, the description adds no further behavioral context such as authentication requirements, error handling, or the fact that only provided fields are updated (partial update). With annotations present, the description's lack of additional transparency is noticeable.

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

Conciseness3/5

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

The description is a single sentence, front-loaded with the verb and resource. It is concise but too brief for a tool with eight parameters, failing to convey necessary detail while still being efficient.

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

Completeness2/5

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

Given the tool's complexity (8 parameters, no output schema, destructive operations), the description should mention that this is a partial update, that the issue must exist, and perhaps the effect on the journal. The current description leaves the agent underinformed.

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

Parameters1/5

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

Schema description coverage is only 25% (two out of eight parameters have descriptions); the description does not help interpret the remaining six parameters. It merely says 'Update fields' without explaining what each field does, leaving a significant gap for the agent.

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

Purpose5/5

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

The description clearly states the verb 'Update' and the resource 'fields of an existing Redmine issue', making the purpose immediately obvious and distinguishable from sibling tools like create_issue and get_issue.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., add_comment for comments only, or create_issue for new issues). The description does not mention prerequisites, limitations, or recommended usage scenarios.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv1.2.0Jul 13, 2026

Addedget_current_user

Changedlist_issues1 field changed

changedInput schema / properties / query / description

Previous value: -"Free-text search in subject; scans up to 500 matching issues"New value: +"Substring match in subject only; scans up to 500 issues. For full-text search (descriptions, comments, wiki) use the search tool"

Addedsearch

1 tool updatev1.1.0Jul 8, 2026

Changedget_issue1 field changed

addedInput schema / properties / include_journals

Added value: +{
+  "default": true,
+  "description": "Include comments and field-change history",
+  "type": "boolean"
+}

10 tool updatesv1.0.0Jul 7, 2026
- First observedadd_comment
- First observedcreate_issue
- First observedget_issue
- First observedget_project
- First observedlist_enumerations
- First observedlist_issues
- First observedlist_projects
- First observedlist_time_entries
- First observedlog_time
- First observedupdate_issue

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clear distinct purpose with no overlap. For example, 'list_issues' lists issues with filters, while 'search' provides full-text search across multiple object types, and 'add_comment' is specifically for adding notes. Even similar tools like 'get_issue' and 'list_issues' are distinct by returning one vs. many.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (e.g., create_issue, list_projects), but 'search' deviates as a single verb without a noun. This is a minor inconsistency, but overall the pattern is clear and predictable.

Tool Count5/5

With 12 tools, the server covers core Redmine operations (issues, projects, time tracking, enumerations, user info, search) without being overwhelming or sparse. Each tool serves a necessary function for typical workflows.

Completeness4/5

The tool set covers most common CRUD operations for issues (create, read, update, list, comment) and time entries, but lacks a delete_issue tool and project creation/update. Search and enumeration tools fill gaps, but a few lifecycle operations are missing.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

todo.vu AOAuth
io.github.mooball
Model Context Protocol server for todo.vu task management and time tracking.
Payments & Billing Project Management Workplace & Productivity
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Studex MCP ServerOAuth
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1
l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362

Related MCP Servers

Redmine MCP Server
Project Management Communication
yonaka15
A
license
Not graded
quality
F
maintenance
A Model Context Protocol server for interacting with Redmine using its REST API, enabling the management of tickets, projects, and user data through integration with LLMs.
Updated a year ago (2025-07-20 09:49 UTC)
78
MIT
Redmine MCP Server
Project Management Developer Tools
snowild
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables Claude Code to directly interact with Redmine project management systems, supporting issue management, project operations, and search features.
Updated 2 months ago (2026-07-11 08:05 UTC)
22
9
MIT
Redmine MCP Server
Project Management Developer Tools
compasify
A
license
C
quality
D
maintenance
Model Context Protocol (MCP) server for Redmine that provides comprehensive access to the Redmine REST API, enabling users to operate Redmine from MCP clients such as Claude Desktop.
Updated 6 months ago (2026-02-28 17:59 UTC)
90
15
MIT
Redmine MCP Server
Project Management Developer Tools
onozaty
A
license
C
quality
A
maintenance
Model Context Protocol (MCP) server for Redmine that provides comprehensive access to the Redmine REST API. It allows you to operate Redmine from MCP clients such as Claude Desktop.
Updated 13 days ago (2026-08-24 23:17 UTC)
90
1,907
24
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/andrelaptenok/redmine-mcp-stdio'

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