Kilo-Kit

Overview Schema Source Related Servers Discussions Admin

Kilo-Sentinel Supervisor Status

kilo_sentinel_status

Read-onlyIdempotent

Inspect real-time supervisor telemetry—circuit breaker state, step budget, failure streaks, and grounded files—for an active Kilo-Kit session to monitor agent safety and progress.

Instructions

Inspect real-time Sentinel supervisor telemetry: Circuit breaker state, step budget, failure streaks, and grounded files list.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sessionId": "<sessionId>"
    },
    "name": "kilo_sentinel_status"
  }
}

Input Schema

Name	Required	Description	Default
`format`	No		markdown
`sessionId`	Yes	Active Kilo-Kit session ID

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 13, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds the notion of real-time telemetry and names the observable fields, which is useful context, but says nothing about freshness, staleness, permission requirements, or what happens for an inactive session.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with the resource front-loaded and the four observable fields listed in order. No filler, no restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the enumeration of returned telemetry partially stands in for a return-value contract, which is valuable. However, it omits the format parameter's effect on output shape and the relationship to the circuit-breaker reset sibling, leaving gaps for a diagnostic tool in a 24-tool cluster.

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

Parameters2/5

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

Schema coverage is only 50%: sessionId is documented as 'Active Kilo-Kit session ID', but the format parameter (enum markdown/json, default markdown) has no description anywhere. The description never mentions either parameter or the output format choice, so it fails to compensate for the coverage gap.

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?

States a specific verb ('Inspect') and resource ('Sentinel supervisor telemetry') and enumerates the concrete payload: circuit breaker state, step budget, failure streaks, grounded files list. That is far more specific than the title. It does not, however, differentiate itself from the closely related sibling kilo_reset_circuit_breaker, which touches the same circuit-breaker concept.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says what can be inspected but never says when to call this tool, what triggers it, or which sibling to use instead (e.g., kilo_reset_circuit_breaker when the breaker is tripped). 'Real-time' hints at diagnostic use but nothing is explicit.

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