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

Annotations already cover the safety profile (not read-only, not destructive, closed-world). The description adds real value beyond that: a new session does not replace or affect the existing project and earlier sessions stay available — exactly the non-obvious, side-effect context an agent needs. It doesn't mention auth or rate limits, but those are minor here.

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 sentences, front-loaded with the verb and resource, then the usage trigger, then the non-impact guarantee. No wasted words; slightly padded by the dash clause, but each sentence earns its place.

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 needn't be described, and the annotations carry safety. Combined with the non-replacement guarantee, an agent has enough to call this correctly. Missing only explicit alternatives to route against sibling session tools.

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?

Schema coverage is 100%, so both params (label, project_id) are fully documented in the schema. The description adds only that the session belongs to a project, which is largely redundant. Baseline 3 when the schema does the work.

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?

Specific verb (create) plus resource (development session for a project) and clarifies it is a separate conversation with its own context. That scope statement distinguishes it from dreamagent_chat and dreamagent_list_sessions without opening a schema.

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?

Gives a clear triggering condition ('when the user wants to start a distinct development topic') but does not name the alternative tools — e.g. chat vs create_session or list_sessions — so an agent must infer the boundary itself.

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