Skip to main content
Glama

Edit a planned release — name, production date, milestones, gate items, description (project admin or release manager; D189: an AI agent only name, date, milestones, description, before the baseline is locked).

update_release

Edit a planned release — name, production date, milestones, gate items, description (project admin or release manager; D189: an AI agent only name, date, milestones, description, before the baseline is locked).

gate is the complete new list: items kept by id keep their ticks (done_by / done_at); a released release → 409 release_released. D189: an agent token may change only name, target_date, milestones and body, and only while the release is planned and its baseline is not locked — gate from an agent, or a baselined release → 403 agent_forbidden (people decide after the baseline).

Edit a planned release's name, target_date, milestones or body (D189): get_release first and pass its frontmatter.version, change only what the user asked, give a reason. Once a person has locked the baseline, or for the gate, you get 403 agent_forbidden — stop and tell the user a release manager changes it in the web app. A released release → 409 release_released.

WRITE: version = from your latest read (get_issue, list_comments, list_sprints, get_doc, read_file). 409 version_conflict (details.current, details.current_version): re-read, re-apply your change, retry — never overwrite blindly; when the changes disagree, ask the user.

Input Schema

NameRequiredDescriptionDefault
bodyNo
gateNoThe complete gate list. New manual items get an id from the title when `id` is missing.
nameNo
reasonNoSpec D144: why you make this change (≤ 200 characters). Optional, but give it when you act as an agent account — it is shown in the agent's run log ("moved KJ-12 To Do → In Progress because <reason>"). board-mcp records it in `agent.run`; board-core / board-files accept it and ignore it (it never changes the file, the version or the history).
versionYesOptimistic-lock version of the file; +1 on every write. Every write must send the version it read.
milestonesNo
release_idYesRelease id (spec D113): `R-` + a number, unique in its project; the file is `releases/R-{n}.md`.
project_keyYesProject key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter.
target_dateNoCalendar date `YYYY-MM-DD` (Asia/Bangkok).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Far beyond what the annotations declare: it explains that `gate` is a complete replacement list, that items kept by id retain their ticks (done_by/done_at), and that a released release returns 409 release_released. The D189 agent-token restrictions and the 409 version_conflict retry protocol (re-read, re-apply, retry, never overwrite blindly, ask the user on disagreement) are exactly the behavioral context an agent needs and no structured field provides.

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 title is pasted verbatim as the opening sentence, and the D189 agent restrictions are stated three separate times in slightly different words. The useful rules are front-loaded, but a third of the text could be cut without losing information.

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 mutation tool with no output schema, the description covers permissions, required prior read, conflict handling, forbidden cases, and the terminal 409 state. Nothing an agent needs in order to call it correctly or to know when to stop 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 coverage is only 67%, and the description compensates well: it defines gate as the complete new list with id-based tick preservation, ties `version` to the get_release read and the 409 conflict payload (details.current_version), and explains when `reason` matters for agent accounts. This adds real meaning beyond the field-level schema text.

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 first sentence names the verb (Edit), the resource (a planned release), the exact mutable fields, and the actor permissions. It is immediately distinguishable from create_release, move_to_release, and update_issue, which sit beside it in the sibling list.

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

Usage Guidelines5/5

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

It gives an explicit precondition workflow — call get_release first and pass frontmatter.version, change only what the user asked, supply a reason. It also names the exact stop conditions (403 agent_forbidden / 409 release_released) and instructs the agent to hand off to a release manager in the web app rather than retrying.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources