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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds value by disclosing the composite return payload (versions with review/release state, builds with processing state), which matters because no output schema exists. It omits freshness/rate-limit or auth context, so it is not 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?

A single front-loaded sentence that packs the aggregate scope into a compact colon-list with zero filler or restatement of the 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?

Without an output schema, the description does a decent job describing what comes back, which is the main need. However, the only input parameter is left completely ambiguous and there is no indication of scope limits (how many versions/builds) or behavior when the app has no recent builds, leaving gaps an agent must guess at.

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 parameter appId is undocumented in both schema and description; 'of an app' only weakly implies what appId is. The agent gets no guidance on whether appId is a numeric App Store Connect ID, a bundle ID, or something else, which is a real invocation 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 ('One-call status of an app') and enumerates exactly what is bundled: app details, latest App Store versions with review/release state, and recent builds with processing state. That scope implicitly separates it from single-purpose siblings like asc_list_apps or asc_list_builds, though it never names an alternative explicitly.

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

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

The phrase 'One-call status' implies the intended use case (a single snapshot instead of several list calls), but there is no explicit when-to-use, when-not-to-use, or named alternative among the many asc_list_* siblings. Usage is inferable rather than stated.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuinely non-redundant behavior — input validation against Apple's OpenAPI spec, response compaction that strips resource links, and the access-mode gating with an explanatory blocked-call path. It does not mention rate limits or failure/error semantics beyond the access-mode block, keeping this 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 and mechanism, then moves efficiently through query format, body format, response handling, and access requirements. The inline JSON examples are dense but each earns its place by removing ambiguity. Slightly heavy for a single paragraph, but no sentence is disposable.

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

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

There is no output schema, and the description compensates directly by explaining that responses are compacted, that nextUrl drives pagination, and that fetchAll or saveTo are the alternatives. Combined with the access-mode rules, an agent has everything needed to call this correctly and interpret what comes 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?

With 8 parameters at 75% schema coverage, the schema documents raw, saveTo, fetchAll, maxItems and pathParams, while the description supplies the syntax the schema cannot — Apple's exact query key names with worked examples and the JSON:API envelope shape for body. The relationship between fetchAll and nextUrl is clarified, though maxItems' interaction with fetchAll is only implied.

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 ("Execute any App Store Connect API operation by operationId") and makes the dispatch mechanism explicit up front. It names asc_fetch_url as the follow-up tool for nextUrl, but does not distinguish itself from the discovery siblings (asc_search_operations, asc_describe_operation), which an agent will most likely confuse it with.

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

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

Gives concrete conditions: creates and updates require the write access mode, deletes require full, and a blocked call explains how the user can enable them. It also routes pagination follow-up to asc_fetch_url. The implicit prerequisite — that you must already know the operationId, presumably via asc_search_operations — is left to inference rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context by stating exactly what the check reveals: API key validity, server mode (readonly/write/full), spec version, and rate-limit status.

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: the first states what the tool does and what it returns, the second gives usage guidance. No filler, and the primary purpose is front-loaded.

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

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

For a zero-parameter diagnostic tool with no output schema, the description fully covers what an agent needs: what the tool checks, what information it returns, and when to invoke 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?

The tool takes zero parameters, so the baseline is 4. The description correctly does not discuss parameter syntax, as there are none.

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 ('Verify') and resource ('API key') plus concrete outputs (server mode, spec version, rate-limit status). It is clearly distinguishable from all sibling tools, which are data-listing or operation-calling 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?

Explicitly says to run this first when setting up or when calls fail with auth errors, giving clear trigger conditions. It does not name alternatives or state when not to use it, but no alternative diagnostic tool exists among the siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds valuable behavioral context by detailing exactly what content is returned (params, sparse fieldsets, body schema), which matters because there is no output schema. It does not mention response format or whether results are cached, leaving a small gap.

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

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

Two sentences, both earning their place: the first enumerates the return payload, the second gives the routing instruction. Return content is front-loaded and the alternative tool is placed last.

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

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

For a discovery/describe tool with no output schema, the description adequately conveys what an agent will get back and when to call it. It stops just short of describing return shape or error behavior, but nothing essential for correct invocation is missing.

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

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

There is a single parameter with 100% schema description coverage, and the schema itself provides example operation IDs (apps_getCollection). The description adds no additional meaning about operationId beyond what the schema already conveys, so the baseline of 3 is correct.

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

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

