Delimit Daemon Status

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

Even though annotations already declare readOnlyHint and idempotentHint, the description adds meaningful behavioral detail: it states 'Side effects: read-only', explicitly reveals the underlying backend call ai.daemon.get_daemon_status, and clarifies that it reads runtime state. These details go beyond what annotations alone provide and leave no hidden side effects.

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?

The description is tightly structured with clear, scannable sections: purpose, when to use, when not to use, sibling contrast, side effects, args, and returns. Every sentence adds information, and the most critical usage guidance is front-loaded.

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?

For a zero-parameter, read-only status tool with annotations covering safety and an output schema available, the description is fully adequate. It even enumerates the returned fields (loop counts, items processed, recent actions, next_steps), giving the agent a complete mental model with no missing context.

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 and the input schema confirms this, so there is no parameter semantics burden. The description additionally states 'Args: None', removing any ambiguity for the agent.

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 begins with a specific verb and resource: 'Report the autonomous daemon's status', and lists the exact observed dimensions (loops, items, actions). It also explicitly differentiates itself from siblings like delimit_daemon_run, which advances iterations, making the tool's purpose unmistakable.

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 description provides a dedicated 'When to use' section, a 'When NOT to use' section with named alternative tools, and a sibling contrast note. This is exemplary routing guidance: an agent knows exactly when to call this tool and when to call delimit_daemon_run or delimit_daemon_classify instead.

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