BoardMark

Move an issue before or after another one in board/backlog order (manual rank)

rank_issue

Move an issue before or after another one in board/backlog order (manual rank).

Give exactly one of before / after (plus version, and reason if you like). Only the moved issue is written.

Give EXACTLY ONE of before or after (another issue key in the same project) plus version — never both, never neither. Only the moved issue gets a new version.

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
`after`	No	Issue key `{PROJECT}-{n}`, e.g. `KJ-101`.
`before`	No	Issue key `{PROJECT}-{n}`, e.g. `KJ-101`.
`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.
`issue_key`	Yes	Issue key `{PROJECT}-{n}`, e.g. `KJ-101`.
`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

A3.9/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, idempotentHint=false), the description discloses what is actually mutated ('Only the moved issue is written ... gets a new version') and spells out concurrency behavior that annotations cannot express: version must come from the latest read, 409 version_conflict with details.current/details.current_version requires re-read, re-apply, retry, never overwrite blindly, and ask the user on disagreeing changes.

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 rule about exactly one of before/after is stated twice, and the write scope is repeated ('Only the moved issue is written' / 'Only the moved issue gets a new version'). The first line duplicates the title verbatim rather than extending it. The content is front-loaded and none of it is wrong, but roughly a third is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter write tool with full schema coverage and annotations, it covers the two things an agent would otherwise get wrong: mutual exclusivity of before/after and optimistic-lock recovery. It omits what the call returns (no output schema exists) and does not say what happens if the anchor issue is not rankable, which leaves a small gap.

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 baseline is 3, but the description adds real semantics the schema does not encode: before/after are mutually exclusive and one is mandatory (schema marks both optional with no oneOf), they must reference an issue in the same project, and version must originate from a named set of read tools. The 'reason' parameter adds nothing beyond its own schema text.

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 opening sentence states a specific verb and resource plus the exact scope: move an issue before or after another one in board/backlog order (manual rank). This is operationally distinct from status-changing siblings, but the description never names an alternative such as transition_issue or update_issue, so the agent must infer the boundary itself.

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

Usage Guidelines3/5

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

It gives hard invocation rules ('Give exactly one of before/after ... never both, never neither') and the prerequisite that version comes from a fresh read, which is genuine usage guidance. However there is no statement of when to prefer this over sibling tools that also reposition work (move_to_sprint, move_to_release, transition_issue), so the routing decision is only implied.

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?