Skip to main content
Glama
Sign In

KirinBoard

by ai.kirinboard
OverviewDiscussionsAdmin

Finished CI pushes, 1 to 12 hours ago

ci_history
Read-onlyIdempotent

Answers "did the push I made a few hours ago pass?". Lists the pushes on a repository that finished between 1 and 12 hours ago (or 1 and 4 hours ago), newest first, each with its branch, pull request, title, who pushed it, outcome (passed, failed, awaiting, superseded), when it finished, how long it took, its commit and a link to the run, plus a count of each outcome. Narrow it by branch, pull request, commit (sha, 7 or more characters) or outcome. It does not cover the last hour: for pushes queued, running or finished in the last hour, use ci_status. Read-only, and it never fails: if CI cannot be read it says why.

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

Input Schema

NameRequiredDescriptionDefault
prNoOnly pushes for this pull request number.
shaNoOnly the push of this commit (its first 7 or more characters).
repoNoowner/name. Optional when the token covers one repository.
hoursNoHow far back: 4 or 12 hours (default 12). Both read the same 12-hour list.
limitNoHow many pushes to list (default 20).
branchNoOnly this branch.
outcomeNoOnly pushes with this outcome.

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?

Annotations already cover read-only, idempotent, non-destructive, but the description still adds real behavior: newest-first ordering, the full result payload and per-outcome counts, and the notable guarantee that it "never fails" and instead explains why CI could not be read. It omits pagination/truncation behavior despite a limit parameter, which keeps it off a 5.

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-loads the user question, then scope, then payload, then exclusions — a sensible order with little filler given the amount of information conveyed. It is a dense single block of ~110 words, so a reader must parse it rather than skim, but no sentence is redundant.

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?

Seven optional parameters with no output schema, yet the description enumerates the returned fields (branch, PR, title, pusher, outcome, finish time, duration, commit, run link, outcome counts), which compensates for the missing output schema. Combined with the failure-mode note and sibling routing, nothing needed to call it correctly is missing.

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?

Schema coverage is 100%, so the parameters are already fully documented and the baseline is 3. The description only restates the filter set (branch, PR, commit sha 7+ chars, outcome) without adding semantics beyond the schema; the one nuance, that hours=4 and hours=12 read the same 12-hour list, is already in the schema description.

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 concrete verb and resource (lists pushes on a repository that finished 1–12 hours ago) and frames it with the exact question it answers. It explicitly distinguishes the sibling tool ci_status for the last-hour window, so an agent can route between the two 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 use context ("did the push I made a few hours ago pass?") and an explicit exclusion ("It does not cover the last hour ... use ci_status"), naming the alternative tool. The valid narrowing filters are also named, which closes the loop on how to use it.

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