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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description goes further, disclosing the immediate side effect (rankings, reviews, competitors begin tracking at once), the billing/plan implication, and an out-of-band dependency (App Store Connect must be connected in the console, not here). That is exactly the behavioral context annotations cannot carry.

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 sentences, front-loaded with the core action, then input forms, then side effects and the ASC limitation. No sentence is filler; each adds a distinct fact an agent needs.

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?

Safety profile comes from annotations and return shape from the output schema, so the description's job is side effects and prerequisites — both covered. Nothing an agent needs to call this mutating, importing tool correctly is missing.

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 already 100%, so the schema sets the floor at 3. The description adds cross-tool semantics by stating all three accepted forms are resolved and imported the same way search_apps resolves them, which tells the agent the input is a resolution target rather than a raw key.

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 and resource ('Add an app to the account as one of the user's own') and pinpoints the accepted input forms (app_id, App Store URL, or name). It also distinguishes itself from the sibling search_apps by noting resolution happens 'the way search_apps does', so an agent can tell importing apart from merely searching.

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 clear context: tracking starts immediately, and measured downloads/proceeds require connecting App Store Connect in the console, which 'cannot be done from here' — a real prerequisite. It stops short of an explicit when-not-to-use rule or naming an alternative tool for the pre-check (dry_run covers that only inside the schema).

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