shipstores

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

No annotations are provided, so the description carries the full burden. It usefully discloses the VALID-state precondition, but says nothing about whether attaching replaces an existing build, whether the operation is idempotent/reversible, or what permissions are required for a mutation 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 short sentences, action stated first and the precondition second. No padding, 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?

An output schema exists, so return values need not be explained, and the prerequisite plus cross-reference are helpful. However, for a two-parameter mutation with no annotations and 0% schema coverage, the description leaves parameters and mutation side effects under-specified.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning, yet neither build_id nor version_id is explained. It only indirectly implies that build_id refers to a processed/VALID build and version_id to an App Store version, leaving format and sourcing unstated.

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 ('Attach') and resource ('a processed build to an App Store version'), which cleanly distinguishes it from siblings like apple_upload_build and apple_list_builds. An agent can identify the operation 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 an explicit precondition (the build must have processingState VALID) and routes to the sibling that reveals that state (apple_list_builds). It stops short of stating when not to use it or what happens if a build is already attached.

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 no annotations, the description carries the full burden and does so reasonably: it discloses this is an 'external action' and that the version transitions to DEVELOPER_REJECTED and can be resubmitted. It omits auth/permission requirements and any rate-limit or irreversibility caveats, but the resulting state change is well described.

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, action front-loaded, with the resulting state and follow-up tool packed efficiently. The timing idea is repeated ('before Apple decides' and 'without waiting for the review'), a minor redundancy, but 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?

An output schema exists, so return values need not be explained. Purpose, usage trigger, resulting state, and the follow-up tool are all covered; the missing parameter semantics and auth context are the main residual 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 0% and the sole required parameter app_id is never referenced or explained. The description only alludes to 'a version submitted for review' conceptually, adding no format or identity detail (e.g., whether app_id is a numeric App Store ID or a bundle identifier), so it fails to compensate for the coverage gap.

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: pulling a version submitted for review out of Apple's queue. It also clarifies the timing constraint ('before Apple decides') and distinguishes the action from the related submission flow, so an agent can tell it apart from apple_submit_for_review/apple_resubmit_for_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?

Gives a concrete when-to-use scenario ('swap the build without waiting for the review') and routes to the follow-up tool apple_submit_for_review. It does not state explicit when-not conditions or prerequisites, but the usage 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 no annotations, the description carries the full burden and does well: it discloses that Apple exposes no POST /v1/apps, that the tool operates by driving an already logged-in Chrome session, and that the actual creation is manual/assisted. It does not cover failure modes (e.g., no active browser session), keeping it from 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?

Front-loaded with the core action, followed by the rationale and prerequisite. Three short sentences with little waste, though the parenthetical API detail is slightly redundant for selection purposes.

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?

Given an output schema exists, explaining return values is unnecessary, and the description still notes that the tool returns the values needed for the form. Combined with the prerequisite, an agent has enough to invoke correctly; only the suggested_name semantics are 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 0%, so the description must compensate for both parameters. It implicitly ties bundle_id to the registered Bundle ID, but suggested_name is never explained (usage, format, or relationship to the form), leaving an agent without guidance on a required 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?

Specific verb (open) + resource (the new-app form) + channel (browser). The description also contrasts with the API path, so an agent can distinguish this assisted step from API-backed siblings like apple_register_bundle_id.

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 directs the agent to call apple_register_bundle_id first, giving a prerequisite and ordering. It does not enumerate when NOT to use it or name an alternative creation path, but the context is clear and actionable.

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 no annotations, the description carries the full behavioral burden. It discloses that this is an 'External action' (network call to Apple), that territory is required or Apple refuses, that only one offer per territory can be created, and that paid offer modes are unsupported. It does not mention authentication, rate limits, or idempotency, but the key operational behaviors are covered.

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 front-loaded with the core purpose and then uses clear, separated lines for each parameter's semantics. It is appropriately sized and every sentence adds value. Minor redundancy exists (e.g., 'free trial' appears in both the opening and offer_mode), but overall structure is efficient.

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?

Given the tool's complexity (creating a subscription intro offer via external API), the description is largely complete: it covers purpose, key parameters, limitations, and territory handling. The presence of an output schema means return values need not be explained. The main gaps are the unmentioned 'number_of_periods' parameter and the schema/description conflict about territory being required.

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

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

Schema description coverage is 0%, so the description must explain parameters. It thoroughly enumerates duration values and offer_mode options, and explains territory requirements. However, it completely omits the 'number_of_periods' parameter and does not explicitly define 'subscription_id'. Additionally, it claims territory is REQUIRED while the schema lists only subscription_id as required and gives territory a default, creating a semantic conflict.

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 opens with a specific verb+resource: 'Create the subscription's introductory offer (free trial).' It clearly distinguishes from sibling tools like apple_set_subscription_price and apple_create_subscription by focusing on the introductory offer creation. The parenthetical '(free trial)' further narrows the scope.

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 provides clear context for use: it notes that the tool is an 'External action' and explains the territory requirement ('one offer per country: Apple refuses to create the offer without it. To apply in several countries, call once per territory'). It also states that PAY_AS_YOU_GO and PAY_UP_FRONT modes are not covered, implying when not to use. However, it does not explicitly compare to alternative tools or state when to choose this over other subscription-related 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?

With no annotations, the description carries the burden well: it flags the operation as an external/live action, warns that product_id is IMMUTABLE and non-reusable, and discloses the resulting MISSING_METADATA state plus what is still required. It does not discuss permissions, error behavior, or reversibility, which keeps it out of the top band.

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 purpose and the external-action warning, then grouped into three short paragraphs covering immutability, field semantics, and lifecycle state. Every sentence provides decision-relevant 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?

An output schema exists, so return-value explanation is unnecessary, and the description covers creation, field meaning, valid periods, and the required follow-up workflow. The only gaps are the unspecified locale parameter and group_id semantics, minor against an otherwise complete picture.

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 0%, so the description must compensate, and it does for the important fields: product_id's immutability/reuse constraint, the name vs display_name/description distinction, and the full subscription_period value set with the 'no installment plans' caveat. locale and group_id are left unexplained, which is why it is not a 5.

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 + containment scope ('Create a subscription product inside a group'), which cleanly separates it from the sibling apple_create_subscription_group and apple_list_subscriptions. The 'External action' framing immediately signals a live-store mutation.

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 real precondition ('check product_id against what the app sends before calling') and names the required follow-up tools (apple_set_subscription_price, apple_set_subscription_availability) to move the product out of MISSING_METADATA. It stops short of stating when NOT to use it versus a sibling group-creation tool, but the workflow 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 no annotations, the description carries the full behavioral burden. It usefully flags 'External action' (a real App Store write) and explains the per-group free-trial consequence, but it omits permissions/auth requirements, whether the operation is reversible, and how re-running against an existing group behaves. Some value added, but significant gaps remain.

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 action in the first sentence, followed by the two clarifying facts (name semantics, per-group trial behavior). Every sentence carries information and none is filler, though the length is at the upper end of what this tool 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?

An output schema exists, so return values need no explanation, and the description covers the core naming and group/trial semantics. The main omissions are the meaning of the 'locale' parameter and any setup prerequisites, minor against an otherwise complete picture.

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

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

