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

With only destructiveHint=true available in annotations, the description carries the burden by disclosing a non-obvious two-phase protocol: a client-side confirmation prompt when supported, otherwise a preview response yielding a confirmToken that must be replayed only after explicit user approval. This is substantial operational context an agent could not infer from annotations or schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, then the confirmation behavior. Dense but every sentence carries needed information; the parenthetical about MCP_CONFIRM_MODE is a compact reference rather than padding.

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, the description covers the calling protocol thoroughly, including the failure/preview path. It does not describe success/failure outcomes for the final call or behavior when a tester is already in the group, which are minor gaps.

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 betaGroupId, betaTesterIds, and confirmToken are already fully documented in the schema itself; the description only echoes the confirmToken flow at a high level. Baseline 3 is appropriate since the description 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?

States a specific verb ('Add') and resource ('one or more existing beta testers to a beta group'), with the qualifier 'existing' scoping which testers qualify. An agent can immediately distinguish this from remove_testers_from_beta_group and invite_beta_tester 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?

The word 'existing' implicitly tells the agent to use this only for testers already in the account (vs invite_beta_tester for new ones), and it clearly states the confirmation requirement and when the confirmToken path applies. It stops short of explicitly naming alternative tools or exclusions, so it is 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?

Annotations cover safety (readOnly, idempotent, openWorld), and the description adds meaningful context beyond them: it never returns the credential, it reports which source supplied it, the round-trip time, and a plain-English failure classification distinguishing missing vs. rejected credentials vs. server-side problems.

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 paragraph that answers what, how, what it reports, and when to call it. Minor waste in repeating the full hostname 'api.appstoreconnect.apple.com' three times, which could be shortened after first mention.

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 input parameters and no output schema, the description carries the return-value burden itself and does so: it enumerates what is reported and how failures are categorized. Nothing an agent needs to call this 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?

The tool takes zero parameters, so there are no parameter semantics to document. Baseline 4 applies; the description correctly implies no input is required.

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 chain: resolve the credential, then make one authenticated request to api.appstoreconnect.apple.com. This is unambiguous against siblings like list_apps or get_build, which are all data-retrieval tools; this one is purely diagnostic.

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?

Provides a clear trigger condition: 'Call this when a real tool fails and you want to know which hop broke.' That is strong contextual guidance, though it doesn't explicitly name when-not to use it or point to an alternative diagnostic.

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 supply destructiveHint=true; the description adds the critical operational detail that the removal is permanent and that confirmation is mandatory, then specifies the two execution paths (native prompt vs. preview + confirmToken round-trip) and points to MCP_CONFIRM_MODE. This is exactly the behavioral context an agent needs before invoking a destructive tool.

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, both earning their place: the destructive action and its permanence come first, then the confirmation mechanics. No filler or restated field labels.

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 still covers everything an agent needs for a destructive operation: permanence, the mandatory confirmation gate, both confirmation modes, and token provenance. Nothing essential to a correct call 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 the baseline is 3, but the description adds state-machine meaning the schema alone doesn't convey: phase 1 returns a preview and confirmToken, and only a repeat call carrying that token proceeds. That sequencing context materially clarifies when confirmToken is legally supplied.

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+resource ('Permanently remove a beta tester') with an explicit scope qualifier, 'from your team', which distinguishes it from the sibling remove_testers_from_beta_group. An agent can tell what this deletes and at what level 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?

The 'from your team' scope implies this is team-level removal rather than group-level, but the description never names remove_testers_from_beta_group or states when to pick one over the other. It describes the confirmation workflow in detail but leaves alternative selection to inference.

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 annotation readOnlyHint=true already establishes a safe read operation. The description adds the return format ('parsed TSV rows') and content scope ('proceeds and adjustments'), which is useful, but it does not disclose additional behavioral traits such as pagination behavior, authentication 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?

