Prepare an image for LINE (resize + host + verify)

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

Annotations are minimal (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description goes far beyond by disclosing the provider chain, auto-teardown on failure, handoff package fallback, keep-alive behavior tied to LINE's fetch-on-first-view timing, and the guarantee that 'NEVER claims false success'. This is rich, non-redundant behavioral context.

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 long but every section serves a purpose: a one-sentence overview, provider chain rationale, critical timing caveat, return contract, and a step-by-step example. It is well-structured with clear paragraph breaks and front-loaded with the most important information.

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?

Despite lacking an output schema, the description fully explains the return shape (prepared_key, provider, base_url?, etc.) and failure behavior. It covers operational nuances like process lifetime, NAT traversal, and handoff instructions, making the tool actionable in real-world scenarios.

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%, but the description adds substantial value beyond the schema: warns base64 can silently corrupt and produce blank images, recommends file_path, explains Google Drive/Dropbox link rewriting for source_url, and contextualizes keep_alive_hours against the LINE fetch timing. This genuinely helps the agent choose the right input.

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 opens with a specific verb + resource: 'Make any image sendable to LINE with ZERO hosting knowledge' and details the exact pipeline (resize, host, verify, return prepared_key). It clearly distinguishes this tool from sibling tools like line_design_imagemap and line_send_message, which consume the prepared_key.

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?

Provides explicit usage context: the tool exists because LINE lacks an upload API, and gives a concrete workflow example (ส่งรูปนี้เป็น Rich Message → prepare → design → send). It names the downstream tools that accept prepared_key, effectively guiding when to use this vs alternatives.

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