Skip to main content
Glama
Sign In

KirinBoard

by ai.kirinboard
OverviewDiscussionsAdmin

Which pull request gates usually fail

gate_compliance
Read-onlyIdempotent

Shows how a repository's pull request gates have fared over the last 7 and 30 days. A gate is a check the dashboard grades every pull request by (for example agent identity, persona, or "closes an issue"). For each gate: how many pull requests passed it, failed it, would have failed it (the gate only warns for now), were not checked by it, are still pending or not read yet, and were exempt (promotions, bots, or an exempt label); and the dashboard's verdict on whether the gate is ready to enforce. The gates that refused the most pull requests come first. Call it before you open or push a pull request, to see which gates usually trip pull requests here and meet them first. Counts only, no logs. Gate compliance is switched on per repository; where it is off, the answer says so. Read-only, and it never fails: if the counts 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": "gate_compliance"
  }
}

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
Behavior5/5

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

Annotations only cover the safety profile (read-only, idempotent, non-destructive), and the description adds substantial context beyond that: counts only, no logs; per-repository enablement with an explicit 'off' response; and a never-fails contract where failures explain themselves. It also discloses result ordering ('gates that refused the most pull requests come first'), which is behavior an agent cannot infer from annotations.

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 is front-loaded in the first sentence and each subsequent sentence carries distinct information (gate definition, returned counts, ordering, usage timing, edge cases). The middle sentence is a dense semicolon run-on, which costs some readability, but nothing is genuinely 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?

There is no output schema, so the description carries the return-shape burden and does so thoroughly: it enumerates the per-gate outcomes (passed, failed, would-have-failed, not checked, pending/unread, exempt) and the enforcement verdict. Combined with annotations covering safety, an agent has everything needed to call and interpret this tool.

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?

With a single parameter at 100% schema description coverage, the schema already documents 'owner/name. Optional when the token covers one repository.' The description adds nothing about the repo argument, so the baseline 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 names a specific verb and resource ('shows how a repository's pull request gates have fared over the last 7 and 30 days') and goes further by defining the domain term 'gate' with concrete examples. No sibling tool concerns gates or compliance verdicts, so it is clearly separable from tools like ci_status or ci_history.

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?

It gives an explicit trigger: 'Call it before you open or push a pull request... and meet them first,' which tells the agent exactly when this tool is the right choice. It stops short of naming an alternative tool or a when-not-to-use condition, so 4 rather than 5.

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