KirinBoard

Initiatives a few tickets from finished

almost_done

Read-onlyIdempotent

Finds the last tickets that would finish an initiative, and which of them are free to pick up. An initiative is a parent ticket that groups the tickets of one larger piece of work. For a repository it lists the initiatives the dashboard classes as almost done (a few tickets left that belong to the original push; by default 3 or fewer open and at least 75% closed, a setting the team can change), smallest remainder first. Each comes with its remaining tickets (number, title, link, phase, whether someone is working on it, who has claimed it) and the dashboard's reason in plain words. Use it when your human asks what is close to finished, or when you are choosing what to work on: closing one of these tickets finishes something. unclaimed_only lists only tickets nobody is working on or has claimed. include_next_part also lists initiatives whose first part is done but whose remaining tickets were filed later and not started (better moved into a new initiative than counted as nearly done). Read-only, and it never fails: if the list cannot be read it says why. Before starting a ticket, check it with board and claim it as usual.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "almost_done"
  }
}

Input Schema

Name	Required	Description
`repo`	No	owner/name. Optional when the token covers one repository.
`limit`	No	How many initiatives (default 10).
`unclaimed_only`	No	Only tickets that are free to pick up: not in progress and claimed by nobody. Initiatives with none are left out (and counted).
`include_next_part`	No	Also list initiatives whose first part is done and whose next part has not started.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds real behavioral context on top: the classification thresholds (3 or fewer open, at least 75% closed, team-configurable), sort order (smallest remainder first), the exact fields returned, and the notable guarantee that it 'never fails: if the list cannot be read it says why.'

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?

Purpose and scope are front-loaded and every sentence carries information, but it is a single dense block with stacked parentheticals (threshold definition, include_next_part caveat) that slow scanning. Slightly tighter phrasing or light structure would improve it.

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?

No output schema exists, and the description compensates by enumerating what each result contains (number, title, link, phase, claim state, reason) plus ordering and emptiness behavior. Nothing an agent needs to call it or interpret the result is missing.

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; the description goes slightly beyond by explaining a side effect not in the schema for unclaimed_only ('Initiatives with none are left out (and counted)') and the rationale for include_next_part ('better moved into a new initiative than counted as nearly done'). repo and limit are left 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: finds the last tickets that would finish an initiative and which are free to pick up. It also defines the domain term ('an initiative is a parent ticket that groups the tickets of one larger piece of work') and the ranking rule, which separates it from siblings like quick_wins or left_behind without needing those schemas.

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

Usage Guidelines4/5

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

Gives explicit triggers ('when your human asks what is close to finished', 'when you are choosing what to work on') and a follow-up workflow ('check it with board and claim it as usual'). It stops short of naming the closest alternative sibling (quick_wins/left_behind) and saying when to prefer those instead.

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

All KirinBoard tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?