The description is two tight sentences with no wasted words, and the core purpose and return format are front-loaded for immediate understanding.

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 stating the return format ('parsed TSV rows'). Parameter details are fully covered by the schema. The only minor gap is the absence of any note about pagination or the default row limit, but that is documented in the 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 description coverage is 100%, so the schema fully documents all five parameters. The description only references the region concept and does not add syntax, format, or interaction details beyond what the schema already provides, making the baseline score of 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 states a specific verb (Download) and resource (a financial report about proceeds and adjustments) with a regional scope. It implicitly distinguishes itself from the sibling download_sales_report by naming the report domain, though it does not explicitly call out that alternative.

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 download_sales_report or when to select different reportType values. The implied usage is clear from the verb and resource, but no explicit conditions or exclusions are provided.

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 meaningful behavior beyond that: it discloses the return format as 'parsed TSV rows', which helps an agent anticipate the output 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 short, front-loaded sentences with no filler. The purpose is stated first, followed by return format and a parameter tip, which is efficient structure.

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 7-parameter tool with no output schema, the description gives the return type (TSV rows) but is thin on how it relates to download_finance_report and omits any detail on large multi-row reports beyond what the schema's limit parameter implies.

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 schema fully documents all 7 parameters including enums and date formats. The description only adds that vendorNumber is Apple-issued and where to find it, so the schema remains the primary source; 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?

States a specific verb and resource ('Download a sales/units report'), making the action clear. However, it does not differentiate itself from the sibling download_finance_report, which a reader could easily confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by pointing to where a vendor number comes from (App Store Connect > Payments and Financial Reports), which is a useful prerequisite. But there is no explicit guidance on when to use this versus download_finance_report or other report 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 the safe-read profile is covered. The description adds nothing on top of that — no note on what fields 'details' contains, no rate-limit or auth context — so it qualifies only as adequate given the lower bar set by 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?

A single front-loaded sentence with no filler; every word contributes to identifying the resource and the keying parameter.

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 tool with annotations covering safety and no output schema to explain, the description is largely sufficient. The mild gap is that 'details' is left undefined and the sibling get_app_infos is never addressed, but 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 description coverage is 100% and the single parameter is fully documented in the schema, including its numeric format and the 'from list_apps' origin. The description's 'by app ID' restates the schema without adding syntax or format meaning, 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 ('Get') and resource ('details for a single app') and scopes it by App Store Connect app ID, so the operation is unambiguous. However, it does nothing to distinguish itself from the sibling get_app_infos, which an agent could easily confuse with it.

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 offers no when-to-use guidance, no prerequisites, and no reference to alternatives or the workflow that precedes it. While a lookup tool's usage is somewhat implied, the presence of a near-identical sibling (get_app_infos) makes the absence of routing guidance a real gap.

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 covering the safety profile, the description adds useful content context (age rating, current store state) beyond the annotations. It does not, however, disclose pagination, ordering, or return shape, so it is adequate but not rich.

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 tight sentence with the resource and its notable contents front-loaded. 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 one-parameter read tool with readOnlyHint and no output schema, the description conveys the resource and the meaningful fields returned, which is enough to call it correctly. It stops short of telling the agent how the results relate to the other list_*/get_* tools.

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 appId parameter is fully documented in the schema as the App Store Connect app ID. 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 (List) and resource (App Info records) scoped to a single app, and clarifies that the records carry age rating and store state. It is clear on its own, but does not explicitly differentiate 'App Info records' from siblings like get_app or list_apps, so an agent must infer the boundary.

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 offers no when-to-use guidance, no prerequisites, and never names an alternative among the many sibling read tools (get_app, list_apps, list_app_store_versions). Usage is only weakly implied by the 'for an app' phrasing.

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, non-mutating read. The description adds value by naming the fields returned, which is helpful given there is no output schema, but it says nothing about failure behavior (e.g., unknown or expired build IDs) or authentication requirements.

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 compact sentence, front-loaded with the verb and resource, and the field list is tacked on without filler. 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?

For a simple single-resource getter with readOnlyHint and full schema coverage, the description is nearly complete, and listing returned fields partly compensates for the absent output schema. Only the lack of error/lookup guidance 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?

