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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, covering the safety profile. The description adds that output includes ratings, review content, reviewer profiles and dates, but omits behavioral facts like task retention window, pagination, or auth requirements, so it adds only modest context beyond the structured data.

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 substantive content is a single front-loaded sentence that leads with the endpoint's output. The appended pricing comment block is boilerplate noise, but the core description is compact and earns its place.

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?

With an output schema present, the description needn't explain return values, and annotations cover the safety profile. For a one-parameter fetch-by-id tool the coverage is nearly complete; the one gap is the absence of an explicit link to the corresponding submit tool, which the sibling naming makes important.

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% and the single 'id' parameter is fully documented in the schema (UUID task identifier, usable for 30 days). The description adds the useful nuance that results are scoped by app_id, location and language from the originating POST, though those are not parameters of this tool, which risks minor confusion.

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 states a specific verb and resource: it returns App Store review feedback data (ratings, content, reviewer profile, dates). It also reveals the retrieval pattern by noting results are scoped to parameters 'specified in the POST request', which implicitly ties it to its submit sibling. However, it never names the App-Store-vs-Google or fetch-vs-submit distinction explicitly, so an agent must infer the routing.

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?

There is no explicit when-to-use or when-not statement, and no sibling is named. The only guidance is the indirect mention that results reflect the POST request parameters, which implies the two-step submit-then-fetch workflow but leaves the agent to infer that this tool is the retrieval half of post_dataforseo_app_apple_app_reviews_submit.

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