Skip to main content
Glama
Sign In
cohors

cohors

by rushirb2001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

CI status

ci_status
Read-onlyIdempotent

Check CI/checks status per repository to find failing, passing, or pending checks. Scope results with a selector and pass failing repos to other tools for action.

Instructions

CI / checks status per repo (GitHub-enriched: passing | failing | pending). Use for "which repos have red/failing CI?"; to then act on them, pass {"ci": "failing"} as a selector to another tool. Needs a token; repos without a GitHub remote are omitted. An optional selector scopes the set.

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_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
selectorNoPredicate that selects repos across the fleet; set fields to AND them, omit a field for no constraint (ADR-024). Scope: all (bool — the whole fleet), ids[str], name (glob, e.g. "pay*"), path_glob (* stays within one path segment, ** crosses /), root, group (a config-defined cluster name, e.g. "payments"). Local state: dirty, ahead (alias unpushed), behind, diverged, no_upstream, unpublished (a branch never pushed although the repo has a remote), stale_fetch (remote not fetched for over 14 days), has_stash, detached, conflicted, in_operation (merge/rebase/… mid-flight), error, branch (exact name), attention ("any"|"notice"|"warn"|"risk"). Remote (needs a GitHub token): ci ("passing"|"failing"|"pending"|"none"), min_prs (int). Combine: any_of[selector] (OR), not (selector). The empty selector {} matches NOTHING by design — pass {"all": true} for the whole fleet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive/open-world, and the description adds behavior the annotations don't: it requires a token and silently omits repos without a GitHub remote. Those omission semantics directly affect result interpretation. It doesn't describe result ordering or pagination, but with no output schema the per-repo status enumeration covers the essentials.

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?

Four short sentences, front-loaded with the purpose and status domain before the usage example, auth caveat, and selector note. Nothing is padded, though the final selector sentence is near-redundant with the schema.

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 read-only, zero-required-param query tool with a very rich selector schema, the description supplies the missing pieces an agent needs: the returned status domain, the token prerequisite, and the omission behavior for non-GitHub repos. The absence of any note on result shape beyond status values is a minor gap given no output schema exists.

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 description coverage is 100%, so the selector's fields, combinators, and the empty-selector-matches-nothing rule are already fully documented in the schema. The description only restates that the selector is optional and scopes the set, plus one concrete {"ci": "failing"} example that mirrors the schema's enum — a modest, not substantive, addition.

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 description gives a specific verb+resource ('CI / checks status per repo') and enumerates the value domain (passing | failing | pending), which is enough to distinguish it from a general summary tool. It does not, however, name any sibling (fleet_summary, overview, changes) explicitly, so an agent has to infer the boundary from the fleet of similarly-titled status tools.

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 a concrete triggering question ('which repos have red/failing CI?') and explicitly describes the hand-off pattern — pass {"ci": "failing"} as a selector to another tool. It stops short of saying when NOT to use it (e.g., when a fleet-wide summary or PR listing is what the agent actually wants), so exclusions are missing.

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

Deploy Server

Other Tools