There is a single parameter with 100% schema description coverage, and the description only restates 'by ID' without adding format, pattern, or lookup-source guidance beyond the schema's pattern and description. Baseline 3 is appropriate when the schema fully documents the parameter.

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 ('Get a single build by ID') and enumerates the salient fields returned (version, processing state, expiration, encryption flag). 'Single build by ID' implicitly distinguishes it from the sibling list_builds, but it never names that sibling, so differentiation is inferred rather than stated.

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: 'by ID' signals that a buildId must already be known, presumably from list_builds, but the description never says when to use this versus list_builds or what to do if the ID is unknown. No prerequisites or 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?

With readOnlyHint=true already covering the safety profile, the description adds real value: it discloses that the developer response is part of the return payload and flags that title/body/nickname are untrusted public text to be treated as data, not instructions. That prompt-injection guidance is behavioral context an agent cannot get from annotations. It omits any not-found/error behavior, keeping it below 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?

Two sentences, both front-loaded and purposeful: the first states the operation and payload, the second carries the security caveat. 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 with no output schema and readOnlyHint set, the description is nearly complete: it names the resource, hints at the return content, and warns about untrusted text. It could say slightly more about what the response contains or what happens for an unknown ID, 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% for the single reviewId parameter, so the schema already fully documents it; the description adds no format or constraint detail. Baseline 3 is appropriate when the schema does all the work.

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 (get a single customer review) plus the notable payload detail that the developer response is included when present. It is clearly distinguishable from the sibling list_customer_reviews by the word 'single'.

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 word 'single' implicitly contrasts with list_customer_reviews, giving a hint about when to prefer this tool. However, there is no explicit when-to-use statement, no prerequisites, and no named alternative, so 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?

Goes well beyond the destructiveHint annotation by disclosing that a real email is sent, that user confirmation is required, how the elicitation path differs from the confirmToken fallback, and that the token must never be invented or reused. This is exactly the side-effect and safety context an agent needs for an externally visible write.

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-loads the action and its real-world side effect, then describes the confirmation flow. Dense but every clause carries information; the confirmation sentence is long though justified by the non-trivial two-step protocol.

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 with no output schema, it covers the essential behaviors: the email side effect, the optional targeting, and the full confirmation protocol including the phase-1 preview/confirmToken response. What it omits is return-value or error detail beyond the preview, and explicit sibling routing.

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 every parameter (email, buildIds, betaGroupIds, names, confirmToken) is already documented in the schema with equal or more detail. The description only restates that group/build targeting is optional, adding no syntax or format meaning beyond structured fields, 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 ('Invite a new beta tester by email') plus the concrete effect ('sends a real email') and the optional scope (beta groups/builds). An agent can distinguish this from siblings like invite_user or add_testers_to_beta_group 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 explains the confirmation workflow and the two-step confirmToken fallback path, which is exactly what an agent needs to invoke it correctly. It does not, however, route the agent between this tool and the sibling invite_user or add_testers_to_beta_group, so alternative selection is left to inference.

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 only destructiveHint=true in annotations, the description carries the real burden and delivers: it discloses that a real email is sent, that ADMIN is a grantable role, and details the two-phase confirmation protocol (elicitation prompt otherwise preview + confirmToken, governed by MCP_CONFIRM_MODE). This is exactly the behavior an agent needs before calling a write tool.

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-loads the action and resource in the first clause, then explains the confirmation contract. Slightly dense with parentheticals, but every sentence earns its place and nothing is redundant.

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 an 8-parameter destructive write tool with no output schema, the description covers the safety-critical behavior (real email, ADMIN escalation, mandatory confirmation, fallback token mechanics) that the schema cannot express. 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?

Schema description coverage is 100%, so the schema already documents all eight parameters, including the confirmToken semantics and visibleAppIds/allAppsVisible interaction. The description adds only the note that roles may include ADMIN, which is minor value beyond the enum already in the schema; 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?