Specific verb (describe/show) applied to a well-defined resource (one App Store Connect API operation), with an explicit enumeration of the payload: path params, query params, sparse fieldsets, and request-body schema. This clearly distinguishes it from the sibling asc_call_operation.

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 states when to use it ('Call this before asc_call_operation for any operation you haven't used yet'), naming both the companion tool and the condition that triggers use. No inference required.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds meaningful behavior beyond that by stating that results are returned as parsed rows and that WW is valid only with FINANCE_DETAIL while ZZ means consolidated.

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 efficient sentences. It front-loads the purpose and return format, then uses the second sentence for region-code semantics without wasting 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?

There is no output schema, and the description only says results are 'parsed rows' without describing columns. More importantly, required parameter vendorNumber has no description in the schema or the tool description, leaving an agent without guidance on a required input.

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 high (83%), so the baseline is 3. The description adds real meaning for regionCode beyond the schema's 'e.g. US, EU, ZZ, WW' by explaining WW's restriction to FINANCE_DETAIL and ZZ's consolidated 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 verb and resource: 'Download a monthly financial report (proceeds by region)' and adds the return format 'parsed rows'. It does not explicitly differentiate from the sibling asc_download_sales_report, 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?

There is no explicit when-to-use guidance, no mention of when not to use it, and no named alternative such as asc_download_sales_report. The financial-report scope implies its purpose, but no selection guidance is provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: the result is returned as 'parsed rows' rather than a raw file, and report data lags the reporting date by roughly a day. It says nothing about truncation behavior when row counts exceed the inline limit, which is the main operational risk 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 tight sentences with the core action front-loaded, followed by the two prerequisites. No filler, though the trailing availability note could have been folded into the first sentence for a slightly stronger opening.

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

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

With no output schema, the description does the right thing by stating the return shape ('parsed rows') and noting saveTo as a full-report escape hatch. For an 8-parameter, open-world read tool this is nearly sufficient; only the inline-row truncation semantics are left entirely to the schema.

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

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

Schema description coverage is 75%, so the schema carries most parameter meaning (reportDate formats, version examples, maxRows default 200, saveTo). The description adds one genuinely non-schema detail – the physical location of vendorNumber in App Store Connect – but does not clarify the interaction between saveTo and maxRows or how reportSubType/reportType should be chosen.

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 ('Sales and Trends report'), and enumerates the report content (sales, subscriptions, subscription events, installs), which separates it from the sibling asc_download_finance_report by data domain. It does not explicitly name or contrast the sibling, so it stops short of a 5.

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

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

It gives two useful operational pointers: where to find the required vendor number (Payments and Financial Reports in App Store Connect) and data-availability timing ('usually available a day after the reporting date'). However, it never states when to prefer this over asc_download_finance_report or other reporting tools, so usage is implied rather than directed.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavioral context beyond them: the request is a GET and the URL must resolve to Apple's API host, which tells the agent this is a constrained passthrough rather than an arbitrary HTTP client. It says nothing about authentication or rate limits, so not a 5.

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

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

Two tight sentences: the capability and its examples come first, the hard host restriction second. No filler, nothing to trim.

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

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

For a simple read-only passthrough with no output schema, the description covers the essential routing and the host constraint. However, with 0% schema coverage it leaves 'saveTo' and the response shape entirely undocumented, which is a real gap for an agent deciding whether the result is returned or written to disk.

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 there are two parameters. The description indirectly explains 'url' (must be a full Apple API URL) but gives no syntax guidance, and 'saveTo' is completely unexplained — an agent cannot tell that it likely persists the response to a file path rather than returning it inline.

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

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

States a specific verb (GET) and a clearly bounded resource (a full api.appstoreconnect.apple.com URL), and the examples of nextUrl and relationship related links make it obvious this is the generic escape hatch rather than one of the specific asc_list_* 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?

Gives concrete when-to-use triggers (following a nextUrl from a prior response, or a relationship's related link) and a hard precondition (only Apple's API host is allowed). It does not explicitly name a when-not case or point at an alternative tool, so it stops short of 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully discloses the shape of the result (ids, names, bundle ids, SKUs), but says nothing about pagination behavior or how the default limit of 100 affects a large account.

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

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

Two short sentences with zero waste; the primary purpose is front-loaded and the prerequisite note follows. Nothing could be trimmed without losing information.

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

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

With no output schema, the description sensibly compensates by listing the returned fields, and annotations cover the read-only/open-world nature. The one gap is pagination and limit handling, which an agent listing a large account would want to know.

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

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

Schema description coverage is 100% – each of the three filter parameters is documented in the schema itself. The description adds no filter semantics, syntax, or matching behavior beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (apps in the App Store Connect account) and even enumerates the fields returned (ids, names, bundle ids, SKUs). It does not, however, distinguish itself from the sibling asc_app_overview, which plausibly overlaps as an app-information 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?

'App ids are needed by most other tools' implies this is a prerequisite discovery call, which is useful implied guidance. It names no explicit alternative and gives no when-not-to-use condition, so usage is only implied rather than stated.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already known. The description adds useful content context by naming internal/external groups and mentioning ids and public link settings, but it omits pagination, authentication, and rate-limit behavior.

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

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

The description is a single front-loaded sentence with no redundant or filler content. Every phrase contributes to scoping the resource and the returned data.

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 low complexity, no output schema, and annotations covering read-only safety, the description is partially sufficient by indicating return contents. However, it leaves the only parameter undocumented and does not describe list completeness or pagination, so gaps remain for an agent invoking it correctly.

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

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

There is one required parameter, appId, and schema description coverage is 0%. The description only implies that an app identifier is needed through the phrase "an app's", without explaining the expected format, source, or constraints, so it does not compensate for the schema 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: list an app's TestFlight beta groups, including internal and external types. It is clear what the tool returns, but it does not distinguish itself from sibling list tools such as asc_list_builds or asc_list_apps beyond the resource name.

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

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

The description gives no guidance on when to choose this tool versus alternatives, nor any prerequisites or exclusions. An agent can infer from the resource name, but there is no explicit usage 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavior (newest-first ordering and the shape of each returned record), but says nothing about pagination behavior beyond the schema's default-25 limit or about how the optional filters narrow results.

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

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

One front-loaded sentence that names the resource, the ordering, and the payload. No filler and nothing buried.

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

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

With no output schema, the description usefully previews the returned fields, but for a 5-parameter list tool it omits the filtering semantics of version, buildNumber, and processingState and does not mention pagination, leaving gaps an agent must guess at.

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 60%, so appId and processingState lack descriptions. The description enumerates returned fields rather than explaining the filter parameters, and 'platform'/'expiry' are not even inputs, so it adds only marginal meaning over the schema. Baseline 3 for partially covered 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?

States a specific verb and resource ('List an app's builds') plus ordering ('newest first') and the returned field set. It is unmistakably distinct from the other asc_list_* siblings, though it never names an alternative to route between 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?

No when-to-use guidance, no mention of alternatives such as asc_app_overview, and no indication that the optional version/buildNumber/processingState parameters act as filters. The agent is left to infer that this is the raw build-list call.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-data profile are covered. The description adds useful return-content context by naming rating, title, body, territory, and developer response, but it does not disclose pagination behavior or other operational traits beyond what the schema provides.

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

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

The description is two tight sentences with no filler. The primary listing behavior is front-loaded, and the filter tip follows 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 read-only list tool with no output schema, the description is mostly complete: it names the returned review fields and explains the key unansweredOnly filter. The main remaining gap is that pagination and sorting behavior are left entirely to the schema.

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

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

Schema description coverage is 67%, so the schema documents several parameters already. The description adds meaning specifically for unansweredOnly by explaining its purpose, but it does not clarify sort defaults, rating filtering, territory codes, or limit behavior beyond the schema text.

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

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

The description gives a specific verb and resource: list an app's App Store customer reviews. It also names returned fields, so the agent can tell this is a review-listing tool rather than a generic app/build/resource lister. It does not explicitly contrast with sibling tools, which keeps it below 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 description states one useful usage condition: use unansweredOnly to find reviews that still need a reply. That is helpful but narrow; it does not say when to use this tool versus alternatives or describe 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the return content (each group plus its operation count) and that this is a no-parameter enumeration of the whole API surface, though it says nothing about result size, ordering, or caching.

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, no filler. The enumeration purpose is front-loaded, and the follow-up action is appended only after the primary purpose is established.

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

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

With no parameters and no output schema, the description must carry the return-value explanation itself, and it does ('resource group with its operation count', plus examples). Purpose, usage trigger, and follow-up path are all present, so nothing an agent needs in order to invoke it is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to add. The description correctly signals that the call is argument-free and that the tag it produces is consumed by asc_search_operations.

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 every resource group (tag) in the App Store Connect API') and immediately clarifies the returned payload ('with its operation count'), with concrete examples (Apps, Builds, BetaGroups). It is clearly distinguishable from sibling tools like asc_search_operations, which it names.

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 an explicit condition for use ('browse the API when you don't know what to search for') and routes the agent to the follow-up tool with the required argument ('then call asc_search_operations with a tag'). The inverse case (you already know the tag) is implied strongly enough that no alternative is left ambiguous.

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

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

The readOnlyHint=true annotation already establishes this is a safe read, and the description adds the useful scope note that results are per-locale and lists the returned metadata fields. It says nothing about pagination, locale coverage limits, or the openWorldHint implication that data may change between calls.

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 no filler, and the field enumeration comes before the id-provenance hint so the agent gets the payoff first.

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

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

With no output schema, the description compensates by naming the returned fields, so the agent knows the shape of the response. What remains unstated is pagination behavior and whether all locales are always present, which for an openWorldHint list tool would be worth one more sentence.

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 is fully documented in the schema at 100% coverage, so the schema baseline already applies. The description earns credit above baseline by explaining the provenance of versionId, which the schema only labels as 'appStoreVersion 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?

A specific verb plus resource ('List the per-locale App Store metadata of a version') followed by an enumeration of the exact fields returned. The agent can distinguish this from siblings such as asc_app_overview, which the description explicitly positions as the source of version ids.

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

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

It tells the agent where version ids come from ('Get version ids from asc_app_overview'), which is the key precondition for calling it. What is missing is any statement of when not to use it or which sibling covers adjacent needs, so it stays below 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds the crucial context that explains this: the tool merely opens a browser page and the user performs any mutation, which is why a 'settings' tool is non-destructive. It also enumerates what the page exposes (API key, access mode, client setup), which goes beyond the annotations.

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

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

Three sentences, front-loaded with the action, then the page contents, then the trigger conditions and the constraint. Each sentence carries distinct information with no repetition of the name or title.

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

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

For a zero-parameter, no-output-schema tool, the description covers what happens, why it is safe despite touching credentials, and when to invoke it. An agent has everything needed to decide to call it and to explain the outcome to the user.

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 zero parameters, so the baseline is 4; there is no parameter semantics for the description to compensate for. Nothing in the text conflicts with the empty input contract.

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 — opening the local settings page in the user's browser — and immediately scopes it with what the page is for (API key, access mode, client registration). This clearly separates it from every sibling, which are all data-retrieval or operation-invocation 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?

Explicitly names the triggering conditions: credentials missing or rejected, or the user wanting writes enabled. It also sets the boundary that only the user can change settings there, so the agent knows this is a hand-off, not a programmatic fix.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds the corpus size (1,300+) and, importantly, the return contract (operationIds) plus how they chain into describe/call. It omits pagination/result-cap behavior and deprecation handling, but nothing is contradicted and the added workflow context is genuinely useful.

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

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

Three sentences, front-loaded with what the tool does, then the return contract, then the sibling preference. Every sentence carries distinct information and there is no 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?

No output schema exists, and the description compensates by stating what is returned (operationIds) and the next-step tools, which is the key integration detail. Minor gaps remain around result limits and deprecated-operation behavior, which are left entirely to the schema.

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

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

Schema coverage is 80%, so the baseline is 3, and the description adds meaning by giving concrete query examples ('customer reviews', 'testflight testers', 'subscription prices', 'xcode cloud builds') that illustrate the keyword style the query parameter expects. It adds nothing for tag/method/includeDeprecated, which the schema already documents.

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 concrete verb+resource with scope ('Search all 1,300+ App Store Connect API operations') and distinguishes itself from curated siblings by positioning itself as the fallback for non-curated operations. It also names the downstream tools (asc_describe_operation, asc_call_operation), so an agent can place it in the workflow without reading 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?

Gives a clear usage rule: 'Prefer a curated asc_* tool when one fits the task,' which is an explicit when-not-to-use signal with a named alternative class. It doesn't spell out when to pick search over asc_list_resource_groups or when a keyword search is preferred over a direct describe, so it stops short of full routing guidance.

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