Check GitHub Actions runtime, action-major, and five Project Telos flagship CI compatibility. Returns a read-only, zero-auth JSON CI doctor register with no external side effects.
Use when a host needs GitHub Actions runtime, action-major, and latest five-flagship CI compatibility receipts. Read-only, zero-auth, no external side effects. Returns a JSON CI doctor register.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full safety burden and does so well: 'Read-only, zero-auth, no external side effects' explicitly declares the safety profile, which is the key trait an agent needs before calling. It does not cover error/determinism behavior or how verbose the register is, but for a zero-parameter diagnostic the disclosed traits are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler: trigger first, safety profile second, return shape third. The structure is well front-loaded, though the dense run of hyphenated jargon ('action-major', 'latest five-flagship') costs some readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and no parameters, so the description bears the entire explanatory burden. It names the return type ('a JSON CI doctor register') but never says what the register contains or what a failing/passing receipt looks like, leaving the agent unable to interpret results. That is a real gap for a results-producing diagnostic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters (additionalProperties: false), so there are no parameter semantics to explain and the baseline is 4. Nothing in the description contradicts or misdescribes the empty argument surface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource: GitHub Actions runtime, action-major, and latest-flagship CI compatibility receipts, positioned as a diagnostic ('doctor') alongside sibling doctors like telos.presentation.doctor and telos.accessibility.doctor. The verb is only implied (it produces a register) and the phrase 'latest five-flagship' is opaque jargon, but an agent can tell this is a CI compatibility diagnostic rather than a general health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
An explicit trigger is given: 'Use when a host needs GitHub Actions runtime, action-major, and latest five-flagship CI compatibility receipts.' That is a clear usage condition rather than implied usage. It does not, however, distinguish this from the sibling telos.ci.triage or state any exclusion, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.