Sales landing page

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

Annotations only say write, non-destructive, open-world; the description goes far beyond that by disclosing the honesty constraints (never invents reviews, guarantees or prices), the media fallback behavior (autoImages fetches free mood photos), the scroll-linked motion model, generated SEO/Open Graph/structured data, and the concrete deploy targets for the output file. This is exactly the extra context an agent needs for a generative, network-touching tool.

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 purpose and organized into identifiable blocks (structure, motion, media, theme, extras, deploy). It is still a dense wall of prose, and it repeats structured data verbatim — the full theme enum list and the fonts/nav/buttons/countdown re-roll are already in the schema.

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 38-parameter generative tool with nested objects and no output schema, the description covers the output (one HTML file), its deploy destinations, and the major behavioral guards. Its main remaining gap is the return shape — whether a path, HTML string or hosted URL comes back is only hinted at.

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 63% schema coverage across 38 params, the description earns credit for explaining the important ones: images/productImage/videoUrl/modelUrl media modes, autoImages fallback, theme + layout "signature" interaction, variant as a re-roll, archetype as an art-director override, and the niche-to-structure mapping. Several parameters (headline, price, terms, faq, features, currency, discountPercent) still carry no explanation anywhere, so it does not fully close 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?

Opens with a specific verb and artifact: generate a ready-to-deploy sales page as a single HTML file built around what the user sells. An agent immediately knows what it produces. It never differentiates itself from the sibling publish_page, which handles deployment-like duties, so the boundary between creating and publishing is left ambiguous.

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?

Usage conditions are implied through branching rules (works from minimal brand+product input, pass media if you have it, autoImages fetches stock when not), but these are behavioral branches rather than when-to-use-this-vs-an-alternative guidance. Nothing tells the agent when to reach for content_kit, platform_specs or publish_page instead.

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