Schema description coverage is 0%, so the description must compensate. It does define the two genuinely ambiguous params well ('reference_name' is internal, 'display_name' is customer-facing), but leaves 'locale' (with its pt-BR default) and 'app_id' undocumented, so half the parameters get no added meaning.

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 first sentence states a specific verb and resource ('Create a subscription group and its localization'), which is clearly distinct from the sibling apple_create_subscription that creates individual products. However, it does not explicitly name or differentiate from siblings, so an agent must infer the relationship to apple_create_subscription from entity semantics alone.

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 makes the group's role clear ('Every subscription product lives inside a group') and explains that free-trial eligibility is per-group, which implies this is a foundational setup step. But it never states when to call it versus alternatives, nor any prerequisite ordering relative to apple_create_subscription or apple_set_subscription_price.

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 no annotations, the description carries the full behavioral burden. It does disclose a real behavioral trait – the precondition failure when an editable version exists – which is valuable and not visible in the schema. However, it says nothing about permissions/auth requirements or what the created version's side effects are.

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 core action, followed by the failure condition and fallback. No redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the behavioral/usage story is complete. The gap is input-side: three parameters, including an enumerated-by-convention platform default, are undocumented in both schema and description.

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

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

Schema description coverage is 0% across 3 parameters, so the description must compensate and largely does not. 'Existing app' only loosely implies app_id, and neither version_string nor the platform parameter (IOS default) nor its accepted values are explained anywhere.

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 (create) and resource (an App Store version for an existing app), making clear it operates on an already-registered app rather than creating one. This cleanly separates it from siblings like apple_create_app_form and apple_set_version_string.

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 the when-not condition ('fails if an editable version already exists') and routes the agent to the alternative (apple_list_versions) to reuse the existing version. This is exactly the kind of routing guidance an agent needs before calling.

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 no annotations, the description carries the full burden: it discloses the scope (the whole account) and the returned identity fields, but says nothing about pagination, ordering, empty-account behavior, or credential/auth requirements. Adequate for a trivial read-only list, 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?

Two short sentences, the scope and result stated first and the cross-tool ID semantics second. Nothing is wasted and it 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?

An output schema exists, so return structure need not be repeated. For a zero-parameter listing tool, the description covers purpose, scope, and the downstream meaning of the returned ID, which is everything an agent needs.

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?

Zero parameters, so the baseline is 4; the schema is fully covered anyway. The description still adds meaning by explaining that app_id maps to ascAppId, which the empty schema could never convey.

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 the apps in the App Store Connect account') and names the identifying fields it returns. It does not explicitly contrast with siblings such as apple_list_builds or apple_list_versions, but no other tool in the set lists apps, so confusion risk is low.

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 note that the returned app_id 'is the App ID (ascAppId) used by every other Apple tool' implicitly positions this as the entry point for Apple workflows, giving the agent a reason to call it first. There is no explicit when-not or alternative named, so it falls short of a 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?

No annotations are provided, so the description must carry behavioral disclosure. It implies a read-only list operation and explains the meaning of PROCESSING vs VALID, which is useful domain context, but it omits auth requirements, pagination behavior, and result ordering.

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 short, front-loaded with the core action, and then gives a focused explanation of processingState. 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 simple list tool with an output schema, the description covers the core purpose and the key output-state semantics. However, with no annotations and 0% schema description coverage, it leaves important invocation details such as parameter meaning and pagination unaddressed.

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

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

Schema description coverage is 0%, and the description does not document either parameter. It only implies that an app is selected, without clarifying app_id syntax or what limit controls.

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 uses a clear verb+resource ('List an app's builds') and adds the processing-state concept. It does not explicitly name sibling alternatives, but the Apple-specific scope is clear enough to distinguish it from generic build tools.

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 provides no when-to-use guidance, no prerequisites, and no alternatives such as eas_build_list or apple_list_versions. It only explains how to interpret processingState once results are returned.

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 no annotations, the description must carry the behavioral load; it usefully discloses the domain constraint that prices come from a fixed table and that `around` narrows the result set. It says nothing about read-only safety, pagination, result volume, or what happens when no matches exist near `around`.

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 purpose, then the domain rationale, then the one non-obvious parameter. Every sentence carries information an agent needs; 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?

An output schema exists, so return values need not be explained here. Still, for a 3-parameter tool at 0% schema coverage, the description omits the territory default and the meaning/format of subscription_id, and gives no indication of result size or filtering fallback behavior.

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

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

Schema description coverage is 0%, so the description must compensate. It does add real meaning for `around` (filters to points near a wanted price, with the 79.90 example), but says nothing about `subscription_id` or that `territory` defaults to BRA, leaving two of three parameters undocumented.

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 the price points available for a subscription in a territory'), so the agent immediately knows the operation. It does not, however, name or contrast with the most relevant sibling, apple_set_subscription_price, which consumes these points.

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 implies a workflow by explaining that Apple rejects arbitrary prices and you must pick from its table, which hints this precedes a price-setting call. But there is no explicit when-to-use/when-not, no mention of the sibling write tool, and no prerequisites for territory/subscription 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?

No annotations are provided, so the description carries the full burden. It usefully documents the 'state' field semantics (MISSING_METADATA vs READY_TO_SUBMIT), which is genuine behavioral context beyond the schema. However, it says nothing about pagination, permissions, rate limits, or whether this reflects live App Store Connect state, leaving gaps for a read tool with zero annotation coverage.

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: purpose first, then a key semantic note about the 'state' field. No filler; 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?

An output schema exists, so return values needn't be fully explained, yet the description goes further by clarifying the critical 'state' semantics. Missing pagination/permission context, but overall complete enough for an agent to call this 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?

One parameter (app_id) with 0% schema description coverage, but a single, self-evident required identifier. The description adds meaning by explaining the returned 'state' values, compensating for the missing param docs. Baseline for a 1-param tool is generous, and the state explanation adds real value.

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 the app's subscription groups, with the products in each') and defines scope precisely. An agent can distinguish it from siblings like apple_create_subscription_group or apple_set_subscription_price 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 description implies usage via the app_id param and the state explanation, but never states when to call this vs alternatives (e.g., before submission) or any prerequisites. Usage is inferable but not 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?

