Design Rich Menu Image (Rich Menu Studio)

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

The description discloses key behavioral traits beyond the annotations: 'auto-deletes the orphaned menu on any post-create failure', 'LINE caps the PNG at <1MB (gradients auto-flatten to solid once)', and 'brand auto-corrects label contrast for readability'. These are important for an agent to understand side effects and constraints. No contradiction with 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?

The description is well-structured with a clear overview, workflow steps, template table, important notes, and an example. It is concise without being terse, and every sentence adds value. There is no repetition of schema information that is already clear from the input 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?

Given the tool's complexity (9 parameters, nested objects, multiple modes, no output schema), the description is remarkably complete. It covers all modes, templates, parameter relationships, deployment behavior, and return values. The example at the end ties everything together, leaving no significant gaps.

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?

While schema coverage is 100%, the description adds significant meaning: template enumeration with visual descriptions (e.g., '3×2 grid, 6 equal cells — the classic LINE OA menu'), explanation that cells[] length must equal template's cell count, and that per-cell action is required only for deploy. The example further clarifies usage. This goes well beyond the schema.

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 tool's purpose is clearly stated: 'Design a professional LINE rich menu PNG from labels alone'. It distinguishes itself from sibling tools by explaining it is a pure-JS renderer requiring no design tool or headless browser, and mentions optional deployment. The description makes it easy to understand what the tool does and how it differs from related tools like line_build_rich_menu or line_upload_rich_menu_image.

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?

Explicit workflow guidance is given: 'ALWAYS preview first: mode="preview" (default) returns the PNG as an image block — LOOK at it, iterate with the user, then call again mode="deploy"'. It also explains when to use save mode and deploy mode, and provides template descriptions. This helps the agent decide when and how to invoke the tool.

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