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

With annotations already declaring non-read-only/non-destructive, the description still adds real context: output is a link per image, cost is free, and `proof: "rating"` is conditionally refused under 4.5 stars or 20 ratings — a failure mode invisible in the schema. It doesn't state what artifact is actually created or whether anything is persisted server-side, which is the notable remaining gap given readOnlyHint=false.

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?

Purpose is front-loaded in the first clause, and the dense sentence structure packs size, script coverage, proof, output, and routing into five sentences. The SEO aside ('since 2025 caption text appears to count...') partly duplicates the caption field's own description, which is the only slack.

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 no-output-schema tool it correctly declares the return ('a link per image'), the permitted image sources are in the schema, and the downstream apply/upload path is named. Only the asset-persistence behavior and the appId/size interaction are left unstated, which is minor but not nothing for a non-read-only tool.

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 only 33%, so the description has to compensate. It does well on three of them: `caption` (benefit wording, search relevance), `sub` (the 'optional second line'), and `proof` (rating line plus its refusal threshold). But `appId`, `bg`/`fg`, and the maxItems=10 constraint on `screenshots` get no explanation anywhere, leaving real gaps.

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 specific verb+resource: composites a caption (plus optional second line) over each raw screen and renders at the exact App Store Connect size, in any script. It also carves out its position against siblings by naming app_experiment_create/app_cpp_create as uploaders and app_screenshots_apply as the applier, so an agent can distinguish 'render images' from 'ship images' without opening another 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?

It routes clearly to alternatives: use app_experiment_create or app_cpp_create to upload, app_screenshots_apply to put a set into the next version. It also gives authoring guidance ('write captions as benefits in the words people search'). What's missing is an explicit negative case (e.g. when not to add captions, or what to do if the source screen isn't a raw portrait asset).

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