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

readOnlyHint=true already establishes this as a safe read. The description usefully adds the scope of the return payload (versions, build status, release state), but says nothing about permissions, App Store Connect auth requirements, or rate limits.

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?

One front-loaded sentence that states the resource first and the returned fields second, with no filler. Slightly lean for the amount of behavior it could have covered, but nothing is wasted.

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 low-complexity, read-only lookup with full schema coverage and no output schema, listing the returned fields is the right level of detail. Missing only edge-case behavior (e.g. what happens for an unknown or inaccessible app_id).

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?

Single parameter with 100% schema description coverage, including a format pattern and a pointer to list_apps, so the schema carries the semantics. The description adds no additional meaning about app_id, which is the expected baseline at full coverage.

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?

Specific verb ('Get') plus resource ('app') and an enumeration of what the detail payload covers (versions, build status, release state). It is clear what the tool returns, though it never contrasts itself with siblings like list_apps or release_version.

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?

The description gives no when-to-use or when-not-to-use guidance and does not name an alternative tool. The only steering ('use list_apps to find it') lives in the app_id schema description, not in the tool description itself.

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

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

Annotations only declare readOnlyHint=true; the description goes further by disclosing what the content contains (which steps are manual and cannot be done via API) and that it is free to call. That is real added context beyond the safety hint, though it says nothing about size or format of the returned playbook.

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 'START HERE' so the routing cue comes first. The one-word 'Free.' sentence is a fragment but carries cost information efficiently; nothing is padded.

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 no output schema, the description must convey what comes back, and it does: an end-to-end playbook with manual steps flagged by topic. It is largely complete for a simple, zero-required-parameter orientation tool, missing only detail about length or structure of the returned content.

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 enum plus 'Omit for the overview + topic list' fully document the single optional parameter. The description's 'Call with topic to orient' adds little beyond the schema, so baseline 3 applies.

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 ('Returns the exact end-to-end playbook for an App Store task') and pins down the scope/content ('every manual ASC-website/Xcode step that no API can do flagged inline'). This clearly distinguishes it from the sibling operational tools like create_version or submit_for_review, which perform steps rather than describe them.

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?

'START HERE' and 'Call with topic to orient before any multi-step flow' give explicit when-to-use guidance, positioning it as a prerequisite/orientation tool. It does not name exclusions or alternatives, but the routing intent is unambiguous.

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

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

readOnlyHint=true already signals a safe non-mutating call. The description adds real behavioral context beyond that: it performs a LIVE authenticated connection test, inspects specific credential artifacts, reports the license tier, and returns 'the exact fix' on failure. It does not describe latency or how the live check behaves on failure, keeping it short of a 5.

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 compact sentences, front-loaded with the core action, followed by the failure behavior and the invocation trigger. No waste.

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?

Despite having no output schema, the description characterizes the return adequately ('returns the exact fix'). For a parameterless diagnostic with a readOnlyHint annotation, an agent has everything needed to call it correctly.

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?

The tool takes zero parameters, so schema-based parameter semantics are moot and a baseline of 4 applies. There is nothing for the description to disambiguate.

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?

Specific verb ('Diagnose') plus resource ('your setup'), and it enumerates exactly what is checked: .p8 key, Key ID, Issuer ID, live authenticated connection, and license tier. This is clearly distinguishable from all siblings, which are action/mutation tools rather than diagnostics.

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 when-to-use guidance: 'Run this first if something isn't working.' Clear context for invocation. It doesn't name an alternative to use instead, but for a setup diagnostic there is no meaningful sibling alternative, so this is close to complete.

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

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

Adds real behavioral context beyond the readOnlyHint=false/destructiveHint=true annotations: the trial activates in the current session and the blocked tool can be retried without restart, and it insists the email be requested (never invented). However, the concrete destructive effects (rewriting MCP client configs, writing ~/.asc-mcp/license.json, .bak copies) are only disclosed in the schema's email field, not the description itself.

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 opening clause and the two usage triggers follow logically. It is dense and runs long, with the email instruction duplicated from the schema, but nearly every sentence carries actionable guidance and nothing is buried.

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 2-parameter trial-starter with no output schema, the description covers activation timing, session persistence, retry behavior, and the consent requirement. An agent has everything needed to invoke it correctly.

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 100%, so both the email and tool parameters are already fully documented there. The description only reinforces 'ask for their email first and never invent one,' which largely repeats the schema rather than adding new semantic meaning — a baseline 3.

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 (start) and resource (free 7-day Pro trial) and immediately quantifies the benefit: 'unlocking all 41 tools including the full write/control plane.' No sibling tool does this, so an agent can distinguish it without opening any 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?

Explicitly names both trigger conditions ('when a Pro tool is refused and the user wants to proceed' and 'when they ask for something only a Pro tool can do... before you hit the refusal') and enumerates the Pro capabilities. This is exactly the when-to-use routing an agent needs.

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

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

Annotations only mark this as non-read-only and destructive; the description goes well beyond that by disclosing that Apple notifies every tester immediately, that the notification cannot be recalled, and that confirm:true is mandatory. It also notes the newest-processed-build default and that the tool is a Pro feature, all of which materially affect whether and how an agent should invoke it.

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?

Two sentences with no filler, front-loaded with the action and immediately followed by the highest-risk consequence. Every clause earns its place; nothing is repeated from the title 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?

For a 4-parameter mutation tool with no output schema and full schema coverage, the description covers the critical unknowns: irreversibility, the confirm gate, default build selection, and Pro gating. It stops short of explaining what happens to a previously assigned build or error behavior, which would round it out.

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 each parameter is already documented, including confirm's requirement and build_id's fallback behavior. The description largely restates that (defaults to newest processed build, needs confirm:true) without adding syntax, format, or edge-case detail beyond the schema, so the baseline of 3 applies.

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 (assign a build to a TestFlight beta group) plus the outcome (testers can install it), which is more than a restatement of the name. It does not explicitly differentiate itself from near-siblings in the list such as attach_build or invite_beta_tester, leaving some ambiguity about which tool handles which build-to-group flow.

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?

