Skip to main content
Glama

BoardMark

by ai.boardmark
OverviewDiscussionsAdmin

Close one active sprint (project_admin, or members with `sprint_control: members` — D141); other active sprints are unaffected (D62)

close_sprint
Destructive

Close one active sprint (project_admin, or members with sprint_control: members — D141); other active sprints are unaffected (D62).

Requires project_admin, or a member when the project's sprint_control is members (agent tokens may close per that role). Closes ONLY the sprint in sprint_id (it must be active); other active sprints and their issues are untouched. Its issues not in a done status move per move_open_issues_to: backlog (default), new_sprint (a new planned sprint right after this one), or an existing PLANNED sprint id — an active sprint is refused (400), so to hand work to another running sprint, close into the backlog and then move_to_sprint those issues.

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
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.
sprint_idYesSprint id `S-{n}`, e.g. `S-12`.
project_keyYesProject key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter.
move_open_issues_toNoComplete sprint: where issues not in a `done`-category status go — `backlog` (default), `new_sprint` (board-core creates the next planned sprint), or the id of an existing planned sprint. backlog

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive=true and idempotent=false, and the description adds the substance behind that: exactly what is destroyed (one sprint's active state), where open issues go under each `move_open_issues_to` mode, why an active target sprint is refused, and the 409 version_conflict recovery procedure (re-read, re-apply, retry, never overwrite blindly). That is a materially richer behavioral picture than the annotations alone.

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?

Front-loaded with the action and its scope, then permissions, then fallout, then write/conflict protocol — a sensible ordering. It is dense but nearly every clause carries a constraint (D141, D62, 400 case, 409 case); the only waste is restating the title's 'other active sprints are unaffected' twice.

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 destructive, non-idempotent 5-parameter mutation with no output schema, the description covers authorization, side effects on issues, target-sprint eligibility, default behavior, and concurrency-failure handling. An agent could invoke this correctly on the first attempt.

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 the baseline is 3, but the description adds real semantics the schema does not: `version` must come from the latest read and stale values produce a 409 with details.current, and `move_open_issues_to` refuses an active sprint while `new_sprint` creates a planned sprint right after this one. Only `reason` is left entirely to the schema.

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 ('Close one active sprint') and immediately bounds the scope: 'Closes ONLY the sprint in `sprint_id` (it must be active); other active sprints and their issues are untouched.' This distinguishes it from `update_sprint` (edits) and `move_to_sprint` (issue relocation) without opening either schema.

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 explicit preconditions (project_admin, or a member when `sprint_control` is `members`; agent tokens per that role) and explicit routing guidance for the tricky case: handing work to another running sprint is refused with 400, so close into backlog then use move_to_sprint. When-to-use, when-not, and the alternative are all named.

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

All BoardMark toolsInspect
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