dream_status

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

With no annotations, the description carries the full burden and discloses important behavioral context: the queue behavior when no Dreamina tab is live, the meaning of an expired license, and the fact that the queue self-resumes after activation. It also clarifies what extension.director contains (prompt formula, technique catalog, credits).

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 front-loaded with what state is reported, then gives the critical usage instruction, then covers the license edge case. Every sentence adds actionable information, and no space is wasted on redundant or vague phrasing.

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?

Given no output schema and no annotations, the description adequately explains the returned state fields and their operational significance. It covers normal operation, the no-tab failure mode, and the expired-license case, leaving the agent prepared to act on the status information.

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?

There are zero parameters, so the schema has no parameter semantics to add and the baseline is 4. The description rightly focuses on state interpretation and usage rather than parameter details.

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 states a specific resource and its scope: bridge and extension state, including connection, Dreamina tab presence, queue contents, and extension.director details. It clearly distinguishes this status/inspection tool from sibling action tools like dream_generate, dream_edit, dream_wait, and dream_cancel.

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?

It explicitly says to call it BEFORE generating and explains the consequence of skipping that step: jobs pile up without a live Dreamina tab. It also gives a specific action path when extension.license is expired, including a URL and the fact that the queue resumes automatically.

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