States a specific verb and resource ('Invite a new user to your App Store Connect team') plus the configurable dimension ('with specified roles'). An agent can distinguish this from the sibling invite_beta_tester, which targets beta testers rather than team members.

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 purpose (team-member invitation) but the description never says when to use this instead of invite_beta_tester or list_user_invitations, nor any prerequisites for who may invite. It spends its guidance budget on the confirmation flow rather than tool selection.

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 description would need to add context beyond that. It mentions filters (already fully documented in the schema) but says nothing about pagination behavior, default result size, or result shape that isn't already in the parameter descriptions.

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 with the core action front-loaded and the filtering capability immediately after. Every word earns its place and there is 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 read-only listing tool with a fully documented schema and a readOnlyHint annotation, this is nearly sufficient. The lack of an output schema leaves result shape and pagination semantics to the parameter text, which is a minor gap but adequately covered there.

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 four parameters are already documented in detail, including defaults and the 200-vs-1000 limit nuance. The description merely repeats the name and bundleId filters, adding no meaning beyond the schema – 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 ('List') and resource ('apps in your App Store Connect account'), which cleanly separates it from the sibling get_app. It does not explicitly name siblings or scope, but the list-vs-get distinction is 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?

Usage is only implied by the verb 'List' and the mention of optional filters. There is no statement of when to use this versus get_app, list_app_store_versions, or other listing siblings, and no prerequisites are given.

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 read. The description adds that returned versions carry state and platform, but says nothing about pagination behavior, ordering, or empty-result handling beyond what the schema's auto_paginate/limit descriptions already carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single well-formed sentence with the resource front-loaded and the useful content (state, platform) at the end. No wasted 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 list tool with a fully documented schema and no output schema, the description is nearly sufficient. It could add ordering or pagination nuance, but nothing critical 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 the schema already documents appId, limit, platform, appStoreState, and auto_paginate with enum values and defaults. The description adds no parameter-level detail, 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 (List) and resource (App Store versions/releases) scoped to a single app, and clarifies that state and platform are surfaced. It implicitly separates itself from siblings like list_builds and list_beta_groups, but never names 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?

Usage is implied by the wording 'for an app' — the agent understands this lists release versions given an appId. There is no explicit when-to-use guidance, no mention of when to prefer list_builds or get_app instead, and no stated prerequisites.

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 tells the agent this is a safe read. The description adds only the scope note that both internal and external groups are returned, which is mild added context. It says nothing about pagination behavior or default result size beyond what the schema already documents.

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, the resource and scope are front-loaded, and there is no filler. Every phrase 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 read-only list tool with no output schema, fully documented parameters, and a safety annotation already present, the description covers what an agent needs to call it. A note on default result set or pagination would round it out, 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 four parameters (appId, limit, auto_paginate, isInternalGroup) are already documented in the schema itself. The description's 'filter by app or group type' merely restates those parameters at a high level 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?

States a specific verb (List) and resource (TestFlight beta groups) with explicit scope '(internal and external)'. It does not differentiate itself from siblings like list_beta_testers, but the resource is unambiguous enough for an agent to select it correctly.

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?

'Filter by app or group type' implies the conditions under which the tool is useful, but gives no explicit when-to-use vs alternatives or exclusions (e.g., that list_beta_testers is the tool for people, not groups). 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?

The readOnlyHint=true annotation already establishes this as a safe, non-mutating operation, so the description carries a lighter burden. It adds nothing about result ordering, default truncation, or pagination, though the schema does cover the pagination controls; given annotations supply the safety profile, a 3 is appropriate.

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, front-loaded sentences with no filler: the purpose leads and the filtering dimensions follow. It is efficient, though the filtering sentence is arguably redundant given the fully documented 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 simple read-only listing tool with 100% parameter coverage and no output schema to explain, the description is nearly sufficient to call it correctly. It omits only result-shape and default-limit expectations, which are minor for this operation.

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 every parameter (appId, email, betaGroupId, limit, auto_paginate) is already documented in the schema with more detail than the description. The description only broadly gestures at the same three filters, adding no syntax or default-value meaning 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?