With no annotations, the description carries the full behavioral burden. It does disclose the notable behavioral trait that each version includes its review state, implying a richer read than a plain ID list, but it says nothing about read-only nature, rate limits, or pagination.

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 front-loaded and the extra return detail trailing. No wasted words, though it is arguably under-specified rather than optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description needn't explain return values beyond noting review state. The main gap is parameter documentation, which is absent from both schema and description, leaving the definition only minimally 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 0%, so neither app_id nor limit is documented anywhere. The description adds no meaning to either parameter—it does not clarify what app_id format is expected or what limit controls. It fails to compensate for the coverage gap.

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 (an app's App Store versions) and adds that each entry includes review state. This clearly distinguishes it from sibling list tools like apple_list_builds or apple_list_apps, which target different resources.

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 verb 'List' and by the required app_id, but there is no explicit when-to-use guidance, no mention of prerequisites or authentication, and no reference to sibling tools it might be confused 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?

No annotations are provided, so the description carries the full behavioral burden. It notes that the operation is supported by the API and identifies the next workflow step, but gives no details about permissions, side effects, duplicate handling, or error behavior for this mutating registration call.

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 short and front-loaded with the core action, followed by workflow context and platform values. It contains no wasted sentences, though the all-caps emphasis on 'IS' is slightly informal.

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 registration tool with no annotations and 0% schema parameter coverage, the description is incomplete: it omits auth/permission requirements, identifier format expectations, and failure modes. It does cover workflow placement and notes an output schema exists, so return values need not be described.

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

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

Schema description coverage is 0%, so the description must compensate. It only gives the possible values for 'platform' (IOS, MAC_OS, UNIVERSAL); it says nothing about the required 'identifier' or 'name' parameters, leaving two of three parameters without added meaning.

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 ('Register') and resource ('new Bundle ID in the Apple Developer portal'), making the action unambiguous. It also distinguishes itself from the app-record creation step by naming apple_create_app_form as the follow-up tool.

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 describes when to use it: as the first step for a new app. It also points to the next tool (apple_create_app_form) for creating the app record itself, giving clear workflow context. It does not state when not to use it or any prerequisites such as authentication.

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?

No annotations are provided, so the description carries the full burden, and it delivers: it warns this is an external action, that replying alone is insufficient because the version stays Rejected, that resubmission is required, and that HEVC is converted to H.264 at 1920px before upload. That is exactly the kind of irreversible/side-effect context 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?

Front-loaded with purpose and the external-action warning, then structured by scenario. Dense but every sentence carries operational weight; slightly over-packed for a single paragraph.

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?

Covers the action, the side effects, the size limit, the transcoding behavior, the required follow-up call, and the resubmission requirement. An output schema exists so return values needn't be explained, and nothing an agent needs to call 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 0%, so the description must compensate, and it does for the important parts: `text` is bounded at 4000 characters, and `attachments` is framed as the iPhone-recorded video with a stated transcoding behavior. `app_id` is left unexplained, keeping it from a 5.

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 ('Reply') and resource ('App Review on a rejected submission'), and explicitly flags it as an external action. An agent can distinguish this from apple_review_messages and apple_set_review_details without opening a 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 for when to use it (replying to a rejected submission) and names the companion tool apple_set_review_details with the condition that motivates using both. It stops short of a full when-not-to-use statement, so not a 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?

With no annotations, the description carries the burden and does well: it flags 'External action', states that rejected items are marked resolved, and warns that a Resolution Center reply alone will not clear the Rejected state. It omits permission/auth requirements and any confirmation or failure 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?

Front-loads the action and scope in the first sentence, then uses the second paragraph to disambiguate. The UI-analogy sentence ('Same as Update Review on the version page...') is slightly redundant but earns its place by clarifying behavior.

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?

Return values are covered by the output schema, and the description supplies the mutation semantics, prerequisite tool, and the common failure mode. Remaining gaps (auth requirements, what happens if the version was not actually rejected) are modest for a single-parameter action.

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) with 0% schema description coverage, and the description adds no meaning to it. The parameter is self-evident from its name, so the gap is minor, but the description does not compensate for the missing schema documentation.

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 (resubmit) and resource (a rejected version) plus the scope condition ('after replying to App Review or fixing it'). The 'Same as Update Review + Resubmit' analogy pins the exact operation, and 'submits the same review submission again' separates it from apple_submit_for_review's fresh submission.

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 an explicit when (after replying or fixing a rejection) and a when-not ('Replying in the Resolution Center alone keeps the version Rejected'). It also names the prerequisite/alternative tool (apple_attach_build) for the case where the fix required a new build.

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 no annotations, the description carries the full disclosure burden, and it does add one genuinely useful behavior: the demo account password is masked. However, it omits permission/auth prerequisites, whether the read is safe/non-mutating, and any rate-limit or freshness caveats, leaving real gaps.

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 core action and followed by exactly one non-obvious caveat. No filler or restated boilerplate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description usefully previews the returned fields and the masking behavior. It is complete enough to call correctly, with only minor gaps around parameter sourcing.

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 parameter (version_id) with 0% schema description coverage, so the description would ideally clarify what a version id is or where it comes from. It says nothing about parameters, though version_id is largely self-explanatory, keeping this at a minimum-viable 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 (Read) and resource (a version's App Review information) plus the concrete fields returned (contact, demo account, notes), which cleanly separates it from the write-side sibling apple_set_review_details. It stops short of naming that sibling explicitly, so it doesn't fully earn 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?

The closing clause frames intent ('check what Apple will see, not extract credentials'), which implies read-only inspection use, but it never states when to prefer this over apple_set_review_details or apple_review_messages. Usage is implied rather than spelled out.

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 no annotations, the description carries the full burden and does well: it discloses that this bypasses the public API and reads via the console's internal API inside a dedicated Chrome session, plus the login-failure remedy (store_browser_session). It stops short of describing rate limits, session prerequisites, or failure modes beyond login.

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 sentences, with the core purpose front-loaded and the implementation caveat second. The parenthetical is slightly dense but every clause carries actionable 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?

An output schema exists, so return values needn't be explained, and the description covers the key operational risk (internal API / session login). Only app_id semantics are left unaddressed, which is minor for a single required identifier.

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 0% and the single app_id parameter is undocumented in both schema and description. The description adds no semantics for app_id; it is adequate only because a lone, self-evident identifier keeps the ambiguity low.

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 (read) and a specific resource (review messages / Resolution Center, rejection reasons). It is distinguishable from siblings like apple_reply_review and apple_review_details, though it doesn't explicitly contrast itself with apple_review_details.

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 Resolution Center framing and the failure hint to check store_browser_session, but there is no explicit when-to-use / when-not-to-use guidance relative to apple_review_details or apple_reply_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?

No annotations are provided, so the description must carry the behavioral burden. It discloses that this is an external action, that it starts from all 'no/NONE' defaults, and that only provided overrides are applied. That clarifies the mutation semantics well, though it omits permission requirements or whether the change is immediately live.

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 brief, front-loaded with the core action, and every sentence adds value. The example clarifies the overrides format without 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?

An output schema exists, so return values need not be explained. For a mutation tool with no annotations and 0% schema coverage, the description supplies the key behavioral and parameter context. It still lacks sibling routing and prerequisite/auth details, keeping it short of 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 0%, so the description must explain parameters. It clearly defines the behavior of `overrides` (applied on top of no/NONE defaults), enumerates valid frequency values, and provides a concrete example object. `app_id` is undocumented but self-evident.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it sets or answers the age rating questionnaire. It is clearly distinct from generic app-info or privacy setters. However, it does not explicitly name sibling tools or differentiate itself from them, so it falls 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 implied by the phrase 'Answer the age rating questionnaire,' but there is no explicit when-to-use, when-not-to-use, or alternative tool guidance. The context of an app store submission makes the use case inferable, but the description does not carry the burden of 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?

With no annotations, the description carries the full burden. It does disclose useful behavior: 'External action' flags a side effect, and 'Only the fields passed are changed' documents partial-update semantics, plus the non-obvious fact that fields live on two different resources (appInfo vs. editable version). However it says nothing about authentication/permissions required, reversibility, or whether changes go live immediately.

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 purpose and the sibling boundary, then a compact enumeration of field placement. No filler sentences, though the second paragraph is a dense run-on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. For a 10-parameter mutation tool with 0% schema coverage and no annotations, the description covers most listing fields but leaves locale (and its pt-BR default) and uses_third_party_content entirely undocumented.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It adds real meaning for the category fields (Apple IDs such as MEDICAL, HEALTH_AND_FITNESS) and maps most listing fields to their owning resource, but app_id, locale, and uses_third_party_content are never explained.

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+resource ('Fill in the listing fields') and explicitly carves out scope relative to the sibling apple_update_listing, so an agent can tell the two apart. It is slightly indirect in that the exact fields are only revealed in the following sentence, but the purpose 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?

It names the alternative tool (apple_update_listing) and defines the boundary: use this for the fields update_listing does not cover. There is no explicit statement of prerequisites or when not to use it, but the routing rule 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?

No annotations exist, so the description carries the full burden, and it does disclose the important traits: "Replace" signals a full overwrite of the existing declaration, "publish" and "External action" signal a live, externally visible mutation, and "Uses the console's internal API" warns of a non-public, potentially fragile integration. Missing are auth requirements and irreversibility/rollback details.

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 action and its side effect, followed by the payload contract. The inline JSON example earns its space, though the categories/purposes pointer is a bit terse for an agent that cannot read the referenced constants directly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the description covers the mutation semantics and payload format that the schema and missing annotations leave open. It falls short only on permissions/prerequisites and on what "publish" changes about store readiness.

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 0% and the `usages` array is loosely typed, so the description has to compensate: it supplies a concrete item shape, states one item per collected data type, defines the empty-list meaning ("we do not collect data"), and points to apple_console.DATA_CATEGORIES / DATA_PURPOSES for valid values. Only `app_id` is left unmentioned, which is self-evident.

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 ("Replace and publish") and a specific resource (the "App Privacy" declaration / privacy nutrition label). No sibling tool does anything comparable, so an agent can route here unambiguously from the name plus description alone.

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 of the `usages` payload is explained in detail, and "Replace and publish" implies the update context, but there is no explicit statement of when to call this (e.g. before submission, when data practices change) or any prerequisite such as an existing app version/declaration to replace.

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 no annotations, the description carries the full burden and does so reasonably: it discloses that this is an external mutation, that it uses the console's internal API because the public one returns 409, that it runs in the dedicated Chrome session, and that EU inclusion requires a trader declaration. It still omits whether existing territories are overwritten or merged, which matters for a mutation.

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 core action is front-loaded in the first clause and the supporting caveats are compact. Formatting is slightly awkward with the parenthetical example and line breaks, but there is little wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. Still, for a 3-parameter mutation tool with zero schema documentation and no annotations, the description should explain available_in_new_territories and the overwrite semantics; it covers the environment and EU prerequisite but not those 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 0%, so the description must compensate. It does explain territories as 3-letter ISO codes with an example (["BRA"]), but app_id is left implicit and available_in_new_territories — a non-obvious boolean — is never explained, leaving a meaningful gap.

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+resource — choosing the countries where the app is available — which is clear and concrete. However, it does not distinguish itself from the close sibling apple_set_subscription_availability, so an agent must infer the app-vs-subscription scope from the name alone.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no naming of alternatives. The only contextual note is a prerequisite (EU availability requires the DSA trader declaration), which is a constraint rather than a routing rule.

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 no annotations provided, the description carries the full burden. 'External action' vaguely signals a remote mutation, and 'price 0 in the base territory' implies the change is scoped, but there is no disclosure of permissions required, reversibility, whether existing purchasers are affected, or how other territories are handled.

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 fragments, front-loaded with the action and no filler. It is appropriately sized, though the trailing 'External action.' reads as a cryptic note that could be clearer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. For a mutation tool with no annotations and zero parameter documentation, however, the description omits prerequisites and side effects that an agent would need before invoking it.

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

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

Schema description coverage is 0%, so the description must compensate. It only gestures at 'base territory' (the base_territory param, default BRA) and says nothing about its accepted format or values, and never explains app_id. This leaves both parameters effectively undocumented.

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: making the app free at price 0 in the base territory, which is unambiguous and distinct from the sibling 'apple_set_subscription_price' (subscriptions vs. app price). It stops short of explicitly differentiating itself from that sibling, but the action is clear.

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 guidance, no mention of prerequisites (e.g., paid-app agreements, build state), and no routing to alternatives. The agent gets a bare action statement with no context on when this is the right call versus other pricing operations.

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 no annotations, the description carries the full burden and does well: it declares "External action" (a remote mutation), discloses partial-update semantics ("Only the fields passed are changed"), and reveals a hidden side effect ("Passing demo_account_name turns on demoAccountRequired automatically"). It stops short of stating auth/permission requirements or reversibility.

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 and the key constraint (partial update) are front-loaded. The subscription-app rationale is somewhat digressive but genuinely instructive, so it earns most of its space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. The description covers the mutation's key behavioral traits and the demo-account workflow, though the unexplained contact/notes parameters and unstated auth requirements leave modest 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 coverage is 0% across 8 params, so the description must compensate. It explains the demo_account fields' purpose and the demoAccountRequired side effect well, but says nothing about notes, contact_email, contact_phone, or contact_first/last_name semantics, leaving half the surface undocumented.

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: filling in App Review contact/demo-account details before testing. An agent can tell it apart from listing or submission siblings like apple_review_details and apple_submit_for_review, though it never explicitly names those 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?

Provides conditional context ("when the app has content behind a login" the demo account must reach the purchase flow), which is genuine usage guidance. However, there is no explicit when-to-use-this-vs-alternatives statement, e.g. versus apple_set_app_info or apple_review_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?

No annotations are provided, so the description carries the full burden. It usefully discloses the downstream state consequence (MISSING_METADATA blocking review) and the default territory (BRA only), but omits reversibility, whether existing territories are replaced or merged, and the permission/'external action' implications. Partial coverage for a mutation 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 short, front-loaded sentences with no waste: the action first, then the consequence and default. Every sentence earns its place, though it 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?

Output schema exists, so return values need no explanation, and the consequence of skipping this tool is well covered. The significant remaining gap is parameter semantics (0% schema coverage) for a three-parameter mutation with no annotations.

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

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

Schema description coverage is 0% across three parameters. The description only touches the default for territories ('Brazil only (BRA)'); it never explains the format of territory codes, the meaning of subscription_id, or what available_in_new_territories controls. With no schema help, the description fails to compensate.

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 countries where the subscription is sold.' The 'subscription' scope distinguishes it from apple_set_availability (app-level), though it does not name that sibling explicitly. Clear enough to act on 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 description gives a strong prerequisite condition ('Without this the product stays in MISSING_METADATA and cannot go to review') and flags it as an external action, which implies required authorization. However, it never contrasts this with alternatives such as apple_set_availability or apple_set_subscription_price, nor states when-not to use it.

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 no annotations, the description carries the full burden and does well: it discloses the external side effect, the ordering dependency on availability, per-territory issuance, and the concrete 409 failure mode with Apple's error text when the attribute is sent on an initial price. It stops short of auth/permission requirements and whether the change takes effect immediately or at a renewal boundary.

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, then prerequisites, then the parameter caveat; each sentence carries real information. The 'External action.' fragment is terse but useful. Slightly dense, but nothing is 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 3-param mutation tool with an output schema, the description supplies the ordering prerequisite, parameter semantics, and the failure mode an agent will actually hit. The only gap is authentication/permission context, which is minor given the output schema covers the response.

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 0%, so the description must compensate, and it does for the two non-obvious parameters: the origin of price_point_id and the full semantics of preserve_current_price (only valid on a price change, None default omits the field entirely, 409 otherwise). subscription_id is left unexplained but is self-evident.

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 subscription price from a price point') and flags it as an external action. It names apple_list_price_points as the source of price_point_id, letting an agent distinguish it from siblings like apple_list_price_points or apple_set_free_price without opening a 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 routes the agent: fetch price_point_id from apple_list_price_points and call it AFTER setting availability, since price points are issued per territory. It also states when preserve_current_price should and should not be sent. No meaningful usage condition 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 no annotations, the description carries the burden. It discloses that this is an 'External action' and explains the App Store state-machine constraint (Apple refuses to create a new version while a slot is occupied), which is genuinely useful. However, it says nothing about permissions required, whether the rename is reversible, or the effect on the version's current state beyond the listing.

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 core operation is front-loaded, immediately followed by the behavioral tag 'External action' and then the rationale. The use-case sentence is somewhat long but each part earns its place by explaining the constraint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be described, and the why/when is covered. But for a mutation tool with zero annotations and zero parameter documentation, the description omits prerequisites (obtaining version_id, permission needs) that an agent would want.

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 0%, so the description must document both parameters. It partially clarifies version_string by implying it should be the new build's version number, but version_id is never explained (e.g. where to obtain it, presumably from apple_list_versions). Half the parameters remain undocumented.

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 opening 'Rename an editable version' states a specific verb (rename) and resource (version), and the constraint about the slot being occupied distinguishes it from apple_create_version. It is clear, though it never names the sibling tools it must be distinguished from.

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 concrete when-to-use scenario: reusing a REJECTED version that blocks creation of a new one. This tells the agent the triggering condition well, but it does not explicitly route away from alternatives such as apple_create_version in the normal case.

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 no annotations provided, the description carries the full burden and does well: it flags the call as an external action that is 'hard to reverse' and mandates user confirmation. It omits auth/permission requirements and failure behavior, but the irreversibility and prerequisite disclosures are the most valuable behavioral facts here.

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, all front-loaded with the action first and the caveat and prerequisites immediately after. Every sentence 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?

An output schema exists, so return values need no explanation, and the description covers prerequisites and the confirmation gate for a high-stakes mutation. For an annotation-free irreversible action, slightly more on permissions or post-call state would be ideal, but it is largely 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 0% and the single parameter (version_id) is undocumented, so the description must compensate. It implies that the identifier refers to a version with an attached build, but adds no format, source, or lookup guidance for obtaining a valid version_id.

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 a version for Apple review'), so the action is unambiguous. It does not explicitly differentiate itself from the sibling apple_resubmit_for_review or play_submit_for_review, so the agent must infer the distinction, but the core purpose is clear.

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 actionable preconditions ('version to already have a build attached and complete metadata') and a confirmation requirement before calling. It stops short of naming alternatives such as apple_resubmit_for_review or stating when resubmission is preferred over a first submission.

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 no annotations, the description carries the full burden and does well: it flags 'External action', discloses the side effect that a group is created if `group_name` doesn't exist, and states the team-membership prerequisite. It omits auth/permission requirements and reversibility (how to revoke an invite), 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 sentences, purpose front-loaded, with the prerequisite and group-creation behavior following. No filler, though the parenthetical aside is slightly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained. For a side-effecting mutation with no annotations, the description covers the prerequisite, the create-if-missing behavior, and the external-action nature, leaving only permission/reversibility details unstated.

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 0%, so the description must compensate. It clarifies the most non-obvious parameter (`group_name` auto-creates a group with that name) and implies email is the invitee, but app_id, first_name, and last_name are left entirely undocumented.

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 ('internal TestFlight'), and clarifies what an internal group means (a group that receives every build). No sibling tool covers TestFlight invites, so it is cleanly distinguishable.

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 prerequisite (the invitee must already be a team user in App Store Connect, check Users and Access) and notes that internal testing skips review. It provides context for when this applies but names no explicit alternative tool or exclusion conditions.

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 no annotations, the description carries the full disclosure burden. It does disclose the important partial-update semantic ('Only the fields passed are changed'), which tells the agent omitted fields are preserved rather than nulled. However it says nothing about permissions, whether changes trigger review/resubmission, or reversibility for a mutation 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 short sentences, front-loaded with the core action and the partial-update rule, with zero filler. 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?

An output schema exists so return values need not be described, and the partial-update rule plus the whats_new caveat are the most important behavioral facts. Still, for a 6-parameter mutation tool with no annotations and 0% schema coverage, the absence of locale-default and per-field guidance leaves the definition under-specified.

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

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

Schema description coverage is 0% across 6 parameters, so the description is the only source of parameter meaning, and it only explains whats_new. keywords, description, promotional_text, and especially locale (which has an unusual default of pt-BR) are left entirely undocumented.

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 (Update) and resource (store listing texts of a version) with a scope qualifier (for one locale). It is distinguishable from the platform-mirror sibling play_update_listing mainly by the apple_ naming prefix rather than by anything in the description.

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 vs when-not guidance and no mention of prerequisites (auth, version state). The one usage constraint given, that whats_new cannot be used on an app's first version, is genuinely useful but is field-specific rather than a routing rule.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that build processing is asynchronous ('takes a few minutes') and how to track it. However it says nothing about required credentials/auth for xcrun altool, overwrite/replace behavior, or failure modes, which are material for an upload mutation.

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 action front-loaded and the async caveat plus platform values appended. 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?

An output schema exists, so return values need not be explained, and the description covers the key async behavior and the tracking tool. The main gap is the absence of any authentication or prerequisite context for an upload operation, which is a moderate omission rather than a fatal one.

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 0% and no enums are declared, so the description must compensate. It does enumerate valid platform values (ios, osx, appletvos), which is genuinely additive over the schema's bare string. It adds nothing about ipa_path format, but the required parameter is self-describing from its name.

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 ('Upload an .ipa to App Store Connect') plus the mechanism ('via xcrun altool'), so the agent knows exactly what action is performed. It does not explicitly distinguish itself from sibling upload tools such as play_upload_bundle, but the App Store target makes the scope 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 implied (upload after building an iOS/tvOS/macOS artifact) and it points to apple_list_builds as the follow-up tool for tracking processing. There is no explicit when-to-use-vs-alternative guidance or prerequisite statement, so it stays at minimum-viable.

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 no annotations the description carries the full burden, and it delivers the non-obvious traits: it uploads every image in the folder in alphabetical order, pins that order in the store, and that order otherwise falls back to unguaranteed creation order. It omits permissions/auth requirements and partial-failure behavior, which keeps it from 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?

Four short paragraphs, each earning its place (ordering rule, naming convention, version lifecycle, display_type values), and the core action is front-loaded. The standalone 'External action.' line is the only slightly wasteful element.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be described. For a mutating external tool with 5 params and no annotations, the description covers ordering, naming, version state, and replace behavior; missing auth/error context 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 coverage is 0%, so the description must compensate. It explains folder (all images inside), replace ('swaps them for these'), and display_type (listing valid values despite no enum in the schema), plus version_id implicitly via the VERSION paragraph. Only locale is left undocumented.

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 ('Upload the App Store listing screenshots, in order') and flags that it is an external action. This clearly separates it from the sibling play_upload_screenshots (different store) and from apple_create_version / apple_attach_build.

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 explicit conditions and exclusions: a READY_FOR_SALE version cannot be changed, so create the next one with apple_create_version (named sibling). It also explains the replace semantics and the file-naming requirement, covering when and how to use the 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?

With no annotations, the description carries the full burden and does well: it flags the call as an 'External action' and describes the three-step reserve/send/commit mechanism, which tells the agent this is a multi-stage mutation against App Store Connect. It omits permissions/auth requirements, file-size or format limits, and retry/idempotency 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?

Front-loaded with the core action, then requirement rationale, then mechanics. Sentences are dense but each adds meaning; the three-step upload sentence is arguably more than needed for an agent that just supplies two params, keeping it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers purpose, precondition, and mutation mechanics. The remaining gap is parameter-level detail (especially image format/path expectations), which is the one thing an agent cannot infer.

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

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

Schema description coverage is 0% and the schema offers no descriptions, so the description must compensate — but it never mentions subscription_id or image_path. The only hint about image_path is the implied 'screenshot' requirement, with no format, size, or path-type detail. Two required, fully undocumented parameters hold this down.

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 ('Upload a subscription's App Review screenshot'), and the scope is narrow enough to separate it from the plural apple_upload_screenshots sibling. It does not explicitly name that sibling, so it falls 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?

Explains the triggering condition clearly: without this screenshot the subscription stays in MISSING_METADATA and cannot be submitted. It also gives a concrete selection hint (use the screen where the subscription is offered, not the home screen). No exclusions or alternative-tool routing, so not a 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?

With no annotations, the description carries the full disclosure burden. It usefully notes the build must be 'finished' (a precondition), but says nothing about auth/permissions, whether an existing file at destination is overwritten, retry behavior, or download size/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?

Two sentences, front-loaded with the core action and followed by routing context. Every sentence 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?

An output schema exists so return values need not be described, and the workflow role is covered. However, for a three-parameter tool with no annotations and no schema descriptions, the absence of any parameter or operational detail (auth, destination overwrite) leaves 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 0% for three required parameters. The text implies build_id ('finished EAS build') and destination ('to a local path') loosely, but project_path is never explained and no parameter is given format or semantics beyond what the names suggest.

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 (Download) and resource (the binary of a finished EAS build) and the target (a local path). It is clearly distinguishable from the sibling EAS tools eas_build_list, eas_build_start, and eas_build_status, which do not download artifacts.

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 second sentence explicitly places the tool in a workflow—download the artifact then pass the path to apple_upload_build or play_upload_bundle—which tells the agent when this tool is the right step. It omits any exclusion conditions (e.g., what to do if the build is not yet finished) but the context is strong.

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?

No annotations, so the description carries full burden. It usefully explains how to interpret the result (a present artifact_url means it can be published directly) and enumerates status values, but says nothing about auth, rate limits, or whether listing has side effects.

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 its decision rationale, then parameter hints. Tight and low-waste, with only a minor dangling parameter line.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return format need not be explained, and the description covers the key interpretation (artifact_url). Given 0% schema coverage, the missing `limit` semantics is the only real 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 0%, so the description must compensate. It documents platform (ios or android) and status (finished, in-queue, in-progress, errored) well, but leaves `limit` and `project_path` unexplained; half the parameters remain undocumented.

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 an Expo project's EAS builds, with the artifact URL.' An agent can distinguish this from eas_build_start and eas_build_status by the listing/read nature, though no sibling is named 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?

'Use this to find out whether a ready binary already exists before spending a new build' gives a clear when-to-use with a rationale. It lacks explicit exclusions or naming of alternatives like eas_build_status or eas_build_download, so it stops short of a 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?

With no annotations, the description carries the behavioral burden and does well: it states the call is non-blocking ('does NOT block'), gives the expected 10-40 minute duration, and names the artifact needed to continue (build_id). It omits prerequisites such as authentication/credentials and that a build is a costly, side-effecting operation that is not trivially reversible.

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 its non-blocking nature, followed by just enough follow-up (duration, status hand-off) and one line of parameter hints. No filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still usefully points to build_id as the tracking handle. For a mutating, long-running tool with no annotations, the only meaningful omission is auth/credential prerequisites.

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 0% and there are no enums, so the description must compensate, and it largely does: it enumerates valid platform values (ios, android, all) and defines profile as a profile from eas.json. project_path is left undocumented, which is the one remaining gap for a required 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?

States a specific verb and resource ('Start an EAS build') plus the key behavioral fact that it returns immediately. An agent can distinguish it from eas_build_list, eas_build_status and eas_build_download without opening a 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 routes the agent: after starting, track progress with eas_build_status using the returned build_id. This is a clear hand-off to the correct sibling, though it gives no guidance on when a build should be initiated vs. other lifecycle steps (e.g., eas_submit).

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 no annotations, the description carries the full behavioral burden. It adds a genuine semantic about the return state (FINISHED + artifact_url = publishable), which is valuable, but it omits whether the call is read-only, what happens on an unknown/in-progress build id, and any auth or project-scoping 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?

Two short sentences, front-loaded with the core action and followed by the one piece of interpretive guidance that matters. 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?

An output schema exists, so return structure needn't be documented, and the description still calls out the key status semantics. For a simple two-param read tool this is nearly sufficient; only the undocumented parameters and lack of explicit sibling routing hold it back.

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

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

Schema description coverage is 0% for two required parameters. 'By id' loosely implies build_id, but project_path is nowhere explained, and neither parameter receives any format or expected-value guidance. The description does not compensate for the coverage gap.

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 the state of an EAS build by id,' which clearly separates it from eas_build_list, eas_build_start, and eas_build_download. It doesn't explicitly name sibling alternatives, so it falls short of the top band, but an agent can identify its role immediately.

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 second sentence gives useful decision context — a FINISHED status with artifact_url set signals readiness to publish — implying this tool precedes a submit/publish step. However, it never says when to call this versus eas_build_list (which presumably also surfaces builds) or what prerequisites exist, leaving usage largely inferred.

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 no annotations to lean on, the description carries the full burden and does so well: it flags the irreversible external publish action, the confirmation requirement, the iOS auth constraint (server key, no API key without a prompt), the altool upload path, and the fallback to the latest finished build.

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 the publish warning, then adds platform-specific detail. Every sentence carries information, though the iOS/Android split could be tightened slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and the description covers the risk, prerequisites, defaults and platform quirks an agent needs before firing an irreversible submission. Complete for this tool's complexity.

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 0%, so the description must compensate, and it explains three of four params meaningfully: profile (the submit profile in eas.json), platform (with platform-specific behavior), and build_id (defaults to the most recent finished build). Only project_path is left to inference, which is low risk.

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 to the store) and scopes it to the EAS submit profile in eas.json. It is clearly distinguishable from siblings like eas_build_start or eas_build_download, which prepare or fetch builds rather than publishing.

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 and an explicit gate: it really publishes, so the agent should confirm the profile and platform with the user first, and notes what happens without build_id (most recent finished build). It stops short of naming alternative tools or when-not-to-use conditions.

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?

No annotations are provided, so the description carries the full burden. It discloses that these fields are API-covered (preventing a wasteful console-automation detour), which is real behavioral value, but it says nothing about auth requirements, rate limits, or whether the listing must exist/is published. Read-only nature is only implied by 'Read'.

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, zero filler. The second sentence is somewhat tangential but earns its place by preventing a wrong approach.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is unnecessary, and this is a simple one-parameter read. The description covers purpose and the API-vs-console caveat; the only real omission is guidance on the package_name parameter.

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 single parameter package_name has 0% schema description coverage, and the description only indirectly refers to 'the app's Play listing' without defining the package name format or where to obtain it. The description does not compensate for the documentation gap.

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: 'Read the public contact details of the app's Play listing,' and even enumerates the three returned fields. The read/set distinction from the sibling play_set_contact_details is inferable from the verb, though the sibling is never named outright.

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 second sentence gives a when-not-to-use rule ('do not automate the console form for them'), which is genuinely useful routing guidance. However, it addresses a browser-automation fallback rather than competing sibling tools, and there is no stated precondition or pointer to play_set_contact_details for the write path.

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?

No annotations, so description carries full burden. It discloses a critical behavioral quirk: Material input offset causing center clicks to fail, and that the tool tries multiple offsets and only reports success via accessibility tree confirmation. This is exactly the kind of implementation detail 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?

Front-loaded with the core action, followed by essential behavioral context, then parameter definitions. Every sentence serves a purpose; no fluff.

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?

Output schema exists, so return values needn't be explained. However, with no annotations and 0% schema coverage, the description leaves gaps: 'package_name' and 'save_after' are unexplained, and the prerequisite of an open declaration (and likely an active browser session) is only implied.

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

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

Schema description coverage is 0%, so description must compensate. It defines 'option' (pt-BR label, e.g. 'Não') and 'nth' (occurrence index for duplicates) well, but omits 'package_name' and especially 'save_after', leaving half the parameters without added meaning.

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 action: select an option by its text in the open declaration and confirm it took effect. It distinguishes from siblings like play_content_options (list) and play_content_save (save) by focusing on selection and verification, though it doesn't name alternatives 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 usage context ('open declaration') but does not explicitly state prerequisites such as calling play_content_open first, nor when to prefer this over play_content_options or play_content_save. The parameter guidance helps but usage guidance remains 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?

No annotations, so the description carries the full burden. It usefully discloses that a browser is opened, that text is returned, and that URL slug mapping is already resolved (removing a real source of agent error). However it says nothing about auth/session requirements (a store_browser_session sibling exists), rate limits, or side effects.

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 action and purpose, followed by the slug caveat and the valid-value list. Every sentence earns its place, though it is slightly sprawling with three distinct ideas.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no expansion; the description's 'return its text' suffices. The form-value enumeration closes the biggest gap left by the schema. Missing auth/session context for a browser-opening tool is the notable remaining 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 0% and the form parameter has no enum, so the description must compensate. It does so by enumerating valid form values (privacy_policy, ads, app_access, government, financial, health, data_safety, content_rating) and clarifying that slugs differ from names. package_name remains unexplained, keeping this below a 5.

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: 'Open an App content declaration in the browser and return its text.' This is clearly distinct from siblings like play_content_answer or play_content_save. It does not explicitly contrast itself with play_content_options, but the role (open/read a declaration) is unmistakable.

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 clear context: 'Use it to see the questions and options before answering.' This implies it belongs earlier in the workflow than answer/save siblings. No explicit when-not guidance or named alternatives, so it falls short of a 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?

With no annotations provided, the description carries the burden and does add real behavioral context: it reads from the accessibility tree rather than the DOM, and warns that Angular Material controls are not reachable via querySelector. This is exactly the kind of implementation detail that prevents failed invocations. It stops short of stating permissions/rate limits or that the operation is non-mutating.

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, front-loaded with what is returned and then the two operational facts an agent needs. Nothing here is redundant with the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the tool carries the essential sequencing prerequisite and implementation caveat. The only meaningful omission is any explanation of package_name, which the schema leaves bare.

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

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

Schema description coverage is 0% for the single required parameter, package_name, and the description never mentions it or clarifies its format (e.g. app package identifier). The name is fairly self-explanatory in context, so this is a gap rather than a failure, but the description does not compensate for the undocumented 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 (controls/radios/checkboxes of the open declaration) plus what is returned (the state of each). This is clearly distinguishable from sibling read tools like play_content_status, although it doesn't explicitly name a sibling to differentiate itself.

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 an explicit prerequisite ordering instruction: 'Call play_content_open first.' That tells the agent when this tool is valid. It doesn't state what to do if no declaration is open or name alternative tools, so it falls short of a full when/when-not treatment.

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?

No annotations are provided, so the description carries the full disclosure burden. It usefully discloses that the tool saves and then dismisses a console dialog, but it omits permissions, failure behavior, and other mutation side effects.

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 front-loaded with the core action and then provides necessary button details without excess. It is appropriately sized, though the parameter detail is slightly fragmented.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained. However, given no annotations and 0% schema description coverage, the description should cover the required package_name parameter and better situate the tool among siblings, which it does not.

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

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

Schema description coverage is 0%, so the description must compensate. It does this well for the button parameter by listing exact pt-BR labels and their meanings, but it says nothing about the required package_name parameter, leaving a significant gap.

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: saving the open declaration and dismissing the subsequent dialog. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as play_content_answer or play_content_options.

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 only through 'the open declaration,' but gives no explicit when-to-use guidance or alternatives. The button options explain parameter choices within multi-step wizards, not when to select this tool over related Play Content 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?

With no annotations provided, the description carries the full burden and does disclose real behavior: it reports a count of outstanding declarations, the gating rule that a draft only publishes once all are complete, and the fact that the declarations are console-only with no API endpoint. It does not state whether this call is strictly read-only, whether it needs auth, or whether it is rate-limited, which keeps it below 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 short sentences, front-loaded with the outcome (how many declarations are missing) before the rationale. Every sentence adds information; only the terseness of the final dash clause slightly weakens readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value format needn't be explained, and the single-parameter surface is small. The description covers purpose, the publish-gating rule, and the console-only limitation, leaving only the parameter's meaning unaddressed.

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

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

Schema description coverage is 0% and the description says nothing about package_name — which app the count is scoped to, its format, or where to obtain it. With one required parameter undocumented in both schema and description, the description fails to compensate for the coverage gap.

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: counts missing "App content" declarations and frames it as a publish-readiness check. It is distinguishable from the fill-in siblings (play_content_open/answer/save) because it reports status rather than completing forms, though it never names a 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?

Clearly implies when to use it (checking whether a draft can leave draft state before publishing) and adds a genuine constraint — the declarations themselves have no API endpoint, so this is a read-only checkpoint rather than a completion path. No explicit 'use X instead' routing, so it stops short of a 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?

With no annotations, the description carries the burden and does well: it discloses that the tool opens a browser page rather than performing an API mutation, that it cannot itself create the app, and that it returns fill-in guidance. It omits prerequisites such as an authenticated console/browser session.

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, purpose front-loaded, with the rationale following immediately. Efficient overall, though the second sentence could be compressed without losing the constraint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and purpose/behavior are covered. However, with 0% parameter coverage and no annotations, the description leaves both required inputs and any auth/browser-session requirements undocumented, which is a real gap for a tool an agent must invoke with the right values.

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

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

Schema description coverage is 0% and the description never mentions package_name or suggested_name, so neither required parameter gains meaning beyond its bare name. The phrase 'returns what to fill in' hints at the output, not at what the inputs must contain.

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 ('Open the Play Console app list in the browser to create a new app') and explicitly frames it against the sibling Apple counterpart and the API-based alternatives by explaining the API cannot create a packageName. 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?

Explains clearly when this is the right path: initial app registration must go through the console because the Google Play Developer API cannot create the packageName. It does not name any alternative tool explicitly, but the context makes the boundary between this and the API tools 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?

With no annotations, the description carries full behavioral burden and does so well: it discloses that the download requires Browser.setDownloadBehavior (and that Page. does not work) and that the file arrives with a GUID name before being renamed. That is meaningful quirk information an agent could not get elsewhere. It stops short of covering auth needs, overwrite behavior at destination_dir, or failure modes.

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 with the core action front-loaded in the first line, followed by supporting context. The middle sentence is justificatory rather than instructional, but it is compact and earns its place by explaining the CSV advantage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the download quirks are well covered. However, for a 2-parameter tool at 0% schema coverage, the description leaves parameter semantics and prerequisite conditions unexplained, making it only minimally 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 0% for both params, so the description must compensate, but it never explains what package_name or destination_dir mean or their expected format. It mentions the renamed output file, which hints at destination_dir semantics, but leaves package_name entirely unexplained.

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 the Data safety declaration CSV template.' An agent can immediately tell this produces a CSV file. However, it never distinguishes itself from the closely related sibling tools play_data_safety_import and play_data_safety_fill, 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?

The description explains why the CSV path is preferable ('much faster and more reliable than clicking screen by screen'), which implies the intended workflow, but it never explicitly says when to use this versus play_data_safety_import or play_data_safety_fill. Usage must be inferred from the wizard context rather than stated as a routing rule.

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 no annotations, the description carries the burden and does valuable work: it discloses that this is a non-destructive generation step ("imports nothing"), that it emits a summary for human review, and that errors carry real production risk. Gaps remain around destination_path overwrite behavior and any auth/permission 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?

Front-loads purpose, then the import/risk warning, then the parameter example — a sensible priority order with no filler. The prose is slightly loose (paragraph breaks mid-sentence) 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?

An output schema exists so return-value detail is not needed, and the description still signals what it returns (a declaration summary). For a tool of this complexity the main omission is the undocumented scalar parameters, but the risk warning and the collected_data example cover the parts most likely to be misused.

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 0%, so the description must compensate. It does so well for collected_data — explaining the Response-ID key mapping and the {group, shared, optional, purposes} value shape with concrete PSL_* examples. However template_path, destination_path, supports_deletion, account_deletion_url and encrypted_in_transit remain undocumented in both schema and description, so the compensation is only partial.

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 ("Fill in the Data safety CSV and return a summary") and explicitly distinguishes itself from the sibling play_data_safety_import by declaring "Imports nothing — it generates the file for review." An agent can tell exactly what this tool produces 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 a clear workflow cue: review the summary with the user before calling play_data_safety_import, and warns that an incorrect declaration can take down a published app. It does not discuss play_data_safety_export (read vs generate), so the routing story is strong but not exhaustive.

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 no annotations provided, the description carries the full burden and does disclose the critical behavior: it is an external action that 'replaces the app's entire declaration' (destructive/irreversible-ish). It omits permission/auth requirements and does not describe failure modes, so it is strong but 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?

Two short sentences, zero filler, with the destructive external-action warning front-loaded right after the purpose statement. 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?

An output schema exists, so return values need not be explained, and the description supplies the crucial destructive-action warning and the sibling prerequisite. The remaining gap is parameter-level detail for a 0%-coverage schema and any auth/permission context.

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

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

Schema description coverage is 0%, so the schema says nothing beyond types. The description's 'filled-in CSV' implies csv_path points at the output of play_data_safety_fill, which adds modest meaning, but it says nothing about path format or package_name expectations, leaving the two required parameters mostly undocumented.

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: importing a filled-in CSV into the Data safety declaration, tied to a named sibling (play_data_safety_fill) that produces the input. An agent can distinguish this from play_data_safety_export and play_data_safety_fill immediately.

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 an explicit precondition ('Review the summary from play_data_safety_fill with the user before calling') and names the external-action consequence, which tells the agent when this step belongs in the workflow. It does not state any case where the tool should be avoided, so it falls short of full when/when-not coverage.

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?

No annotations are provided, so the description carries the full burden, and it does disclose useful behavior: read-only, deterministic ordering, and the sha256 return shape. It omits auth requirements, rate limits, pagination, and what happens for an unpublished or missing image type, so behavior is only partially covered.

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, front-loaded with purpose and read-only status, followed by the return detail. No filler, though the return explanation is partly redundant given the output schema exists.

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?

The output schema covers return values, so listing content is a bonus rather than a necessity. However, with 0% parameter coverage and no annotations, the definition leaves an agent without the argument semantics and safety/authorization context needed to call it confidently.

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

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

Schema description coverage is 0% across three parameters. The description loosely maps 'one listing image type' to image_type and 'listing' to package_name, but adds no format, enum values, or defaults, and says nothing about the language parameter. It fails to compensate for the coverage gap.

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 the published screenshots of one listing image type.' The verb 'list' plus the read-only framing clearly separates it from the write-side sibling play_upload_screenshots, 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?

Usage is implied rather than stated: 'compare them with local files to confirm what is published' hints at a verification workflow, but there is no explicit when-to-use/when-not guidance or reference to alternatives like play_content_status or play_upload_screenshots.

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 no annotations provided, the description carries the full burden and does well: it flags that this is an external action, that promoting to production publishes the app, and that user confirmation is required. It omits permissions/auth requirements, reversibility of a promotion, and what happens to prior releases on the target track, which keeps it from 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 short sentences, front-loaded with what the tool does, then the safety-critical warning, then the optional rollout pattern. No filler; 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?

An output schema exists, so return values need not be described. The description covers the core action, the high-stakes production side effect, and the staged-rollout pattern — enough for a safe call. The remaining gap is the undocumented non-rollout parameters.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate. It explains status=inProgress and semantics of user_fraction (0.1 = 10%), but track, package_name, version_code, and release_notes_pt_br are left without any added meaning beyond their names and types.

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 (promote), resource (an already uploaded versionCode), and destination (another track), plus the key differentiator from the upload siblings: 'without a new upload.' An agent can immediately distinguish this from play_upload_bundle and eas_submit.

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 when-to-use context (promoting an existing build rather than uploading) and routes staged-rollout users to status=inProgress with user_fraction. It does not name a sibling as an explicit alternative nor state when not to use it, so it stops short of a 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?

With no annotations, the description carries the full burden and does disclose key traits: the change is an external, user-visible action and is committed to the listing. It adds a correctness check (verify ownership) that goes beyond structured data, though it omits what null values do and whether authentication/authorization is 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 tight sentences, front-loaded with the action and its commit semantics, then the external-visibility caveat. 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?

An output schema exists so return values need not be explained, and the external/commit semantics are covered. The remaining gap is the semantics of nullable parameters (does passing null clear a field?), which neither the description nor the schema resolves.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate. It names only two of the four fields (e-mail and website) and omits package_name and contact_phone, and gives no format or null-means-clear semantics, so it only partially fills the gap.

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 (Update) and resource (public contact details of the Play listing) and adds the commit semantic, which distinguishes it from the read-only sibling play_contact_details. An agent can tell it apart from play_update_listing and play_contact_details without opening a 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 a clear context (publishing-facing details shown on Google Play) and names a verification alternative, store_audit_identity, for confirming the publishing entity. It does not state explicit when-not-to-use conditions or prerequisites, but the routing hint is concrete.

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 no annotations, the description carries the full burden and does well: it discloses the Google re-signing behavior, the source artifact (deployment_cert.der), and that the visible UI value is the wrong key. It does not cover auth requirements or what happens if package_name is invalid, 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?

Front-loaded with the core action, then the diagnostic scenario, then the caveat. Every sentence adds real value, though the symptom narrative is a bit long relative to the two-parameter operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be spelled out, yet the description still explains the SHA-1 payload. The main gap is the unknown parameter semantics and the file side-effect of writing to download_dir, which matters for an unannotated 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?

Schema coverage is 0%, so the description must compensate. It implies purpose for both parameters (package_name identifies the app, download_dir receives the downloaded certs) but never specifies format, path semantics, or whether download_dir must exist. Adequate but incomplete.

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 (download), resource (Play's app signing certificates), and output (SHA-1 of each). It is clearly distinguishable from unrelated siblings like store_audit_identity or apple_register_bundle_id, and even clarifies which certificate is involved (deployment_cert.der).

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 an explicit trigger scenario ('Sign in with Google' works locally but fails with the store APK, account picker loops with no error) and explicitly warns against using the wrong value (the upload key's SHA-1 on the App signing page). It also names where the output is consumed (Android OAuth client in Google Cloud Console).

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 no annotations, the description must carry the behavioral load; it does disclose that this is a read of the 'Publishing overview' page (hence non-mutating) and that the terminology is ambiguous, which is genuinely useful. It says nothing about auth requirements, failure modes, or what happens if the package is unknown.

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 answer 'what does this report', followed by a short disambiguation of the two confusing status strings. Two tight paragraphs, no filler; the quoted phrasing earns its place by mapping UI text to state meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return format need not be explained, and the description supplies the one thing the schema cannot: what 'in review' vs 'waiting to be sent' actually mean. Only the undocumented package_name parameter keeps this from being 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 0% and the description never mentions package_name or what form it takes (bundle ID, app ID, etc.). For a single required identifier this is a real gap the description should have filled.

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 reporting verb and the resource (pending submission state) and enumerates the three possible outcomes, so an agent knows exactly what question this tool answers. It does not explicitly distinguish itself from near-neighbours like play_content_status or play_track_status, which keeps it just 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 implied by the description (check whether changes are waiting, in review, or done), but there is no explicit 'call this when X, use play_content_status when Y' guidance despite several overlapping siblings. The state disambiguation helps interpretation rather than selection.

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