Skip to main content
Glama
dokkiitech

redmine-mcp

by dokkiitech

create_issue

Creates a new Redmine issue from a project ID and subject, with optional tracker, priority, assignee, parent task, custom fields, and attachments.

Instructions

チケットを新規作成する。

Args: project_id: プロジェクトの identifier または数値 ID subject: 件名(必須) description: 説明(Textile/Markdown は Redmine 設定に従う) tracker_id: トラッカー数値 ID。プロジェクトで有効なもののみ(無効な ID は Redmine が黙って別トラッカーに差し替える。get_project で有効トラッカーを確認) priority_id / assigned_to_id: 数値 ID(list_metadata で確認) parent_issue_id: 親チケット ID(サブタスクにする場合) custom_fields: カスタムフィールド(例: [{"id": 2, "value": "32"}]) uploads: 添付(例: [{"token": "...", "filename": "a.txt"}]。先に upload_attachment)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subjectYes
uploadsNo
project_idYes
tracker_idNo
descriptionNo
priority_idNo
custom_fieldsNo
assigned_to_idNo
parent_issue_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

アノテーションがないため説明が全責任を負う。無効な tracker_id を Redmine が黙って別トラッカーに差し替えるという重要な挙動を開示しており、uploads の前提も述べている点は価値がある。しかし権限要件や作成の可逆性、失敗時の挙動には触れておらず、変異ツールとしての開示は不完全。

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?

目的を先頭に置き、その後に引数を簡潔に列挙する構造で無駄が少ない。引数説明は必要な粒度でまとまっており、冗長ではない。

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?

出力スキーマが存在するため戻り値の説明は不要。作成時の重要な注意点(トラッカーの差し替え、アップロードの前提)を網羅しており、9 パラメータのツールとして概ね完全。

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?

スキーマ説明カバレッジは 0% で 9 個のパラメータがあるため説明が補う必要がある。各引数に意味を与え、tracker_id の有効性制約、custom_fields と uploads の具体例、必須フラグまで明示しており、スキーマ以上の価値を提供している。

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?

「チケットを新規作成する」は明確な動詞+リソースで、update_issue や create_project などの兄弟ツールと混同しにくい。ただし、いつ使うべきかの兄弟ツールとの差別化には触れていない。

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?

明示的な when-to-use/when-not はないが、uploads には先に upload_attachment が必要、tracker_id は get_project で確認、priority_id/assigned_to_id は list_metadata で確認といった前提条件を埋め込んでいる。使用コンテキストは示唆されているが、代替ツールとの選択基準はない。

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