The description states a specific verb and resource ("List TestFlight beta testers") plus the scope of filtering, which is clear enough to distinguish it from the write-oriented siblings like invite_beta_tester and delete_beta_tester. It does not, however, explicitly name any sibling or contrast itself with list_beta_groups.

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 by the word "List" and the mention of filterable dimensions. There is no explicit when-to-use guidance, no prerequisites, and no pointer to the related siblings (e.g., list_beta_groups) that an agent might confuse this with.

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 as a safe read, and the description usefully adds the default sort order (newest-first by upload date). However it says nothing about pagination behavior, result caps, or how auto_paginate affects return size — relevant for a list tool with a 1000 max limit.

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 with zero waste; the sort/scope statement is front-loaded ahead of the filter list. 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 read-only list tool with full schema coverage and no output schema, the definition covers purpose, ordering, and filter surface. It stops short of explaining pagination or result shape, but annotations and schema carry most of the remaining load.

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 (appId, limit, version, auto_paginate, processingState) are already documented in the schema. The description names a subset of the filters but adds no syntax, format, or semantics beyond what the schema carries. 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 ("List recent builds") and adds sorting behavior (newest first by upload date). It clearly distinguishes this bulk-listing tool from the singular get_build sibling by implication, though it never names or contrasts with it 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?

Usage is implied by the filter list, but there is no explicit guidance on when to use this versus get_build for a single build, nor any note on pagination strategy or expected volumes. An agent can infer the intent but must guess at the 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?

Annotations already declare readOnlyHint=true, so safety is partly covered, but the description goes beyond that with a genuinely valuable behavioral warning that review title/body/nickname are untrusted public text to be treated as data, not instructions. It doesn't mention rate limits, auth scope, or pagination behavior beyond what the schema states, so it stops 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 tight sentences with zero filler; the primary purpose and default ordering lead, followed by filter options and then the safety note. Every sentence carries distinct 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 read-only list tool with annotations covering the safety profile and a fully documented schema, the definition covers purpose, defaults, filters, and an important prompt-injection caution. It omits any indication of return shape or pagination behavior, which matters somewhat since no output schema exists.

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 schema already documents every parameter, making 3 the baseline. The description adds only the default sort direction (newest first), which the schema enum doesn't state, while 'filter by rating or territory' largely restates 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 a specific verb and resource (list customer reviews for an app) plus scope details: default sort, filters by rating and territory. This clearly separates it from the singular get_customer_review sibling, though it never names that sibling 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?

Implies when to reach for the filters ('Filter by rating or territory') and documents the default sort, but gives no when-not guidance and does not point to alternatives such as get_customer_review or respond_to_review. 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 declare readOnlyHint=true, so the safety profile is covered. The description usefully narrows behavior by specifying 'pending' invitations (excluding accepted/revoked), which is real context beyond the annotation, but says nothing about auth needs 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?

A single front-loaded sentence with zero waste. It is well-sized, though the brevity means it leaves opportunity for routing guidance on the table.

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, the description plus rich schema descriptions and readOnlyHint cover most needs. Only the lack of sibling routing guidance leaves a minor 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 the schema already documents email filtering, limit, and auto_paginate behavior in detail. The description adds no parameter meaning 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 ('List') and resource ('pending user invitations') with a clear scope ('on your team'). It is distinguishable from siblings like list_users and invite_user, though it never names them 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?

