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

Annotations declare a non-readOnly, non-idempotent, non-destructive write, and the description adds real context beyond them: editor defaults fill unset fields, a tip inherits the preceding step's screen unless overridden, and both demos:read and demos:write scopes are required. It stops short of describing failure modes or what is returned, but nothing contradicts the annotations.

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?

Front-loaded with the verb and resource, and the permissions requirement is isolated in its own short paragraph. The first sentence is parenthetical-heavy and slightly run-on, but every clause (kind list, placement, defaults) carries information an agent needs.

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 an 11-parameter nested-object mutation with no output schema, the description covers kinds, placement, defaults, screen inheritance and authorization. The notable gap is that it never says what comes back — presumably the new step id, which callers need for a follow-up update_step or move_step.

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?

At 64% schema coverage the description usefully adds meaning: it explains the six `kind` values in prose, defines `after` semantics including the "start" sentinel, explains the screen inheritance rule for `screenId`, and clarifies that `fields` is a catch-all for any other step field. It does not explain `place`, `body`, `title` or `ctaUrl` beyond what the schema already says, so it adds value without fully closing the gap.

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?

Starts with a specific verb+resource ("Adds a step to a guided demo") and then enumerates every step kind the tool can create, so the agent knows exactly what will be produced. The sibling set contains add_scene, update_step and move_step, and this definition is unambiguously the step-creation one.

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 concrete placement semantics (append by default, insert after `after` or at "start", always before a final outro) and states when to pass `screenId` versus relying on inheritance. It never names alternatives such as update_step or add_scene, so it is clear context without explicit exclusions.

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