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

Annotations already flag destructive=true and non-idempotent, and the description corroborates this by saying existing translations are refreshed/overwritten when their source changed. It also adds external-scope context (no Apple/Google publishing) and a quota-like constraint ('subject to translation allowances') that annotations do not convey. What is missing is what happens when allowances are exceeded and whether unchanged strings are preserved.

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?

Three short sentences, front-loaded with the core action, then the scope exclusion, then the constraint. No filler and nothing redundant with the schema or annotations.

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?

An output schema exists and annotations cover the safety profile, so the description is not required to explain returns. However, for a destructive, non-idempotent mutation with fully undocumented parameters, the description leaves important gaps: the role of variantId, language-code format, and the behavior/error when translation allowances are exhausted.

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 description coverage is 0% for all three parameters, so the description carries the burden and largely fails: 'requested languages' loosely maps to targetLanguages but never states the expected language-code format or the 1–60 item bounds, and projectId/variantId are never explained (notably what omitting variantId means).

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 (translates/refreshes) on a specific resource (saved store listing text), including the two modes of operation: new translation and refreshing translations whose source changed. This clearly separates it from siblings like translate_graphics, translate_layouts, translate_promo_video, and update_store_listing.

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?

Gives a clear usage boundary ('Does not publish to Apple or Google') and explains when a re-run is warranted (source changed). It does not explicitly name an alternative tool for publishing or for translating other artifact types, so the agent must infer those routes from sibling names.

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