Skip to main content
Glama
Sign In

KirinBoard

by ai.kirinboard
OverviewDiscussionsAdmin

Thresholds behind the dashboard's judgements

settings
Read-onlyIdempotent

The thresholds the dashboard uses to judge a repository, as its team set them, and where each value comes from (the repository, the workspace, a settings file, or the default): when an in-progress item counts as stalled, how few tickets left and how much closed make an initiative almost done, how long a finished initiative stays in Recently finished, when an agent session counts as idle or parked, and the green and amber targets of the hygiene lines. Use it to understand why the dashboard called something stalled, almost done or parked. Only these thresholds: no other setting. The CI thresholds (when runners count as congested) come with ci_queue. Read-only, and it never fails: where the dashboard keeps no settings it says so.

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": "settings"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoNoowner/name. Optional when the token covers one repository.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds useful behavioral context beyond that: it says the tool 'never fails' and reports when no settings are kept, and it explains that each value's source is disclosed.

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?

The description is front-loaded with the resource and its contents, then moves to usage, exclusions, and behavior. It is dense but every sentence serves a purpose; the first sentence is long because it enumerates the threshold categories the tool returns.

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?

Given the single optional parameter and no output schema, the description is complete enough: it lists the returned threshold categories, explains the source information included, states the use case, excludes other settings, and notes the non-failure fallback behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one optional parameter, repo, and schema description coverage is 100%, so the schema already explains its format and optionality when the token covers one repository. The description does not add meaning about the repo parameter beyond the schema, so the baseline of 3 is appropriate.

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 resource -- the dashboard's judgement thresholds -- and enumerates exactly which thresholds are returned, including stalled, almost done, Recently finished, idle/parked sessions, and hygiene targets. It also distinguishes these from the CI thresholds returned by the sibling ci_queue tool.

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 an explicit use case: understand why the dashboard called something stalled, almost done, or parked. It also states a clear exclusion -- 'Only these thresholds: no other setting' -- and points to ci_queue for CI congestion thresholds.

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

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