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 states the intended outcome but does not disclose whether attaching a build replaces an existing one, whether the version must be in a particular state, or whether the operation is reversible. These are significant gaps 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?

A single sentence that front-loads the action, adds the key eligibility qualifier, and states the intended outcome. There is no repetition or filler.

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

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

For a simple two-parameter attach operation with an output schema present, the description provides adequate purpose and parameter clarity. It is incomplete on side effects, preconditions, and behavior when re-attaching a build, so an agent may not fully understand the operational consequences.

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%, but the description compensates by mapping build_id to a 'processed TestFlight build' and version_id to an 'App Store version.' It does not explain how to find these IDs or what formats are accepted, but the description makes both required parameters semantically meaningful.

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

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

The description names a specific action (attach), a specific resource (a processed TestFlight build), and a target resource (an App Store version). This clearly distinguishes the tool from siblings like create_app_store_version and submit_for_review, and the 'processed' qualification narrows which builds are relevant.

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 clear context for when this tool is used: when a build is processed and the version needs to be ready for submission. It does not explicitly name alternatives or exclusions, such as not using it after review has already started, but the intended workflow position is reasonably 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, but it only states the creation action and the existing-app prerequisite. It does not disclose side effects, duplicate-version behavior, validation rules, permissions, or what state the new version is created in.

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, tightly written sentence with no filler. The core purpose and key exclusion are front-loaded, so an agent can quickly grasp the tool's function.

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 exists, so return-value details are not required from the description. However, the description omits parameter semantics, platform options, and workflow context, leaving the agent to infer important details from the schema and sibling names.

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 only clarifies that app_id refers to an existing app record. It does not explain version_string format, acceptable platform values, or any constraints on the parameters beyond the schema's type/default information.

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 ('Create a new App Store version') on a specific resource ('EXISTING app record') and explicitly clarifies what it does not do ('does not create the app itself'). This clearly distinguishes it from any app-creation tool without needing to inspect 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?

The description implies the tool should be used when an app record already exists and a new version needs to be created. However, it does not explicitly mention alternatives, when not to use it, or workflow steps like attaching a build or submitting for review.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully states that a missing app returns None, which is a key branch for an agent to handle. 'Look up' implies a read-only operation, though it does not explicitly address auth or rate limits.

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

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

One tight sentence that front-loads the action and lookup key, then appends the important None-on-miss behavior. No filler or redundant restating of the tool's name.

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

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

For a one-parameter read tool with an output schema present, this is largely complete: it says what it does and what it returns on a missing app. It is only slightly incomplete in not explaining when it should be preferred over sibling lookup/list tools.

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

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

The schema only provides a property name and type (bundle_id: string) with 0% coverage. The description adds the critical format example com.example.app, which clarifies the expected value well enough for a single simple parameter.

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

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

The description states a specific verb ('Look up'), a resource ('app'), and the lookup key ('bundle identifier'), with an example format. This distinguishes it from get_app and list_apps reasonably well, though it does not explicitly name sibling alternatives.

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

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

