generate_design_image

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

Given no annotations, description provides minimal behavioral context. It does not disclose rate limits, cost, output format details (e.g., URL vs base64), or error handling. The lack of annotations places full burden on description, which is insufficient.

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?

The description is two sentences, front-loaded with the primary action and resource, followed by a list of supported modes. Every word contributes meaning; no fluff or redundancy.

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?

The tool lacks an output schema and the description does not explain what is returned (e.g., image URL, binary data, base64). With 7 parameters and no output details, the agent needs more context to fully understand the tool's behavior and integrate it 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?

Schema coverage is 100%, so baseline is 3. Description adds no parameter-specific information beyond the schema, which already includes clear descriptions for each parameter. No further semantic clarification is provided.

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 clearly states it generates SVG or PNG mockup images of UI screens and components, identifying specific modes (wireframe, mockup, component_preview). This effectively distinguishes it from sibling tools like generate_ui_component which likely produce code rather than images.

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?

No explicit guidance on when to use this tool versus alternatives such as generate_ui_component or image_to_component. The description does not mention scenarios where image generation is preferred over code generation, nor does it indicate prerequisites or limitations.

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