BoardMark

Change a sprint's name, dates or goal (project_admin, or members with `sprint_control: members` — D141; D61). Send the version you read.

update_sprint

Destructive

Change a sprint's name, dates or goal (project_admin, or members with sprint_control: members — D141; D61). Send the version you read.

Planned and active sprints: name, start, end, goal. Closed sprints: name and goal only (dates are history) — dates on a closed sprint → 409 sprint_closed. end must not be before start (400). Publishes core.sprint.changed. reason alone is not a change (400).

Rename a sprint, move its dates or change its goal. Requires project_admin, or a member when the project's sprint_control is members. Call list_sprints first and pass the sprint's version; send only the fields to change (name, start, end as YYYY-MM-DD, goal — null clears it) — all of them in ONE call. Planned and active sprints accept every field; a CLOSED sprint keeps its dates (they are history): sending start or end for it fails with 409 sprint_closed — change only name/goal there. end must not be before start (400). Moving an active sprint's dates changes its burndown date range. Do not use write_file on sprints/*.md for this.

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

Name	Required	Description
`end`	No	Calendar date `YYYY-MM-DD` (Asia/Bangkok).
`goal`	No
`name`	No
`start`	No	Calendar date `YYYY-MM-DD` (Asia/Bangkok).
`reason`	No	Spec 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).
`version`	Yes	Optimistic-lock version of the file; +1 on every write. Every write must send the version it read.
`sprint_id`	Yes	Sprint id `S-{n}`, e.g. `S-12`.
`project_key`	Yes	Project key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / reason

Added value: +{
+  "description": "Spec 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).",
+  "maxLength": 200,
+  "type": "string"
+}

First observedOct 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes far beyond the annotations: closed sprints reject `start`/`end` with 409 sprint_closed, `end` before `start` yields 400, `reason` alone is a 400, the write publishes core.sprint.changed, and moving an active sprint's dates shifts its burndown range. It also spells out the version-conflict recovery loop (409 version_conflict → re-read, re-apply, never blind-overwrite), which is exactly the operational context destructiveHint=true cannot convey.

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?

Front-loaded and scannable, but the title string is pasted verbatim as the opening paragraph, and the closed-sprint rule plus the `end` >= `start` (400) rule are each stated twice in near-identical wording. Redundancy costs length without adding 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?

With 8 parameters, no output schema, and destructive/non-idempotent semantics, the description covers permissions, per-state field legality, validation errors, version locking, side effects (event publish, burndown), and conflict recovery. Nothing an agent needs to call it safely 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 75%, but the description still adds real meaning: only send the fields you want changed, do it in ONE call, `goal: null` clears the field, and dates are YYYY-MM-DD. It also explains that `version` must come from the latest read and that `reason` never mutates the file — nuance the schema's own text only partly covers.

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?

States a specific verb and resource ('Change a sprint's name, dates or goal') and enumerates the mutable fields. It also explicitly rules out the nearest sibling-style alternative ('Do not use write_file on sprints/*.md for this'), which is the exact confusion an agent could have given write_file/read_file 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?

Gives an explicit precondition ('Call list_sprints first and pass the sprint's version'), the permission model (project_admin, or member when `sprint_control` is `members`), and the exclusion of the file-based path. The agent knows when to reach for this versus write_file or close_sprint without inference.

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

All BoardMark tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?