No guidance is provided about when to use this tool over list_bundle_ids, get_app, or list_apps. An agent must infer that having a bundle ID is the trigger, and there are no exclusions, prerequisites, or fallback hints.

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. 'Fetch' implies a read-only operation, but it does not explicitly state that it is non-destructive, require any specific permissions, or mention rate limits. The absence of side-effect warnings is acceptable for a simple GET, but a more explicit statement about read-only nature would strengthen transparency. It is adequate but not explicit.

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 a single sentence that is front-loaded with the core action ('Fetch one app's full attributes') and immediately clarifies the key parameter. There is zero redundancy or unnecessary detail, making it highly 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?

For a simple single-parameter read operation with an output schema provided, the description is complete. It specifies what is fetched and by what identifier. No additional behavioral context (like pagination or filters) is needed, as this is a targeted fetch. The presence of an output schema covers return-value documentation.

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%, but the description explains that app_id is the App Store Connect app id, which gives meaningful context beyond the bare schema definition (type: string). Since there is only one parameter and the description clarifies its role, it compensates well for the lack of schema-level documentation. However, it does not specify format constraints (e.g., numeric vs alphanumeric), so a small gap remains.

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 clearly states the verb 'Fetch', the resource 'one app's full attributes', and the identifier 'App Store Connect app id'. This differentiates it from sibling tools like list_apps (which lists many) and find_app_by_bundle_id (which uses a different identifier). No ambiguity remains about what this tool does.

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 when you have a specific App Store Connect app id and need the full attribute set, but it does not explicitly mention when not to use it or point to alternatives. There is no direct guidance on choosing between this and find_app_by_bundle_id, though the identifier difference is implied. It is adequate but relies on the agent to infer context.

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?

There are no annotations, so the description must communicate the operation's behavior. 'Fetch' signals a read operation, which is useful, but it does not disclose failure modes, authorization requirements, or other behavioral details. The description is not misleading, just light on context.

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

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

A single, front-loaded sentence with no filler. It states the action, the resource, and a meaningful included attribute, which is appropriately sized for a one-parameter fetch tool.

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

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

For a simple one-parameter read operation with an output schema available, the description is nearly sufficient. It does not explain where version_id originates, but the low complexity and strong sibling naming make that omission minor.

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

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

With 0% schema description coverage, the description should compensate for the parameter, but it only loosely ties version_id to 'one App Store version'. The schema title 'Version Id' already conveys the core meaning, so the description adds modest but not substantial 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?

The description uses a specific verb, 'Fetch', with a concrete resource, 'one App Store version's full attributes', and highlights a distinguishing attribute, appStoreState. This clearly separates it from list_app_store_versions and create_app_store_version.

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

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

The description implies this is the tool for retrieving a single version's full data rather than listing all versions, but it never explicitly contrasts with list_app_store_versions or states when to prefer this over that sibling. The usage guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the scope ('visible to this API key') and the returned fields, which is useful. However, it does not mention potential pagination, ordering, or rate limits, which are common for list operations. The read-only nature is implied but not explicit.

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

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

A single, compact sentence that conveys the essential information—action, scope, and return fields—with zero wasted words. It is front-loaded and directly usable by an agent.

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 zero parameters and the presence of an output schema (which defines the return structure), the description covers the core purpose and scope. The only gap is the lack of explicit mention of pagination or response format, but these are likely minor for a simple listing tool and are partially covered by the output schema.

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

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

The tool has zero parameters, so per the rubric the baseline is 4. There is nothing to describe beyond what the (empty) schema already provides, so the description does not need to compensate for any undocumented parameters.

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 clearly states the action (List), the resource (apps), and the exact fields returned (id, bundle id, name, sku). This differentiates it from siblings like get_app (single app) and find_app_by_bundle_id (search by bundle ID), making the purpose unambiguous even without explicit sibling references.

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 this is the general-purpose listing tool for all apps, but it does not explicitly state when to prefer it over alternatives like find_app_by_bundle_id or get_app. There is no mention of exclusions or context, though the tool's simplicity makes usage relatively obvious.

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 behavioral burden. It clearly frames the operation as a read-only listing and names the returned attributes, but it does not disclose ordering, pagination, or whether all App Store states are included. There is no contradiction with annotations.

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

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

One focused sentence that front-loads the verb and object, with a compact field list after the colon. Every part is useful and there is no filler.

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

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

For a single-parameter list tool with an output schema, a minimal description can be sufficient. However, the description omits how to obtain app_id, whether all versions are returned, and how this tool relates to get_app_store_version, making it adequate but not 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 description never names app_id. 'for an app' provides only a weak semantic link to the required parameter; no format, source, or meaning beyond the field name is given.

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 specific verb ('List') and resource ('App Store versions for an app'), and it names the returned fields. It does not explicitly differentiate from the sibling get_app_store_version, so it lacks full sibling distinction.

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

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

There is no guidance about when to use this tool versus get_app_store_version or create_app_store_version. The description only states the operation and gives no alternatives, exclusions, or prerequisites beyond the implicit app_id.

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 of behavioral disclosure. 'List' implies a read operation, but the description does not mention any behavior such as pagination, sorting, or what happens when no groups exist. It also does not clarify whether both internal and external groups are always returned or if there are any constraints on the app_id.

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 a single sentence with no filler or repetition, making it efficient and front-loaded. However, it is under-specified, which lowers the score slightly from 5 because conciseness is appropriate but at the expense of necessary details.

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 simplicity (one parameter, output schema exists), the description is reasonably complete for the core action, but it lacks context on prerequisites, edge cases, or any additional behavior beyond a basic listing. An agent might still call it correctly, but the missing usage guidance and parameter details reduce completeness.

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 the undocumented app_id parameter. It only says 'for an app,' which is vague and does not explain the format, source, or how to obtain a valid app_id. No additional meaning is added beyond the parameter name itself.

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 clearly states the action ('List') and the resource ('TestFlight beta groups'), with an explicit qualifier ('internal/external') and scope ('for an app'). It distinguishes this from siblings like list_beta_testers (testers vs groups) and list_builds (builds vs groups) without needing to open schemas.

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

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

The description implies usage (you need an app_id to list its groups) but does not provide explicit guidance on when to choose this tool over alternatives like list_beta_testers or list_builds. There is no mention of exclusions or alternative tools, so an agent must infer the appropriate context.

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. 'List' implies a read operation, but the description does not disclose pagination behavior, tester statuses (invited/accepted/etc.), authentication needs, or any other operational caveats.

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 a single, front-loaded sentence with no filler. Every word contributes meaning, and the action and scope are presented immediately.

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

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

For a simple one-parameter tool with an output schema, the description provides enough to invoke it correctly if the beta_group_id is already known. However, it lacks guidance on how to obtain the group ID via sibling tools and does not mention any behavioral edge cases that an agent should account for.

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 explain beta_group_id beyond what the parameter name and title already imply. It adds only the TestFlight context, but no format, source, or lookup guidance for the parameter.

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

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

The description states a specific verb ('List'), a clear resource ('testers'), and a scope ('in a TestFlight beta group'). It clearly differentiates from siblings like list_beta_groups, which lists groups rather than the testers within a group.

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

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

No guidance is given on when to use this tool versus alternatives, nor does it mention that list_beta_groups might be needed to first obtain a beta_group_id. The intended usage is only implied by the tool name and description.

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 is the sole source of behavioral information. It only mentions the output fields and does not disclose whether the operation is read-only, any permission requirements, pagination, or side effects. This is a significant gap for a tool with no 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?

The description is a single, concise sentence that is front-loaded with the action and resource. It is efficient with no unnecessary words, though it could potentially be structured to include usage guidance.

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 simplicity, the description covers the basic purpose and output fields, and an output schema exists to define return values. However, it lacks behavioral context such as read-only nature or any constraints, which is needed given the absence of 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?

The schema has one parameter, app_id, with 0% description coverage. The description does not explain the parameter beyond implying it identifies the app; it adds no details about format, how to obtain it, or relationships to other tools. The description fails to compensate for the schema's lack of 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?

The description clearly states the action (list), the resource (TestFlight builds), and the app scope, and enumerates the fields returned (version, build number, processing state). It distinguishes from sibling tools like list_app_store_versions by specifying TestFlight builds, though it does not explicitly name alternatives.

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 the use case—listing TestFlight builds for an app—but provides no explicit guidance on when to choose this over other list tools or any exclusions. There is no mention of alternatives or conditions, so usage is inferred rather than stated.

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

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

With no annotations, the description carries the disclosure burden. 'List' and the per-bundle 'whether used for an app' clarify that this is a read-only enumeration and indicate the output shape, but it does not mention pagination, limiting, auth requirements, or any edge-case behavior. For a zero-parameter read tool, this is adequate but not rich.

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

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

A single sentence that leads with the action and resource, then adds the distinguishing return detail. There is no filler or redundancy.

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

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

For a tool with zero parameters and an output schema, the description is complete: it states what is being enumerated and what each entry will tell the caller. The presence of an output schema means the return structure need not be repeated in the 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?

The input schema has no parameters and the description adds no parameter-level mechanics, but none are needed. Per the rubric, zero parameters set a baseline of 4.

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 specific verb ('List'), a precise resource ('registered Bundle IDs'), and a distinguishing output detail ('whether each is used for an app'). This clearly separates it from siblings like list_apps and find_app_by_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?

The description implies the tool's role by naming the operation, but it does not explicitly state when to choose it over alternatives such as find_app_by_bundle_id or list_apps. There is no 'if you need X use this' guidance or exclusion of sibling 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 behavioral disclosure burden. It clarifies the resource is signing certificates and scopes them to the account, and 'List' implies a read-only operation. It does not explicitly state authentication needs or guarantee non-mutation, but for a parameterless read tool this is acceptable minimal disclosure.

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 a single front-loaded sentence with the verb first, followed by the resource and the relevant data fields. Every word earns its place and there is no filler.

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

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

Given that the tool takes no parameters and an output schema exists to define return structure, the description is sufficiently complete for an agent to call it correctly. It identifies the resource, the account scope, and the key returned attributes.

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

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

The tool has zero parameters, so there are no parameter semantics for the description to add. The empty schema is trivially fully covered, matching the baseline for parameterless tools.

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 specific verb ('List') plus a clear resource ('signing certificates') and names the returned fields (type, name, expiry). This distinguishes it from sibling tools like list_profiles and list_bundle_ids by resource type.

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

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

No guidance is given about when to use this tool versus sibling list tools, particularly list_profiles, which is closely related in the signing domain. There are no stated exclusions, alternatives, or selection criteria.

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 present, so the description carries the full burden. 'List' implies a read-only enumeration, but the description does not explicitly state that it is non-mutating, nor does it mention pagination, scoping details, or any behavior beyond the basic 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 description is one clear sentence with the verb and object front-loaded. It contains no filler or repeated 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?

Given the tool has zero parameters and an output schema, the description is largely sufficient to select and invoke it. It lacks only some behavioral context (e.g., explicit read-only/pagination disclosure), but nothing about inputs or return shape 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?

There are zero parameters, so the schema already fully covers invocation needs. With no parameters, there is nothing meaningful for the description to add, matching the baseline of 4.

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 distinct resource ('provisioning profiles on the account'), which distinguishes it from siblings like list_certificates and list_bundle_ids. The intent is immediately clear without needing to inspect schemas.

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

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

Usage is implied by the description: use this when you need the set of provisioning profiles on the current account. However, it does not explicitly compare with sibling list tools or state when not to use it, so the guidance is only implicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly reveals that this is a consequential action that starts Apple's App Review and typically takes 24-48 hours. It does not mention irreversibility or status transitions, but it does disclose the key side effect.

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

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

The description is two sentences: the first states the action, and the second adds a necessary caution about consequences and preconditions. No filler or redundant information.

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

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

For a single-parameter tool with an output schema present, the description covers the essential aspects: what the tool does, its consequence, and preconditions. It could mention the version_id parameter explicitly or note the resulting version status, but the low complexity makes the description reasonably 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?

The schema has one parameter, version_id, with 0% description coverage. The description never explicitly names or explains version_id, only referring to 'the given version.' Because schema coverage is low, the description needed to compensate but does not add direct parameter guidance.

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

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

The description states a specific verb ('Submit'), a specific resource ('an App Store version'), and a clear purpose ('for Apple review'). This distinguishes it from sibling tools like attach_build_to_version and create_app_store_version, even without naming them.

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

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

It provides explicit preconditions: confirm a build is attached and all required metadata is complete before calling. This signals that the tool is the final submission step, though it does not explicitly name alternatives or say 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.