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

Goes beyond destructiveHint=true by specifying the exact blast radius: it replaces that size's screenshots in that version only, and nothing live changes until the founder submits and Apple releases it. It also surfaces a refusal rule via the proof field (under 4.5 stars / 20 ratings). Minor gap: it does not say whether the prior screenshot set is recoverable or lost on overwrite.

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 the action and its scope; the destructive consequence and the test-first rule follow in priority order. The middle clauses are slightly run-on, but every sentence carries decision-relevant 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?

For a destructive, open-world write with no output schema, the description covers what is mutated, what is deferred to the founder/Apple, and when an untested apply is legitimate. It leaves open what the tool returns (e.g., the applied set or a staged-version id) and how to undo an apply, which keeps it short of a 5.

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 80%, so the baseline is 3, and the description earns an upgrade by explaining that screenshots are ordered ('in this order') and scoped to a single locale+size per call — semantics the array/param schema does not convey. It still says nothing about why/appId beyond what the enum and field names give.

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?

Names a concrete verb and resource ('put a set of captioned screenshots ... into the version the founder will submit') and bounds it to one language and one size in one call. It is clearly separable from app_screenshots (read) and app_experiment_create (test), which are the two obvious siblings an agent would confound it with.

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 routing: 'A change to the screenshots everyone sees is tested first (app_experiment_create): apply a set without a test only for a language that has none of its own.' That names the alternative and the exact condition under which this tool may be used untested, plus the audience (Builder and Growth).

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