Skip to main content
Glama

Create a planned release (D113, D189) — project admin or release manager; an AI agent may too (the token user's rights), with the default gate.

create_release

Create a planned release (D113, D189) — project admin or release manager; an AI agent may too (the token user's rights), with the default gate.

Releases must be on for the project (403 feature_disabled) and the company on a paid plan (403 plan_required, details.plan = pro). gate omitted = the default gate: automatic all_passed, no_critical, no_blocked (required) and no_high (optional); manual Release note, Deployment package, Rollback plan (required), CAB approval, Security review (optional). copy_gate_from = start from another release's gate instead (ticks not copied). D189: an agent token (MCP / PAT / OAuth, D144 agent account) may create a release when its user may: it starts planned with the default gate — gate or copy_gate_from from an agent → 403 agent_forbidden (the gate is set by people). The file records created_by_agent. Ticking the gate, locking the baseline, shipping, reopening and deleting stay with people in the web app (core-admin.yaml); board-core refuses them for every agent token.

Create a planned release (D189) only when the user asks for one: name (unique in the project), target_date (the planned production day, YYYY-MM-DD), optional milestones and body, and a short reason. It starts planned with the project's default gate — never send gate or copy_gate_from (403 agent_forbidden): people set the gate in the web app. Needs your user to be a project admin or release manager (else 403 forbidden — tell the user who can), releases on (403 feature_disabled) and a paid plan (403 plan_required). Then put work in with add_to_release. Tell the user the gate, baseline and shipping stay with people in BoardMark.

Input Schema

NameRequiredDescriptionDefault
bodyNo
gateNoThe complete gate list. New manual items get an id from the title when `id` is missing.
nameYes
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).
milestonesNo
project_keyYesProject key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter.
target_dateYesCalendar date `YYYY-MM-DD` (Asia/Bangkok).
copy_gate_fromNoRelease id (spec D113): `R-` + a number, unique in its project; the file is `releases/R-{n}.md`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, the description discloses the initial status (planned), default gate behavior, agent-token restrictions, 403 error codes, and that created_by_agent is recorded. It also explains that gate edits, baseline locking, shipping, reopening, and deletion remain people-only operations.

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 content is front-loaded and useful, but the description repeats the same agent restriction and default-gate information across multiple paragraphs. It is verbose and could be shortened without losing behavioral guidance.

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 an 8-parameter creation tool with no output schema, the description covers prerequisites, agent-specific constraints, default behavior, error conditions, and the next step. An agent has enough context to avoid forbidden calls and to know when creation is allowed.

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 63%, and the description adds meaningful semantics for key parameters: name uniqueness, target_date as the planned production day, reason for agent logs, and the agent prohibition on gate/copy_gate_from. Some schema-documented parameters still rely on the schema, so it is strong but not fully compensating.

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 states a specific verb and resource — create a planned release — and clearly scopes it to the project, including the default gate and agent restrictions. It distinguishes this from related actions such as adding work with add_to_release and from people-only actions like shipping or locking the baseline.

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 explicit when-to-use guidance: only when the user asks for a release, with required fields and prerequisites. It also names the follow-up tool add_to_release and explicitly says agents must not send gate or copy_gate_from, routing that decision to people in the web app.

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