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

Annotations declare this a non-destructive, closed-world read, and the description meaningfully extends that: only Webba library graphics are used, no new artwork is generated, and on no-match it reports failure and names the closest match. That fallback/constraint disclosure is exactly the kind of behavior annotations cannot express. Minor gap: no output schema exists, yet the description never says what a successful call returns (a build state, a preview, a list of parts), which would help the agent chain into get_download.

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 use case and closed by exclusions that name the exact alternatives. No filler, no restatement of the title, and the negative constraint (no new artwork) is placed where it will be read before the call rather than buried.

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 7-parameter tool with a nested object and no output schema, the description covers the essential decision context: library-only sourcing, failure behavior, and routing to siblings. The remaining gap is the return shape on success, which matters because the sibling get_download consumes a state this tool presumably produces.

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 description coverage is 100% and every parameter (font, colour, graphic, tagline, placement, business_name, from_state) is documented inline with examples and constraints, so the baseline of 3 applies. The description adds no per-parameter meaning beyond what the schema supplies; its only related signal is the round-trip hint about passing a design's state to get_download, which is arguably a header-level clarification but does not explain how from_state seeds colours and tagline.

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?

States a concrete verb and resource ('build a logo from parts') and immediately grounds it with examples ('a phone with a chat symbol') and the case that motivates it ('a graphic, lettering or placement a ready made design can't change'). An agent can distinguish it from find_designs, get_download, and update_design without opening any 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?

Explicitly names both when to use (person describes a composite graphic or wants customization a ready-made can't provide) and when not to use ('just wants logo ideas' → find_designs; 'choose or download a design already shown' → pass state to get_download). Alternatives are named with the condition that selects each.

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