keil_get_status

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

With no annotations, the description carries the full burden. 'get' plus the absence of destructive language implies a read, and the disclaimer about CPU state usefully bounds what the call observes. It says nothing about whether the call can block or time out when the server is unreachable, whether it requires an active session, or what the failure mode looks like — real gaps for a status probe.

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?

A single short sentence with zero filler, and the scope-limiting clause is placed immediately after the resource name. It is efficient but arguably over-compressed — the terseness itself is a source of ambiguity rather than of clarity.

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?

An output schema exists, so return values need not be described, and the empty parameter list removes schema burden. Still, in a 29-sibling Keil toolset where several tools report overlapping state (session log, connection diagnosis, project info), the definition does not do enough to tell an agent what distinguishes this status call from those neighbors.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description does not waste words re-explaining an empty schema.

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 names the resource ('server session/worker status') and adds a scope boundary ('does not claim to observe CPU state'), which hints at separation from keil_get_execution_state. However, it is a bare noun phrase with no verb, and 'status' is undefined — an agent cannot tell whether this returns a connection state, a worker count, a debugger health flag, or something else, versus keil_get_session_log or keil_diagnose_connection.

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?

The negative clause ('does not claim to observe CPU state') functions as an implicit when-not, steering the agent toward the CPU/execution-state siblings. But it never states when to use this tool, never names the alternative explicitly, and gives no prerequisites or context about when a session/worker check is warranted.

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