The description gives a conditional requirement (confirm:true) and states the default build selection, which is real usage guidance. However, it never says when to prefer this over attach_build or how it relates to the surrounding release flow, so the when-to-use-vs-alternative signal is only implied.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this mutates state. The description usefully adds that the target must be the *editable* version and that the tool is Pro-gated, but it does not explain what the destructive aspect means in practice (e.g., whether an already-attached build is replaced) or what permissions are required.

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?

Two short sentences, purpose front-loaded ahead of the default behavior, with no wasted prose. 'Pro feature' is terse but carries real information; the only cost is that brevity leaves the destructive semantics unexplained.

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 2-parameter mutation tool with no output schema and full schema coverage, the description covers enough to invoke it, but omits what happens to a previously attached build and any prerequisite that the version be in an editable state. Adequate, not thorough.

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%, so the baseline is 3, but the description's default rule ('newest processed build') conflicts with the schema's own wording ('Omit for newest VALID build'), introducing ambiguity about which build is selected. That inconsistency actively degrades parameter understanding rather than adding to it.

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?

Clear verb+resource: attach a build to the editable version, with the target (editable version) and the default source (newest build) stated. It is distinguishable from assign_build_to_group and upload_binary, though it never names or contrasts those siblings explicitly.

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?

States the default behavior when build_id is omitted ('defaults to the newest processed build') and notes 'Pro feature' gating, which implies an availability constraint. However, there is no when-to-use vs. when-not-to-use guidance relative to siblings like assign_build_to_group or submit_for_review.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so safety is covered. The description adds useful behavioral context the annotations don't: the local Xcode environment requirement, required inputs, Pro-feature gating, and that the output is a signed .ipa. It stops short of describing what happens to a pre-existing build directory, which the destructive hint hints at.

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 tight sentences, front-loaded with the action and artifact, then environment and prerequisites. No filler.

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 mutation/build tool with annotations covering safety and no output schema, the description covers prerequisites, environment, gating, and the produced artifact. Remaining gaps (build duration, overwrite behavior on output_dir) are minor for an agent to invoke it correctly.

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 100%, so all six parameters are self-documented; baseline is 3. The description only reiterates that a scheme and ExportOptions.plist are required and doesn't add format, default, or constraint detail beyond the schema.

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 specific verbs (build, archive, export) plus the concrete artifact (.ipa) and the underlying tool (xcodebuild). No sibling overlaps with this exact operation, so an agent can distinguish it, though it doesn't explicitly name an alternative to avoid.

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 prerequisites (needs a scheme and ExportOptions.plist, requires Xcode on this Mac) which implies when the tool is usable, but never states when to choose it over neighbors like upload_binary, wait_for_build, or list_builds, nor any exclusions.

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

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

With readOnlyHint=true already in annotations, the safety profile is covered by structured data. The description adds two pieces of context the annotations do not: the exact data returned (since there is no output schema) and the 'Pro feature' entitlement gate. It omits country defaulting and any rate-limit behavior.

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, front-loaded sentences with no waste. The core lookup action leads, the accepted identifier forms follow, and the terse 'Pro feature.' earns its fragment status as an entitlement gate.

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 two-parameter read-only lookup with no output schema, the description covers what the tool does, what fields come back, and how to address the app. The only real gap is that it neither explains the country parameter's effect nor distinguishes the tool from overlapping siblings.

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%, so both parameters (query, country) are already fully documented in the schema, including the 'us' default. The description's 'Search by name or App Store ID' merely restates the query parameter's semantics and adds nothing on country. Baseline 3 applies.

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 ('Look up any app on the App Store') and enumerates the return payload (ratings, reviews, version, price, category, release notes). It does not, however, differentiate itself from close siblings like app_details or list_apps, leaving an agent to guess which lookup tool to pick.

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 tells the agent how to address the app ('Search by name or App Store ID') and flags a gating condition ('Pro feature'), which is useful. But there is no when-to-use/when-not guidance and no pointer to app_details or list_apps, so disambiguation is left implicit.

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

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

With annotations only declaring readOnlyHint=false and destructiveHint=true, the description adds real behavioral value: 'idempotently' tells the agent retries are safe and a duplicate product_id will not double-create, and 'Pro feature' signals an entitlement precondition. It stops short of explaining what a failed/partial create leaves behind or how the created IAP is identified in the response.

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?

Two brief sentences, zero filler, and the most decision-relevant facts (idempotent create, one-time, USA price) are front-loaded. Nothing is repeated that structured fields already state verbatim.

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 10-parameter mutation tool with no output schema, the description covers the essentials: idempotency, product scope, and entitlement gating, with all field detail delegated to a fully covered schema. It could go slightly further on post-creation expectations (e.g. that a review screenshot still has to be set via set_iap_review_screenshot before submission), which is the one workflow gap.

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 100% and every field is individually documented (type enum, price_usd, product_id, length caps), so the schema carries the parameter burden. The description's mentions of purchase type and USA price restate the schema rather than adding format constraints or defaults, so the baseline 3 applies.

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 ('Create ... a one-time in-app purchase'), narrows the variants (non-consumable or consumable), and pins the pricing rule ('with USA price'). This plainly distinguishes it from the sibling create_subscription, which covers recurring purchases.

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?

Usage is implied rather than stated: 'one-time' implies this is the non-recurring counterpart to create_subscription, and 'Pro feature' hints at a gating/precondition. There is no explicit when-to-use/when-not or named alternative, so the agent must infer the boundary.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds genuinely non-redundant behavior: idempotency, automatic territory-availability side effect, and the Pro-tier requirement. It stops short of describing the response, keeping it at a 4.

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 tight sentences with zero waste; the core action and its key modifiers are front-loaded before the side-effect and tier notes.

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 14-parameter creation tool with no output schema, the description covers the essential behavioral facts (idempotent, auto territory setup, Pro requirement) alongside annotations that carry the safety profile. Only the absence of any return/confirmation detail keeps it from 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 description coverage is 100%, so all 14 parameters are documented in the schema itself. The description mentions the group, USD price, free trial, and territory behavior, but adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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 gives a precise verb (Create), resource (auto-renewable subscription), and scope (inside a group, USA price, optional free trial), so an agent immediately knows what the tool does. It does not explicitly differentiate from the nearby create_iap sibling, which is the only gap keeping it from a 5.

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 guidance on when to use this tool versus alternatives such as create_iap, nor any when-not/exclusion. The only contextual hint is 'Pro feature,' which signals a tier prerequisite but is not usage direction.

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

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