No guidance on when to use this versus list_users or invite_user, and no prerequisites or conditions mentioned. The agent must infer usage from the name alone.

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 nothing beyond that: no note on ordering, result size, pagination defaults, or what happens with role/username filters, all of which would be new information rather than a restatement of the annotation.

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 no filler. It is efficient, though its brevity comes at the cost of any scoping or alternative detail rather than being purely economical.

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 parameterless, read-only list tool with a fully documented schema and readOnlyHint annotation, the essentials are covered. The absence of an output schema means return-shape information is unavailable, but a list-users result is self-evident enough that this is a minor 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%, so all four parameters (limit, roles, username, auto_paginate) are already fully documented, including the auto_paginate/limit interaction. The description contributes no additional parameter semantics, which is acceptable at this coverage level.

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 (users on your App Store Connect team), so the operation is unmistakable. It does not, however, distinguish itself from the nearby sibling list_user_invitations, which an agent could easily confuse with this one.

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, when-not-to-use, or alternative guidance. The description never mentions list_user_invitations, so an agent has to infer from the name alone whether it wants existing team members or pending invitations.

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 entire confirmation protocol: a client confirmation prompt where supported, otherwise a two-phase preview-plus-confirmToken handshake governed by MCP_CONFIRM_MODE. It also clarifies the non-destructive scope of the removal. This is exactly the behavioral context an agent needs before invoking a destructive tool.

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 and scope in the first clause, followed by the confirmation model. Two focused sentences with no filler, though the confirmation explanation is fairly dense and could be slightly tighter.

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 three-parameter destructive mutation with no output schema, the description adequately covers purpose, scope, and the confirmation workflow. Return/response shape is not described, but the creation of confirmToken in the fallback path is explained, which is the critical behavioral detail.

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 schema already documents betaGroupId, betaTesterIds, and confirmToken in full detail. The description adds conceptual framing for the confirmation flow but no syntax or format meaning beyond the structured fields, 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 — 'Remove one or more beta testers from a beta group' — and immediately disambiguates from the delete_beta_tester sibling with '(does not delete the testers)'. An agent can tell exactly what this does 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?

Usage is implied: it clearly concerns removing testers from a group rather than deleting them, but it never explicitly names when to prefer this over delete_beta_tester or add_testers_to_beta_group. No when-not conditions are given, leaving the agent to infer the group-vs-global scope distinction.

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 destructiveHint=true; the description adds substantial behavioral context beyond that: the response is public and visible on the App Store, the call is gated by a confirmation prompt where supported, and otherwise returns a preview plus a confirmToken that must be passed back only on an approved repeat call. That is exactly the kind of side-effect and auth/confirmation detail annotations cannot express.

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, purpose front-loaded in the first clause before the confirmation mechanics. No filler; every phrase (public, App Store, confirmToken, MCP_CONFIRM_MODE) 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?

For a mutation tool with no output schema, the description covers the consequence (public posting), the confirmation requirement, and the fallback return shape (preview + confirmToken). It leaves out whether an existing response is overwritten, required permissions, and rate limits.

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 confirmToken parameter is already documented in detail in the schema, including the 'never on the first call, never invented, never reused' rule. The description reinforces the two-phase flow but adds no new per-parameter meaning (no format constraints or examples for responseBody beyond what the schema states).

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 pair (post or update), the exact resource (the PUBLIC developer response to a customer review), and the scope (visible on the App Store). This is unambiguously distinct from the read-only siblings list_customer_reviews and get_customer_review.

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 confirmation protocol clearly and tells the agent to expect a two-phase interaction, which is the main 'how/when' guidance an agent needs. It does not explicitly say to locate the reviewId via list_customer_reviews/get_customer_review first, nor whether this can be used on a review that already has a response.

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 only destructiveHint=true given, the description carries the behavioral load and does so well: it discloses that this submits to Apple (an external, irreversible action), that user confirmation is mandatory, and describes the two-phase preview/confirmToken fallback including MCP_CONFIRM_MODE. No contradictions with 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?

Opens with the core action and scope before detailing the confirmation mechanics, which is well front-loaded. The parenthetical about MCP_CONFIRM_MODE is dense, but every clause is functional rather than 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 mutating tool with no output schema and only one annotation, the description covers the action, the required confirmation protocol, and the fallback response shape (preview + confirmToken). It is nearly complete; only the actual return payload after submission is unspecified, which is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so baseline is 3, but the description adds genuine meaning by explaining that confirmToken belongs only to the two-step fallback phase and is ignored when elicitation is supported — context the schema states but the description reinforces coherently within the tool's overall flow.

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 (submit a build for TestFlight beta app review) and adds the scope qualifier 'required before external testing', which distinguishes it from list_builds/get_build siblings. An agent knows exactly what this does without consulting 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 clear context: it is required before external testing and must be confirmed by the user, with the specific flow for clients that do and do not support elicitation. It does not name an alternative tool or state when NOT to submit, so it falls short of the top bar.

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