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

Beyond the annotations (mutating, idempotent, non-destructive), the description discloses the iterative clarification protocol: do not invent missing details, ask about ambiguous days/times/timezone, batch open_questions into one message, repeat until ready_to_submit, and delegate image saving to owner_photos. It also explains what the response contains, which is especially valuable given there is no output schema.

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?

Roughly 150 words cover a genuinely complex multi-turn workflow with no filler; the most important constraints (don't invent, keep draft_id, batch questions, loop until ready_to_submit) are front-loaded. Every sentence contributes either a prerequisite, a mode switch, or an orchestration rule.

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 nested 4-parameter tool with no output schema, the description supplies the missing workflow context: response shape (accepted, missing, open_questions), iteration until ready_to_submit, the preview/approval gate, and image-handling delegation to owner_photos. An agent has enough to begin and continue the guided setup correctly.

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?

With only 50% schema coverage, the description adds important meaning to draft_id, new_business, and copy_from_business_id, including the distinction between a new business and a new location of an existing business. It does not enumerate the large answers object, but the schema provides field-level detail and the description explains the conversion rule and the break-hour nuance.

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 identifies a specific action (guided business onboarding for Awning owners), a specific resource (a business draft), and the key behavior (converting natural-language description, prices and hours into structured answers). It also distinguishes itself from related sibling tools like owner_preview, owner_submit, and owner_photos, so an agent can tell this tool apart.

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 gives explicit conditions and routing: only for business owners signed in to Awning, use new_business=true for a separate business, and use copy_from_business_id and ask only what differs for a new location. It also says to use owner_preview and explicit approval before owner_submit, which is clear when-to-use guidance rather than leaving alternatives to inference.

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