Kaiku

Update issue

update_issue

Destructive

Update an issue: any of summary, description, type, assignee, priority, labels, dueDate, parentKey, fixVersions, or status (which performs the transition, and fires the project's rules — a rule may append a checklist to the description, in which case 'description' is listed in 'changed'). Only the fields you pass are changed. A project's workflow may put conditions on a move — that only certain people may make it, or that it must set certain fields — and a refusal names the condition and, where it is about who you are, lists the states you CAN reach. Fields a move requires must be sent in this same call, with 'resolution' and 'fields': a value set by an earlier call does not satisfy the condition. Answers with 'notified' (who this actually reaches: the people mentioned, and for an assignment the new assignee as 'assignee' and the one taken off as 'unassigned' in 'as' — never yourself) and 'unresolvedMentions' (what looked like a mention and reached nobody, each with a reason) — a wrong handle is stored as written and never refused, so that list is the only sign it did not land.

Input Schema

Name	Required	Description
`key`	Yes	Issue key, e.g. 'UK-1'.
`type`	No	New issue type name, e.g. 'Task', 'Bug', 'Story', 'Epic'.
`fields`	No	The project's own columns to fill in with this update, by their NAMES: 'Segment=AI; Country=Poland', or a JSON object. Same shape as set_issue_fields — this exists here because a move a workflow conditions on a column has to set it in the same call.
`labels`	No	Labels to set, space or comma separated. Replaces the existing set.
`status`	No	Status name to move the issue to, e.g. 'In Progress', 'Done'.
`dueDate`	No	The day this is due, as YYYY-MM-DD. A calendar day, not a timestamp. Pass an empty string to clear it.
`summary`	No	New summary (title).
`assignee`	No	Assignee username or email. Pass an empty string to unassign. 'agent:<role>' (e.g. 'agent:product') hands the issue to that agent instead: you become the assignee and the agent works on your behalf — allowed only where a switched-on duty of that role in this project takes issues like this one (list_project_rules shows the duties).
`priority`	No	Priority name, e.g. 'High'.
`parentKey`	No	Key of the issue this one hangs off, e.g. 'PM-276' — moves it under that story or epic. To DETACH it instead, send detachParent: true; an empty string still works but is easy to lose on the way. Nothing is renamed and the key never changes: an issue keeps the key of the project it lives in. A sub-task must stay in its parent's project; anything else may cross projects.
`resolution`	No	Resolution name to set, e.g. 'Fixed', 'Won't Do'. Some workflows require one on the move into a finished state; sending it here is how that condition is met.
`description`	No	New description. Markdown, with $…$ / $$…$$ LaTeX formulas and [~username] mentions.
`fixVersions`	No	The versions of the project this goes out in, by name, comma-separated: '2.4.0, 2.4.1'. REPLACES the set — to add one, send the ones it has (get_issue's 'fixVersions') with the new one. Pass an empty string to take it out of every version. A name the project does not have refuses the update and lists the ones it has.
`detachParent`	No	Take this issue out from under its parent and leave it top-level. The reliable way to detach: unlike an empty parentKey it cannot arrive as the two characters "" or be dropped as «nothing was sent». Refused together with a parentKey, since the two would be asking for opposite things.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

addedInput schema / properties / fixVersions

Added value: +{
+  "default": null,
+  "description": "The versions of the project this goes out in, by name, comma-separated: '2.4.0, 2.4.1'. REPLACES the set — to add one, send the ones it has (get_issue's 'fixVersions') with the new one. Pass an empty string to take it out of every version. A name the project does not have refuses the update and lists the ones it has.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

First observedSep 22, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With only generic annotations (destructiveHint=true), the description carries real behavioral weight: it explains that a status change fires project rules, may append a checklist and marks 'description' as changed; that refusals name the failing condition and list reachable states; and that a wrong handle is stored silently rather than rejected. That is exactly the kind of consequence disclosure the annotations cannot provide.

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?

It is front-loaded with the field list and every sentence carries substantive information, including return-value semantics for a tool with no output schema. However, the nested em-dash parentheticals (the status/rule clause, the notified clause) make it dense and force a second read.

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 14-parameter mutation with no output schema, the description covers the missing pieces: partial-update semantics, workflow preconditions and refusal shape, and the 'notified'/'unresolvedMentions' response fields. An agent has enough to call this correctly and interpret the result.

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?

Schema coverage is 100%, so a 3 would be the floor; the description earns more by adding meaning the schema lacks, e.g. that status triggers the transition machinery and rules, that fixVersions replaces rather than appends, and that detachParent is the reliable alternative to an empty parentKey. It stops short of 5 only because most per-field syntax details are already in the schema.

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 opens with a specific verb and resource and enumerates every updatable field, so an agent knows exactly what the tool mutates. It even clarifies that 'status' performs a transition. It falls short of a 5 because it never contrasts itself with the sibling move_issue or set_issue_fields (it only notes the 'fields' parameter shares their shape), leaving the boundary blurred.

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?

It states a clear partial-update contract ('Only the fields you pass are changed') and spells out the condition for combining parameters: workflow-required fields must be sent in the same call as the move, with resolution and fields. What is missing is explicit routing versus alternatives such as move_issue when the intent is purely to relocate an issue.

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

All Kaiku tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?