Annotations already flag readOnlyHint=false and destructiveHint=true, so the mutation risk is known. The description earns credit for explaining WHY it is irreversible (Apple only allows deleting an app's first version) and disclosing the Pro-plan gating, which annotations do not cover.

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 what the tool does, then the confirm gate, then plan gating. Every clause carries information 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?

For a destructive creation tool with no output schema, the description covers purpose, irreversibility, required confirmation, and plan gating. It could go slightly further on what the call returns or what state the app must be in, but nothing essential 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 description coverage is 100%, so all five parameters including confirm, platform, and version_string are already documented. The description only restates the confirm requirement, adding little semantics beyond the schema's own confirm description.

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 (create a new App Store version) plus the lifecycle scope ('editable ... to prepare your next release'), which separates it from release_version, submit_for_review, and update_version_metadata without opening their schemas.

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 context (preparing the next release) and a hard prerequisite (confirm:true required). It does not name alternatives such as update_version_metadata for editing an existing version or release_version for shipping, so it stops short of explicit routing.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely new context beyond structured fields: the aggregation spans 'all apps' rather than one app, and 'Pro feature' discloses an entitlement requirement that the schema and annotations do not express. It stops short of describing latency, rate limits, or result shape.

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 compact fragments with no filler, and the most important information (what the briefing contains) is front-loaded before the positioning and gating notes. Every clause 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 no output schema, the description compensates by listing the categories returned (version status, reviews, rejections, action items), which is enough for an agent to judge relevance. It could say more about scope limits (e.g. limits on app count) or ordering, but nothing blocks correct invocation.

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?

There is one optional parameter (days) with 100% schema description coverage, including its default of 3. The description adds nothing about the lookback window, so the schema carries the full burden — the baseline 3 for high coverage applies.

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 names a specific artifact (a morning briefing) and enumerates its contents — version status, recent reviews, rejections, action items — while scoping it to 'all apps'. 'One call for full situational awareness' makes the aggregation role clear against single-purpose siblings like list_reviews, review_status, or release_version.

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?

'One call for full situational awareness' gives a clear condition for selecting this tool over the narrow sibling calls, and 'Morning briefing' frames the daily cadence. It does not explicitly state when not to use it or name the specific alternatives, but the aggregation framing is unambiguous.

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

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

Beyond the lone readOnlyHint, it discloses significant behavior: it uses MCP Sampling and Elicitation (client-dependent) to obtain tone, NEVER auto-posts, and always returns a draft the caller must post manually. These are exactly the operational traits an agent needs and that no annotation conveys.

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 core action in the first clause, then layered with constraints in five tight, waste-free sentences. Every sentence adds a distinct operational fact (locale, elicitation, never-post, manual posting, Pro gating).

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?

There is no output schema, but the description compensates by explaining that a draft is returned and must be posted by the caller, closing the return-value gap. Nothing needed to invoke it 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 100%, so all five parameters are already documented. The description's mention of Elicitation for tone largely restates what the tone schema description already says, adding little per-parameter meaning beyond the baseline.

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?

Specific verb (draft) plus resource (a public reply to a single App Store review), with the mechanism ('via MCP Sampling, in the review's locale') made explicit. It is clearly distinguishable from siblings like list_reviews and triage_reviews, which the description implicitly complements.

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?

The description clarifies the intended context (a single review, Pro feature) and the post-draft workflow ('you must post via App Store Connect yourself'), which routes the agent after drafting. It does not, however, name an explicit alternative or state when NOT to use it versus triage_reviews.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds the crucial why: Apple sends a real email from the user's account and the action cannot be recalled. This irreversible side effect plus the confirm:true safety gate is exactly the behavioral context an agent needs beyond the flags.

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 tight sentences, front-loaded with the action, then the safety requirement and consequence, then the Pro gating. No filler and every clause carries 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?

No output schema exists, and the description covers the irreversibility, the mandatory confirm flag, and the Pro requirement for a 5-param mutation. Nothing needed to call it safely and 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 100%, so all five parameters are already documented, and the description largely reinforces that (confirm required, email consequence). It adds the rationale for confirm but no new syntax or value semantics beyond the schema, so the baseline 3 applies.

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 (Invite) and resource (external tester by email) plus the second effect of adding them to a beta group. It also implicitly distinguishes this from build/version siblings by naming the beta-group target that the schema links to list_beta_groups, so an agent can tell it apart from assign_build_to_group.

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 for use (inviting an external tester) and a precondition (confirm:true) plus a gating note (Pro feature). It does not name an alternative tool or state when-not-to-use, but the surrounding conditions are explicit enough to route correctly.

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

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

Beyond readOnlyHint=true, the description discloses that it calls the iTunes Search API and is a 'Pro feature' (auth/entitlement requirement), and the mention of 'budget usage' hints at an external quota/rate-limit dimension. These add material behavioral context the annotations do not carry, though reversibility/pagination behavior is unstated.

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?

Four short, front-loaded sentences with no padding; the core action and its outputs come first. Efficient, though 'Uses iTunes Search API' and 'Pro feature' are terse fragments rather than fully integrated statements.

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 no output schema, the description usefully names what is returned (difficulty, competing apps, budget usage) and flags the Pro entitlement. For a two-parameter read-only analysis tool this is largely complete, with only quota/rate-limit specifics left implicit.

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 100%, so app_id and extra_keywords are already documented in the schema. The description adds no format or constraint detail beyond that, so the baseline 3 applies.

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 ('Analyze your app's keywords against search competition') and enumerates the outputs: difficulty, competing apps, budget usage. It clearly distinguishes keyword analysis from the other list/search siblings, though it doesn't explicitly position itself against a nearby tool like competitor_snapshot.

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?

Usage is implied ('Analyze your app's keywords') and the 'Pro feature' note signals an availability prerequisite, but there is no explicit when-to-use, when-not-to-use, or alternative tool named. The agent is left to infer that this is for keyword research rather than release or metadata workflows.

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

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

readOnlyHint=true in annotations already declares this is a safe read. The description adds context by listing the returned fields and confirming account scope, but says nothing about pagination behavior or what the limit parameter governs beyond what the schema states.

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?

A single front-loaded sentence with zero filler; the verb, scope, and return fields are all packed efficiently without redundancy.

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?

There is no output schema, so the description usefully enumerates the returned fields (name, bundle ID, SKU, App ID). For a one-parameter read tool with readOnlyHint coverage, this is nearly complete; only pagination/max-result semantics are left implicit.

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% - the single 'limit' parameter (default 50, max 200) is fully documented in the schema. The description adds no parameter detail, so the baseline 3 for high coverage applies.

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 (List) and resource (apps) with scope ('in your App Store Connect account') and the fields returned (name, bundle ID, SKU, App ID). Sibling tools are mostly write/action operations with no competing 'list apps' variant, so no explicit differentiation is needed, but none is offered.

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?

No when-to-use or when-not guidance is given. The description only restates what the tool does, leaving the agent to infer that this is the entry point for discovering apps before calling siblings like app_details or list_builds.

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

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

Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds the 'Pro feature' gating caveat, which is genuinely useful context, but omits pagination, result limits, or ordering behavior. With annotations carrying the safety profile, this is an adequate but thin contribution.

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?

Two short sentences, front-loaded with the action and resource. Every word earns its place with no filler.

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 simple one-parameter read tool with readOnlyHint and full schema coverage, the description is nearly sufficient. It lacks any note on what a group contains or whether results are paginated, but the essentials for correct invocation are present.

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 100% and the single app_id parameter is fully documented with type, pattern, and meaning. The description adds nothing parameter-specific, so the baseline of 3 applies.

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: 'List TestFlight beta groups for an app.' An agent can distinguish this from siblings like assign_build_to_group or list_builds. However, it does not explicitly differentiate scope against any named sibling.

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?

No when-to-use guidance, no prerequisites, and no alternatives named. The only hint is 'Pro feature,' which signals availability gating but not when an agent should select this tool over the related beta-group and build tools.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds two pieces of genuinely useful context beyond that: results carry a processing state with 'VALID = ready to use', and the tool is a 'Pro feature', alerting the agent to a possible access/entitlement restriction.

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?

A single compact sentence with the operation front-loaded and no wasted words; the parenthetical state hint and 'Pro feature' note each earn their 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?

For a simple read-only list tool with no output schema, the description covers purpose, the meaning of the key returned state, and the Pro gating. It omits return ordering and pagination behavior relative to the 'limit' cap, keeping it just short of fully complete.

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 both parameters (app_id, limit) are documented in the schema itself. The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 is correct.

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 clear verb+resource ('List recent builds for an app') and adds a scoping qualifier ('recent') plus what the results contain ('processing state'). An agent can tell it apart from mutation siblings like wait_for_build or attach_build, but no sibling is named explicitly, so it lands at 4 rather than 5.

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?

The phrase 'for an app' implies the listing use case, but there is no explicit when-to-use vs when-not-to-use guidance and no routing to alternatives such as wait_for_build for polling a single build. Usage is only implied.

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

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

readOnlyHint=true already covers the read-only safety profile, so the bar is lower. The description adds the useful "Pro feature" gating constraint, but says nothing about pagination or return shape for what is clearly a paged list endpoint.

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 front-loaded sentences with no waste; the primary purpose leads. The final "Pro feature" telegraph is terse but earns its place as a prerequisite signal.

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 simple read-only list tool with no output schema and full schema coverage, this is minimally adequate. It omits expected behavior on default result caps beyond limit and offers no hint of the response contents.

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 100%, so all four parameters are fully documented in the schema (sort, limit, app_id, rating with enum/min/max). The description's "Filter by rating" only restates the rating param, adding nothing the schema lacks, so baseline 3 applies.

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 ("List customer reviews for an app") plus a filtering capability. However, it does not differentiate from siblings like triage_reviews or review_status, leaving the agent to infer which review-related tool applies.

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?

"Pro feature" notes a prerequisite (needs a Pro subscription), which is useful. But there is no guidance on when to use this versus triage_reviews or draft_review_response, and no exclusions are stated.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds value beyond that: the 7-day window, that 'complete' means release to 100%, and that this is a Pro-gated feature. It stops short of stating auth requirements or what happens to a paused release.

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?

Two compact fragments with zero filler; the core action and the 7-day scope are front-loaded before the qualifying 'Pro feature' note. Nothing could be trimmed without losing 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 3-parameter mutation tool with no output schema, full schema coverage and a destructive annotation, the description supplies the essential framing: duration, action set, and gating. It omits failure modes and state-transition rules, which keeps it slightly short of complete.

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 100%, so all three parameters are already documented, including the irreversible nature of 'complete' via the confirm field. The description only lightly clarifies 'complete (release to 100%)', which is already implied by the enum. Baseline 3 is appropriate.

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 names a specific verb (control) and resource (the 7-day phased rollout) and enumerates the four supported actions, which map exactly to the action enum. It is clearly distinct in scope from siblings like release_version or submit_for_review, though it never explicitly contrasts itself with them.

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?

Usage is implied by the action list and the 'Pro feature' caveat, so an agent can infer this manages an in-flight rollout. However, there is no explicit when-to-use guidance, no statement of prerequisites or ordering (e.g. must start before pausing), and no named alternative.

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

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

The readOnlyHint annotation already establishes this is a safe read, so the bar is lower. The description does add real context beyond the annotations: the fields compared (descriptions, keywords, release notes), the cross-locale scope, and the 'Pro feature' entitlement note. It does not describe diff granularity, ordering, or size limits, so it stays mid-range.

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, and every sentence contributes: the comparison, the field scope, and the entitlement. No repetition of the title or schema.

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 single-parameter read tool this is nearly complete, and with no output schema the description sensibly sketches the return content ('what changed in descriptions, keywords, and release notes across locales'). It still omits how results are structured or whether unchanged locales appear, a minor gap for a diff 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?

Only one parameter exists and schema description coverage is 100%, so the schema already fully documents app_id. The description adds no format or constraint details beyond what the schema carries, making the baseline 3 the correct score.

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 gives a specific verb+resource ('Compare metadata between your live and pending app versions') and enumerates the compared fields, making the tool clearly distinct from mutators like update_version_metadata or set_app_metadata. It stops short of naming any sibling tool outright, so it lands at 4 rather than 5.

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, when-not-to-use, or alternative-tool guidance. The only usage-adjacent signal is 'Pro feature,' which hints at an entitlement requirement but does not tell the agent when this diff is the right call versus release_preflight or app_details.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: it returns structured/categorized data, supplies writing guidelines, and is gated as a 'Pro feature' (an entitlement prerequisite). It doesn't describe output shape or pagination, but it goes well past the annotations.

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?

Two tight sentences with the core action front-loaded and the downstream purpose immediately after; no filler. A touch terse on behavioral detail, but every clause 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?

For a no-output-schema, read-only tool with three fully documented optional parameters, the description conveys enough: what it reads, what it returns (structured/categorized data plus guidelines), and the Pro gating. Only the exact return structure is left unspecified, which is acceptable absent an output schema.

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%, so since_tag, max_commits and project_path are fully documented in the schema itself. The description only echoes the date-range concept ('since last tag') without adding syntax or format details beyond what the schema already provides, making the baseline 3 appropriate.

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 gives a specific verb and resource ('Extract git commits since last tag') and states the downstream goal (App Store 'What's New' text), so its function is unambiguous. It does not explicitly differentiate itself from nearby siblings such as release_version or release_preflight, which is the only reason it isn't a 5.

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?

Usage is implied by 'since last tag' and 'for writing App Store What's New text', so the agent can infer the scenario. However there is no explicit when-to-use guidance, no exclusions, and no mention of when a different sibling (e.g. release_version) is the better choice.

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

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

Annotations already declare readOnlyHint=true, and the description is consistent (it only says 'checks'), so no contradiction. It adds real context beyond annotations: the exact categories audited and an access constraint ('Pro feature'), which an agent needs to know before invoking.

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 tight clauses with no filler: what it does, why it matters, and the access caveat. The purpose is front-loaded in the first four words.

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 read-only, single-parameter audit tool with no output schema, the description covers what is checked and the Pro gating, which is enough to call it correctly. It could clarify the scope tie to a specific version, since the title mentions 'a version' but the only input is an app ID.

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?

Only one parameter (app_id) and schema coverage is 100%, so the schema fully documents it with format and pattern. The description adds nothing about the identifier, which is the expected baseline when the schema does the heavy lifting.

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 specific action (pre-submission audit) and enumerates what it inspects: metadata, character limits, screenshots, build status. It is clearly distinct from submit_for_review and review_status, though it does not name those siblings explicitly.

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?

States the clear context of use: run it before submitting to catch rejection causes. No exclusions or explicit alternative routing are given, but an agent can infer the pre-submission window without ambiguity.

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

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

Annotations already declare this as a non-read-only, destructive operation. The description adds real context beyond that: the operation is outward-facing (goes to the live public store), it is gated behind confirm:true, it is a Pro-tier feature, and it demands a specific prior state. It does not address reversibility or what happens if the version is not yet approved, so it is not exhaustive.

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, front-loaded clauses with zero filler: what it does, the required state, the outward-facing confirm gate, and the tier. Every fragment 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?

For a two-parameter tool with strong annotations and full schema coverage, the description covers the precondition, the safety gate, and the tier requirement. With no output schema it could say a little more about what the agent should expect back, but nothing needed for correct invocation 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 description coverage is 100%, so both app_id and confirm are already documented in the schema. The description only restates the confirm:true requirement, adding emphasis but no new syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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?

It states a specific verb (release), the resource (a version), the required source state (PENDING_DEVELOPER_RELEASE) and the destination (public App Store). This is clearly distinguishable from siblings like submit_for_review, release_preflight, and manage_phased_release.

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?

The description gives a clear precondition (version must be in PENDING_DEVELOPER_RELEASE) and two gating conditions (confirm:true, Pro feature). It does not name an alternative sibling such as release_preflight or explain what to do if the version is not yet approved, so it stops short of full when/when-not routing.

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

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

The readOnlyHint=true annotation already establishes this is a safe, non-mutating read, so the description is not carrying the full behavioral burden. It adds the set of possible status values, which is genuinely useful, but says nothing about whether the result is live from App Store Connect, cached, or subject to rate limits.

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?

A single front-loaded sentence with zero filler; the purpose and the expected result values are both delivered before the reader needs anything else.

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 one-parameter, read-only tool this is nearly sufficient: purpose and likely return values are covered. With no output schema, it could have said slightly more about what the response actually contains or how fresh it is, but nothing an agent strictly needs to invoke it 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 description coverage is 100% — app_id is documented as the 'App Store Connect app ID' with a numeric pattern — so the schema does the heavy lifting for the single parameter. The description adds no meaning beyond that, which is the baseline 3 case.

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 ('Check the current App Store review status') and even enumerates the possible result values, so an agent knows exactly what it retrieves. It does not differentiate itself from any sibling (e.g., submit_for_review as the preceding step), which keeps it short of a 5.

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 when-to-use or when-not-to-use guidance, no prerequisites, and no mention of related siblings such as submit_for_review or release_preflight. Usage is only inferable from the tool name itself, which is the minimum rather than real guidance.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds one genuinely useful behavioral fact beyond the annotations: it is a Pro feature, implying an entitlement check. It does not disclose rate limits, pagination, or what happens when the vendor number is omitted (the schema only hints at this).

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 terse, front-loaded sentences with no filler — the verb and resource lead, and the Pro caveat closes. It is perhaps too terse to earn a 5, but every sentence carries 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?

With no output schema, the description does carry the burden of describing returns, and it does so only summarily (units, proceeds, territory). Given three fully documented parameters and a simple read-only tool, this is adequate but leaves return shape and entitlement-failure behavior unspecified.

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 100%, so frequency, report_date formats, and the vendor_number sourcing note are already documented. The description adds no syntax or default information beyond the schema; 'territory' is mentioned but is report content, not an input parameter, so it does not map to any field.

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 ('Download sales/downloads summary') and enumerates the report contents (units, proceeds, territory), which is enough to distinguish it from the release/metadata/review management siblings. It does not, however, name any sibling or explicitly contrast itself with them.

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?

'Pro feature' is the only usage guidance, and it is a licensing caveat rather than a when-to-use rule. The description never says when an agent should reach for this report versus other analytics/reporting tools, nor what prerequisites (e.g., vendor number, Pro entitlement) must be satisfied first.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the write/destructive profile is covered structurally. The description usefully adds that Apple computes the final tier from the declarations (so the caller passes inputs, not a rating), but it does not clarify whether the declarations map replaces or merges with existing declarations.

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 with zero filler: purpose, then the call pattern with an example, then the Pro gating. The most important information is front-loaded.

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 two-parameter mutation tool with full schema coverage and annotations carrying the safety profile, the description covers purpose, the nested-map shape, and the gating constraint. No output schema exists, so nothing about return values is owed here.

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 100%, so the baseline is 3; the description earns an extra point by giving a concrete example key ('medicalOrTreatmentInformation') that the schema only describes generically, making the map's shape immediately usable.

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 ('Set the app's age-rating content declarations') and clarifies the outcome (Apple computes 4+/9+/12+/17+), which separates it from adjacent mutation tools like set_app_metadata. It does not explicitly name any sibling, so it stops short of a 5.

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?

Usage is only implied — an agent infers this is the tool for age-rating declarations. The 'Pro feature' note is a useful gating prerequisite, but there is no when-to-use/when-not guidance and no alternative named for related metadata tasks.

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

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

Annotations already flag destructiveHint=true, and the description reinforces this by disclosing that [] takes the app off sale worldwide. It also adds an external requirement (Pro feature) not present in structured fields. It does not state reversibility or that unlisted territories are disabled, though the schema covers the latter.

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, zero filler, with the core purpose front-loaded and the constraint immediately after. Every sentence 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?

For a four-parameter mutation with no output schema, the description covers the destructive case, the required-input contract, and the plan requirement. It omits what the response returns and whether partial failures are possible, which are minor given the rich schema.

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%, so baseline is 3, but the description adds the mutual-exclusivity rule between territories and all_territories and the off-sale semantics of the empty array. This goes beyond restating parameter descriptions.

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 precise verb and resource ('Set the app's country/region availability'), which is immediately distinguishable from siblings like set_app_price or set_app_metadata. An agent knows exactly what domain this mutates.

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 invocation rule: an explicit choice of territories list, all_territories:true, or [] for worldwide removal. It stops short of naming alternative tools or when-not-to-use conditions, but the required-input contract is unambiguous.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered structurally. The description usefully adds that unprovided fields are left untouched ('Each applied only if provided'), but says nothing about overwriting existing category/copyright values, permission/auth needs, or the 'Pro feature' gating implications beyond a terse label.

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 enumerated fields, no filler sentences, and the partial-update caveat and 'Pro feature' note are compact. The sentence is dense to the point of being a field list, which slightly hurts readability but wastes nothing.

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 6-parameter, 1-required mutation with full schema coverage and no output schema, the description covers every settable field and the partial-update semantics. Remaining gaps are minor: no confirmation of return behavior or error/precondition handling.

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 100%, so the baseline is 3; the schema already documents each field including the encryption guidance. The description reiterates the same fields (categories, copyright, content rights, encryption) and adds the appCategory-id convention, but contributes little syntax or format detail the schema lacks.

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?

Specific verb (Set) plus the exact resources being set: categories, copyright, content-rights, and export compliance. It names concrete field values (appCategory ids like HEALTH_AND_FITNESS) and clearly distinguishes itself from siblings like set_age_rating, set_privacy_nutrition, and update_version_metadata.

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?

'Submission-required app basics' implies this is part of the pre-submission flow, and 'Each applied only if provided' clarifies partial-update behavior. However, it never says when to use this versus the many adjacent setters (set_age_rating, set_privacy_nutrition, update_version_metadata) or states any prerequisites such as the app being in an editable state.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation risk is covered. The description adds meaningful behavior beyond that: it creates a price schedule, auto-equalizes to other territories (a side effect not in the schema), and is a paid-tier feature. It does not state reversibility or how existing pricing is replaced.

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 tight sentences, front-loaded with the core action and mechanism, then prerequisites. Every clause earns its place and nothing is padded.

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 simple two-parameter mutation with no output schema, the description covers action, mechanism, edge case (0 = free), and precondition. Minor gaps remain around what happens to prior pricing or territory overrides, but nothing critical to correct invocation 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 description coverage is 100%, so both parameters are already documented. The description's 'price_usd: 0 for free' restates the schema field rather than adding new meaning, so the baseline 3 applies.

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 ('Set the app's base price') and clarifies the mechanism ('by creating its price schedule') as well as the scope ('USA base, auto-equalized'). An agent immediately understands this is a write operation that establishes pricing, distinct from the metadata/version siblings.

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?

'Required before submission' gives a concrete precondition for calling it, and 'Pro feature' flags an availability gate. It stops short of naming alternatives or when-not-to-use conditions, but the context is clear.

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

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

With readOnlyHint=true already set, the description adds real value: it discloses that the tool does not actually mutate anything ('Not API-addressable') and that it returns steps plus a deep link, which corrects the misleading 'set_' naming. 'Pro feature' also flags access gating. It stops short of describing the return payload's shape.

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?

Two tight sentences that front-load the resource and immediately correct the misleading name. Every clause earns its place with no filler.

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 single-parameter, read-only guidance tool with no output schema, the description covers the essentials: what it relates to, that it is not API-addressable, and what it returns. Minor gap is the absence of any note on how the returned steps should be consumed or presented.

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?

There is a single parameter (app_id) with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing about the parameter, so the baseline of 3 applies.

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 resource (EU DSA trader status) and clarifies the actual behavior: it returns the steps and a deep link rather than performing the change implied by the name 'set_eu_trader_status'. This is clear, though it does not differentiate itself from related guide siblings like asc_guide or asc_setup_check.

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?

The phrase 'Not API-addressable' tells the agent this is a guidance-only tool, which is genuine usage context, but there is no explicit when-to-use guidance and no alternatives named. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation profile is known. The description adds value beyond that by disclosing automatic product resolution via product_id and the 'Pro feature' entitlement gate. It stops short of saying what happens to a pre-existing screenshot, which is the natural question given destructiveHint=true.

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, zero filler, and the most decision-relevant information (what it uploads and why) is front-loaded. Even the terse 'Pro feature.' fragment carries gating information 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 all three parameters documented and no output schema to explain, the description covers purpose, trigger condition, and entitlement requirement. The remaining gap is destructive behavior detail: with destructiveHint=true and no statement about replacing an existing review screenshot, an agent cannot fully predict the side effect.

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 100%, so app_id, product_id, and file are already fully documented in the schema, making 3 the baseline. The description only adds that product_id is auto-resolved to the product, a minor semantic clarification rather than new syntax or format guidance.

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 ('Upload'), an exact resource ('the App Review screenshot a subscription or in-app purchase needs'), and the outcome it unblocks ('leave MISSING_METADATA'). The IAP/subscription qualifier implicitly separates it from the sibling upload_screenshots, which handles app-store listing screenshots rather than product review assets.

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 gives a clear triggering condition: use this when a subscription or IAP is stuck at MISSING_METADATA. That is real context an agent can act on, but it never states what to do instead when the blocker is a different status, nor names any alternative tool.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description earns extra credit by disclosing behavior beyond that: Apple does not expose this via API, the return is step-by-step instructions plus a deep link, and the tool is gated to Pro users — all non-obvious traits an agent needs.

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, front-loaded sentences with no padding; the API limitation and return behavior come early. Only the mildly misleading opening verb costs it a point.

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 no output schema, the description correctly fills the gap by describing what comes back (steps + deep link). All required/optional parameters are covered by the schema, and the Pro restriction is noted, so an agent can call it correctly; explicitly resolving the read-only-vs-configure ambiguity would make it airtight.

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 100%, so both parameters are already documented with patterns and descriptions, giving a baseline of 3. The description's note about data_not_collected:true largely restates the schema's own wording and adds no format or edge-case detail beyond it.

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 the resource (App Privacy nutrition label) and the real outcome (returns the exact steps + deep link, since Apple does not expose it via API). The leading verb "Configure" is slightly misleading given the tool is read-only, but the very next clause corrects it, so an agent still lands on the right purpose without opening the 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?

Gives one concrete branch rule (pass data_not_collected:true for the 'Data Not Collected' path) and flags the Pro gate, which is useful. However it offers no when-to-use vs alternatives or when-not guidance, and no sibling (e.g. asc_guide) is named, so routing is only implied.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the write/destructive nature is covered. The description adds the 'editable version' constraint, which is useful, but says nothing about what existing settings get overwritten, auth requirements, or failure modes on a non-editable version. With annotations carrying the safety profile, this is adequate but thin.

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 tight sentences with zero filler, front-loading what the tool does before the prerequisite and the gating note. Every sentence 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?

For a 9-parameter setter with no output schema, the definition covers purpose, precondition, and gating. It leaves minor gaps about what happens on a non-editable version or what gets overwritten, but the annotations and full schema coverage make it largely sufficient.

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 100%, so all 9 parameters are already documented, including the subtle demo_account_required behavior. The description only alludes to the 'optional demo account' and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 (Set) and resource (App Review contact and optional demo account) plus a scope qualifier ('on the editable version'). It is clear what the tool does, though it does not name any sibling tool to differentiate from, so it falls short of the 5 bar.

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?

'Required before submission' gives a concrete precondition for when the agent must call it, and 'Pro feature' signals a gating constraint. There is no explicit comparison against alternatives (e.g., submit_for_review or update_version_metadata), but the context is clear enough.

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

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

Annotations already flag destructiveHint=true, and the description adds real context: a prerequisite (Apple Distribution certificate in keychain), a Pro gate, and the side effects of installing profiles. It does not warn that writing output_plist will overwrite an existing file at that path, which is the specific destruction an agent should anticipate.

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?

A single dense sentence-set, front-loaded with the tool's purpose and constraints in a logical order (why, what, prerequisite, availability). Every clause carries information; the only mild cost is a long first clause before the actions.

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 two-parameter mutation tool with no output schema, the description covers the goal, ordering relative to build_and_archive, prerequisites, and the Pro requirement. The gap is the absence of any statement about overwrite behavior or what the tool returns on success.

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%, so both parameters are already documented, including the default for output_plist. The description mentions the plist file and its role but adds no format or syntax detail beyond the schema, so the 3 baseline applies.

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 specific verbs and resources: downloads IOS_APP_STORE provisioning profiles (app + extensions), installs them, and writes a manual-signing ExportOptions.plist. It also situates itself in the workflow by naming build_and_archive, so an agent can distinguish it from generic release/upload siblings.

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?

Explains the condition that selects this tool – prepare signing without the cloud-signing permission many API keys lack – which implicitly tells the agent when it is unnecessary (when cloud signing is available) and that it precedes build_and_archive. No explicit 'do not use' clause or named alternative tool, so not a full 5.

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

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

Goes well beyond the destructiveHint=true annotation by disclosing the actual order of operations (IAPs first, then version), an explicit abort condition with its cause (first IAP must be bundled on the website) and the side effect that nothing is orphaned, plus the confirm:true guard against accidental outward-facing submission. This is the kind of consequence detail an agent cannot get from annotations or schema.

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?

Four tight sentences, front-loaded with the primary action, then sequencing, then the failure mode, then the safety gate. Every sentence carries distinct operational information with no filler.

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, no-output-schema mutation tool, the description covers ordering, abort semantics, reversal avoidance, and the confirmation gate — the essentials an agent needs. It stops short of describing what a successful submission returns, though with no output schema that is a minor omission.

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%, so app_id, confirm, and platform are already documented with enums and patterns; the description only reinforces confirm:true. Baseline 3 is appropriate since the description adds no new syntax or format meaning for the parameters themselves.

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 ('Submit the editable version to Apple App Review') and scopes it precisely to the editable version, which separates it from sibling tools like release_version or create_version. The added sequencing detail ('First submits any READY_TO_SUBMIT in-app purchases...') makes the operation unambiguous.

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?

The description implies when to use it (submitting an editable version for review) and states the confirm:true prerequisite and the Pro-feature gate, but never names an alternative such as release_version or explains when this is the wrong tool. Usage is inferable rather than explicit.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful context beyond that: it runs via MCP Sampling using the client's own model (no extra server cost), and it is gated behind a Pro feature. This is the kind of operational detail annotations cannot convey. It stops short of noting latency or failure modes of the sampling step.

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 and output, followed by cost and feature-gating notes. Little waste; the sampling/cost sentence earns its place because it affects invocation decisions.

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 no output schema, the description carries the burden of describing returns, which it does well (themes, counts, representative quotes, action buckets). Combined with full schema coverage for inputs and a read-only annotation, an agent has enough to call it correctly.

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%, so app_id, days, limit, and rating are already fully documented in the schema. The description implies a look-back window ('recent reviews') but adds no syntax or constraint detail beyond what the schema provides, so the baseline 3 applies.

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 gives a specific verb and resource (pull reviews and cluster them into 3-5 themes) and specifies the exact output shape with counts, quotes, and action buckets. This clearly separates it from sibling list/review tools like list_reviews and review_status, which do not cluster.

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?

The usage context is implied (thematic triage of recent reviews) and there's a hint of prerequisites via 'Pro feature' and the MCP Sampling mechanism. However, it never explicitly states when to choose this over list_reviews or review_status, nor any exclusions. Adequate but no explicit routing.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description still adds value beyond that: it discloses that Apple character limits are validated before writing and that it targets only the editable version. It does not state partial-update semantics or what happens on validation failure.

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, fully front-loaded: verb+resource first, then the editable field list, then the validation and gating notes. No filler or restated title.

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 mutation tool with no output schema, annotations covering the destructive profile and a fully documented parameter schema, the description is nearly complete. The one meaningful gap is that it never says omitted fields are left untouched (partial update) versus cleared.

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 100%, with each of the 11 parameters carrying its own description and length limits, so the baseline is 3. The description merely re-lists the same fields and adds no syntax or format detail beyond the schema.

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?

Specific verb ('Edit') plus resource ('App Store metadata on the editable version') and an explicit enumeration of editable fields. Clear enough that an agent knows what it does, but it never distinguishes itself from the closely related sibling set_app_metadata.

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?

Context is only implied: 'on the editable version' signals a precondition (the version must be in an editable state) and 'Pro feature' signals a gating requirement. There is no explicit when-to-use vs when-not, and no routing away from the near-duplicate set_app_metadata sibling.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, yet the description adds real context the annotations cannot: the API-key auth requirement, the explicit confirm:true gate, the outward-facing nature of the call, and the Pro-feature prerequisite. It stops short of describing irreversibility or what happens on a partial/failed upload.

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, front-loaded fragments with no filler; the action and destination lead, constraints follow. The telegraphic style ("Outward-facing", "Pro feature") is compact but slightly under-explained rather than wasteful.

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 3-parameter, no-output-schema mutation tool with safety already covered by annotations, the description supplies the missing auth, confirmation, and entitlement context. It omits failure/retry behavior and any hint about the platform parameter, which keeps it shy of complete.

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 100%, so both ipa_path, confirm, and platform are already documented with defaults. The description reinforces the confirm gate and the .ipa type but adds no format, path, or platform-selection detail beyond the schema, so the baseline of 3 applies.

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 (upload), resource (signed .ipa), and destination (App Store Connect via altool), which is clearly more than a restatement of the name. It does not, however, distinguish itself from nearby siblings like build_and_archive or attach_build, so an agent must infer which stage of the pipeline this occupies.

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?

"Requires confirm:true" and "Pro feature" give concrete invocation conditions, and "outward-facing" hints at the level of commitment. But it never says when to use this versus siblings (build_and_archive, attach_build, list_builds), leaving the sequencing of an upload pipeline implicit.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds useful context beyond that: the internal reserve/upload/commit flow and the Pro gating requirement. It still doesn't say whether existing screenshots are replaced or appended, which is the key destructive behavior.

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, front-loaded sentences with zero filler. The purpose is stated first, the notable internal behavior second, and the access constraint last.

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 mutation with no output schema and full annotation coverage, the description supplies purpose, the multi-step Apple flow, and the Pro entitlement. It falls just short by not clarifying replace-vs-append semantics on existing screenshots.

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 100%, so all four parameters (app_id, display_type, files, locale) are already documented in the schema. The description only echoes the display_type and locale concepts without adding format or ordering detail beyond what the schema provides, so baseline 3 applies.

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 (upload) and resource (screenshots) scoped to a version localization and device display type, with a concrete example (APP_IPHONE_67). This clearly separates it from the IAP-specific sibling set_iap_review_screenshot, though it doesn't name an alternative explicitly.

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?

The scope ('version localization for a device display type') implies the usage context, and 'Pro feature' signals an entitlement gate. However, it gives no explicit when-to-use vs. when-not guidance and names no alternatives for placing screenshot assets.

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

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

With readOnlyHint=true already covered by annotations, the description still adds real behavior: it blocks, defaults to a 30-minute wait, polls, and is a Pro feature. It doesn't note what happens on timeout (partial return vs error), which is the one meaningful gap.

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 tight sentences with the core behavior and terminal state front-loaded, then the timeout caveat and the Pro-gating note. No filler.

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?

No output schema exists, and the description implies the terminal state (VALID) but doesn't state what is returned or how a timeout surfaces. For a simple polling tool with full schema coverage, this is nearly complete.

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 schema already documents poll_seconds, max_wait_seconds, defaults and caps. The description only restates the 30-minute default, adding no syntax or semantics beyond the schema, so the baseline 3 applies.

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 (poll/wait) and resource (the newest uploaded build), plus the terminal condition (VALID) and the goal (ship flow in one call). This clearly differentiates it from the sibling list_builds.

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?

Explicitly says when to use it (to make the ship flow one call) and when not to (if you should not hold the session that long, call list_builds yourself instead). The alternative is named with the selecting condition.

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