appstore-connect-mcp

by tomoki013

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation4/5
Each tool targets a distinct resource and action, with clear descriptions that separate similar-sounding tools (e.g., build status vs upload status vs wait). A few pairs like app-info localization vs metadata could be confused without close reading, but overall the boundaries are well-defined.
Naming Consistency5/5
Every tool follows the consistent pattern asc_<resource>_<action> (e.g., asc_builds_list, asc_version_update, asc_screenshot_upload), using snake_case throughout with no camelCase or irregular verbs. This makes the naming highly predictable and scannable even at scale.
Tool Count2/5
At 44 tools, the server significantly exceeds the 25-tool threshold where coherence typically degrades. While the App Store Connect domain is broad, the granularity here is high and could overwhelm agents; some operations could likely be consolidated.
Completeness4/5
The tool set covers core release workflows comprehensively: app management, builds, versions, metadata, localization, beta groups, pricing, availability, review, screenshots, submission, and preflight. Minor gaps exist—no version deletion, no beta group creation/update, and no privacy management—but they are non-critical for most release automation.
Average 4.2/5 across 44 of 44 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal for a mutation tool with no annotations. It discloses the 'Write' nature and dryRun support but omits details about permissions, side effects, reversibility, or response format. The dryRun mention is useful but insufficient to fully convey behavioral traits without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Utterly concise: two sentences, front-loaded with 'Write.' and no wasted words. Every element serves a purpose and adds clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 3 parameters and no output schema, the description covers the core purpose and dryRun behavior, but does not mention return values, authentication prerequisites, or whether a prior read via asc_content_rights_get is recommended. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so the description partially compensates. It clarifies the meaning of contentRightsDeclaration ('third-party content requiring rights') and dryRun ('preview the change'), but does not add much beyond the schema's existing dryRun description and the enum values. AppId is left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Sets whether the app uses third-party content requiring rights.' The verb 'Sets' and resource 'content rights declaration' are specific and distinguish it from sibling read tools like asc_content_rights_get and other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention asc_content_rights_get or other related tools, nor does it specify conditions under which this update should be performed. The only context is implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It states 'Read-only' which is a clear behavioral disclosure, but lacks additional context such as authentication requirements, what fields are included, or error behavior. Some details are 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the essential information without redundancy. 'Read-only.' is an efficient opening that immediately signals the safe nature of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with only two required parameters and a clear read-op purpose. The description covers the 'get one' aspect, and the schema covers parameters. However, without an output schema, the agent must infer the return shape; mentioning the specific localized fields returned or any potential errors would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (appId, locale) with descriptions, so the description adds no additional parameter semantics beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and clearly identifies the resource ('app-level localized fields for a single locale'), distinguishing this from sibling list/update/create operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like asc_app_info_localizations_list or asc_app_info_localization_update. The 'Read-only' prefix hints at a reading use case but does not give explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the core action (sets the shipping build) and the dryRun preview capability. However, it doesn't mention whether the previous build selection is overwritten, requires a specific version state, or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action, but the initial 'Write.' is redundant with the title. The two substantive sentences are efficient and contain the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and no output schema, the description covers the core purpose but lacks information about return values, side effects, or interplay with the version lifecycle (e.g., validation before submission). However, the schema covers parameters, so the description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all four parameters (100% coverage), so the baseline is 3. The tool description only repeats the dryRun concept already in the schema, adding no extra parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Sets') and resource ('which uploaded build an App Store version will ship'), distinguishing it from siblings like asc_version_update or asc_build_upload. The title further confirms 'Attach a build to an 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to set the build for an App Store version, but it doesn't explicitly state when to use it over alternatives or mention any exclusions. It only mentions dryRun for previewing, which is more of a parameter feature than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It explicitly states 'Read-only', which helps, but it does not disclose response format, error behavior, or territory code details. This is a simple tool, but richer behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that leads with 'Read-only' before stating the action. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description provides enough context: purpose, scope, and safety. Minor gaps remain around response format and territory encoding, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single appId parameter, which includes its own description ('Bundle id, app name, or App Store Connect app id'). The tool description adds no additional parameter semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'App Store territories' with scope 'an app currently available in'. This distinguishes it from the sibling asc_availability_update, which is the write counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Read-only' prefix signals that this is a safe read operation, but there is no explicit guidance on when to use this tool versus alternatives like asc_availability_update. It lacks explicit exclusions or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose a key side effect (creating the screenshot set if it doesn't exist), which is useful. However, it does not mention permissions, idempotency, whether existing screenshots are replaced, or prerequisites like an existing version/locale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main verb 'Uploads'. The 'Write.' prefix is somewhat redundant but not bloated. It is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter mutation tool with no annotations and no output schema, the description covers the main action and one side effect, but lacks information about return values, prerequisites (e.g., app/version existence), and potential failure modes. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (4 of 5 parameters have descriptions; screenshotDisplayType has an enum). The description adds modest context by linking screenshotDisplayType to the screenshot set creation logic, but otherwise repeats parameter names. Baseline 3 applies due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a local screenshot file to App Store Connect for a specific version/locale/display type, and it distinguishes itself from sibling tools like asc_screenshot_delete by specifying the action and the screenshot set creation side effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context of when to use the tool (for uploading screenshots to a specific version/locale/display type) but does not explicitly mention when not to use it or name alternatives. The 'Write.' prefix and the upload verb imply mutation, which is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only' and clarifies it retrieves current answers, providing key behavioral context. It does not disclose potential error states or response format, but given the simplicity of the operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence preceded by 'Read-only.' It immediately communicates the most important behavior and lists the specific data returned without unnecessary detail. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, no output schema, no annotations), the description sufficiently explains what is retrieved. It mentions the specific components of the questionnaire, making the tool's purpose clear for an agent. It could benefit from noting that the answer would be for a single app, but the parameter name implies that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear description for appId ('Bundle id, app name, or App Store Connect app id'). The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current App Store age rating questionnaire answers for an app, specifying content descriptors, Kids Age Band, and overrides. It uses the verb 'Gets' and identifies the resource, distinguishing it from the update sibling tool by declaring it 'Read-only'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: this tool is for retrieving current age rating answers, while the update sibling would be for modifications. However, the description does not explicitly state when to use this tool versus alternatives or mention any exclusions, so it relies on implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses read-only nature and explains the default behavior of returning all locales when no specific locale is provided. This adds context beyond the title for a tool with no annotations, though it does not cover auth or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'Read-only.', and contains zero waste. It is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description covers the core behavior and default filtering. It does not elaborate on return format or errors, but that is acceptable given the tool's simplicity and the presence of full schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage), so the baseline is 3. The description adds minimal extra meaning about locale behavior, but the schema already states it is optional and used to filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'per-locale TestFlight "What to Test" notes for a build', which distinguishes it from sibling tools like asc_beta_build_localization_update and asc_build_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool vs alternatives, and only the 'Read-only' prefix implies usage for reads. No exclusions or alternative recommendations are provided, making it implied usage rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It reveals an important prerequisite (localization must exist) and Apple's automatic creation behavior. However, it does not mention what happens if the localization does not exist, whether the update is idempotent, or any permission requirements. This is decent but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the operation type ('Write') and a clear action. No unnecessary information, every sentence contributes useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 required params, no output schema, no annotations), the description covers the essential behavior and key prerequisite. It lacks details on return values or error handling, but those are less critical for a simple update operation. The pointer to the get tool helps complete the workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds some context by tying the 'locale' parameter to the prerequisite that localization must already exist, but it doesn't add substantial meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Updates the "What to Test" notes shown to testers for a build/locale.' It uses a specific verb ('Updates'), identifies the resource (build/locale localization), and explicitly differentiates from the sibling tool asc_beta_build_localization_get by directing users to check existence first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: the localization must already exist, and points to asc_beta_build_localization_get as a prerequisite check. It does not explicitly list situations where the tool should not be used, but the guidance is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses read-only behavior, which is a key safety signal. However, it does not describe error handling, authentication requirements, or response format, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with 'Read-only,' and each word adds value. It is appropriately minimal for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward single-get tool, the description adequately covers its purpose and parameters. There is no output schema, but return values are implied for a get operation, and the tool's simplicity reduces the need for further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter coverage with clear descriptions for appId and buildId. The description restates that buildId can be a build id or version/build number, adding no new information beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets a single build by its App Store Connect build id or version/build number, providing a specific verb and resource. It distinguishes itself from sibling tools like asc_builds_list and asc_build_latest by emphasizing 'single build.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (when fetching a specific build) but does not explicitly mention alternatives or when not to use it. It implies a single-build lookup, which is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states 'Read-only,' which is a critical safety trait. However, it does not describe return format, error cases, or authorization requirements, which would provide richer transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value, conveying both the read-only nature and the precise purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one well-documented parameter and no output schema, the description is nearly complete. It states what is retrieved (contentRightsDeclaration) and implies a boolean result. It could mention authentication or return format, but for this low-complexity tool, the current detail is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the appId parameter is already well-described in the schema. The description adds no additional parameter-specific meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Gets') and resource ('content rights declaration'), and even names the exact field (contentRightsDeclaration). This distinguishes it from the sibling asc_content_rights_update tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is a read-only operation to fetch the content rights declaration. It does not explicitly exclude alternatives, but the intent is unambiguous. The read-only phrasing signals when this tool should be used (inspection) versus the update sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states 'Read-only' and describes what information is returned (review state and submitted flag). It does not detail response format or error handling, but it is transparent about the core behavior and data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the read-only nature and uses a parenthetical for examples. It contains no filler and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description reasonably explains the return value by naming the review state and submitted flag, with examples. It is adequate for a simple status getter, though it could list all possible states or describe the response structure in more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already clearly described in the input schema. The tool description adds no additional parameter-specific meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as getting the App Store review state for a version, specifying the verb 'Gets' and the resource. It distinguishes itself from siblings like asc_review_get or asc_build_status by focusing specifically on submission status and provides concrete state examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing App Review submission status, but it does not explicitly contrast with alternative sibling tools or provide exclusion criteria. The 'Read-only' prefix offers some context but is not a full usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses the main side effect (creating a version), a critical non-effect ('does not submit anything for review'), and the dryRun preview behavior. It omits details like permissions, idempotency, or response shape, but the most important behavioral distinctions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose, then options, then caveats. The leading 'Write.' is redundant with the title's '[Write]' and the example could be trimmed slightly, but each sentence carries useful information and the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation with no output schema and no annotations, the description covers purpose, the no-submit caveat, and dryRun. However, it does not state what the tool returns, how duplicate version strings are handled, or error behavior, leaving some gaps for an agent to fully rely on it in a multi-step workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71% (5 of 7 parameters documented). The description adds value by naming optional fields (copyright, releaseType, earliestReleaseDate) and listing releaseType enum values. However, it largely repeats schema info for dryRun and earliestReleaseDate, and does not explain copyright's format or releaseType semantics beyond the enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and resource ('a new App Store Version'), includes a concrete example ('prepare 1.1 for review'), and distinguishes itself from submission by stating 'This does not submit anything for review.' This clearly separates it from sibling tools like asc_version_update, asc_versions_list, and asc_submit_for_review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('prepare 1.1 for review'), notes an important exclusion ('does not submit anything for review'), and mentions dryRun for previewing. However, it does not explicitly name alternative sibling tools (e.g., asc_version_update or asc_version_ensure), 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.
Behavior4/5
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 core behavior (idempotent get-or-create), the return structure ({ version, created }), and dryRun support. It doesn't mention permissions or side effects on existing versions, but it clearly states it returns the existing version without implying modification, which is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with 'Write' and the core purpose. Every phrase earns its place, and the dryRun mention is integrated naturally. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the central get-or-create flow and return shape, but lacks details about how the optional parameters (platform, releaseType, copyright, earliestReleaseDate) interact with the creation process. Without an output schema, it could clarify edge cases like what happens if the version already exists with different attributes. It's adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57%, so the description should compensate for undocumented parameters like copyright, releaseType, and earliestReleaseDate. However, it only mentions dryRun, adding little beyond the schema. It does not explain how releaseType or other optional parameters affect the creation behavior, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's unique behavior: returns an existing App Store version or creates it if missing. It uses specific verbs ('Returns', 'creates') and explicitly differentiates from a manual get/check/create sequence, distinguishing it from siblings like asc_version_get and asc_version_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to avoid a manual get/exists-check/create/conflict sequence. This implies it's the preferred alternative to composing separate calls, and it mentions dryRun for previewing. It doesn't explicitly name sibling tools as alternatives, but the guidance is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses 'Read-only', a key safety trait, but it does not describe error behavior (e.g., what happens if the version is not found) or any prerequisites beyond the parameter schema. This leaves notable gaps for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: 'Read-only.' is stated first, followed by a single clear sentence. There is no filler, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 well-documented params, no nested objects) and no output schema, the description is mostly sufficient. It clearly states what the tool does and its read-only nature. However, it omits mention of not-found behavior or return format, which is a minor gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for both parameters, so the baseline is 3. The description adds minimal extra meaning by clarifying 'by its version string' as the lookup key, but it does not provide additional format details or edge-case semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets a single App Store version by its version string' specifies a clear verb ('Gets'), resource ('a single App Store version'), and scope ('by its version string'). It distinguishes this tool from siblings like asc_versions_list (which lists versions) and mutation tools like asc_version_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need a specific version by its version string, providing clear context. However, it does not explicitly mention alternatives or when-not-to-use scenarios, such as preferring asc_versions_list when listing all versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency responsibility. It explicitly discloses that the password is write-only and never echoed in results, dryRun output, or logs, and that the update is partial. This goes beyond schema details and provides valuable safety context, though it does not cover permissions or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences that start with the operation type ('Write.'), then list the affected fields, and provide essential password/dryRun details. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no output schema, and no annotations. The description covers scope, partial-update behavior, password safety, and dryRun, but it does not mention what the response contains or potential error conditions. This leaves some ambiguity for an agent invoking it, though the core usage is reasonably covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 36%, and the description groups parameters as 'reviewer-only info' but does not individually explain semantics for most fields (e.g., contactEmail, notes). It repeats password write-only behavior from the schema and mentions dryRun, but does not fully compensate for missing parameter descriptions on 7 schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a write operation that 'partially updates reviewer-only info', enumerating specific fields (contact name/phone/email, demoAccountRequired, demoAccountName, demoAccountPassword, notes). This distinctively separates it from read tools like asc_review_get and other update tools such as asc_version_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for updating reviewer-only information) and mentions dryRun support for previewing changes. However, it does not explicitly exclude alternatives like asc_submit_for_review or provide 'when-not-to-use' guidance, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the disclosure burden. It explicitly states 'Read-only' and enumerates the output fields, providing transparency about the operation's non-mutating nature and return structure. However, it does not mention potential pagination or permissions, but for a simple list tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences (~20 words) that front-load the behavior ('Read-only. Lists all App Store versions') and then list the returned fields. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a single parameter and no output schema, the description adequately covers purpose, output fields, and safety. It specifies 'all' versions, giving a complete scope. No annotations or output schema exist, but the description compensates sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema coverage is 100% with appId fully described ('Bundle id, app name, or App Store Connect app id'), so the description need not repeat it. The tool description adds no parameter details beyond the schema, consistent with the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('lists') and resource ('all App Store versions for an app') alongside explicit output fields (version string, platform, review state, etc.). This clearly distinguishes it from sibling tools like asc_version_get (single version) and asc_version_create, despite not naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a collection of versions but does not provide explicit guidance on when to choose this tool over siblings like asc_version_get or mention any exclusions. The 'Read-only' prefix and list semantics suggest contexts, but no when-not-to-use or alternative tools are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It adds valuable context: partial update semantics, dryRun preview as old→new diff without applying, and lists updatable fields. However, it does not mention permissions, response format, idempotency, or reversibility, which is a gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the operation and field list. Every sentence earns its place, with no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 7 parameters, the description covers the core action and dryRun behavior but omits return value details, prerequisites (e.g., version must exist), and edge-case constraints. It is adequate but lacks a fuller picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71% (5 of 7 properties documented). The description adds meaning by inlining releaseType enum values (MANUAL/AFTER_APPROVAL/SCHEDULED) and clarifying dryRun behavior. It also helps compensate for missing schema descriptions on copyright and releaseType by naming them as updatable fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Partially updates an existing App Store version' with specific verb and resource, and enumerates updatable fields (versionString, copyright, releaseType, earliestReleaseDate). This distinguishes it from sibling tools like asc_version_create (create) and asc_version_get (get).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for partial updates to existing versions, with dryRun option. Does not explicitly exclude alternatives or name sibling tools, but the 'existing' and 'partially updates' framing implies it is not for creation or full replacement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses 'Read-only', which is important given no annotations are provided. However, it does not describe what 'details' are returned, potential ambiguity of matching by name, error behavior, or permission requirements. With no annotations, this leaves some behavioral gaps for an agent to infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loads the key read-only behavior, and every word contributes meaning. No filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool and full schema coverage, the description provides sufficient invocation guidance. The absence of an output schema is partially mitigated by the clear 'details for a single app' phrasing, though a fuller list of returned fields would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the parameter as 'Bundle id, app name, or App Store Connect app id' (100% coverage). The description adds concrete examples (io.tmkch.colorvia, Colorvia) and clarifies that the numeric id is not mandatory, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets details for a single app') and the resource ('app'), and distinguishes from list-style siblings by emphasizing 'single app'. The read-only nature is front-loaded, and the identifier options are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on how to invoke the tool: by bundle id, app name, or numeric App Store Connect id, with a reassurance that the numeric id is never required. It does not explicitly name alternative tools for listing or search, but the 'single app' framing implies the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states 'Read-only', which is a key behavioral trait, and details what data is returned (processing state and beta review state). It doesn't mention potential errors or return format, but for a simple read tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the essential 'Read-only' qualifier, then states the action and purpose. Every word earns its place; there is no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description covers the core actions and intended use. It names the data returned (processing state and beta review state), which is sufficient for an agent to decide when to call it. It doesn't describe the exact return structure or possible status values, but that is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already fully documents both parameters. The description does not add any parameter-specific meaning beyond what is in the schema, such as clarifying the format or acceptable values for appId and buildId. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and clearly identifies the resource: a build's processing state plus its internal/external TestFlight beta review state. It also states the purpose ('checking whether a build is ready to distribute to testers'), which distinguishes it from sibling tools like asc_build_status or asc_submission_status that focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'for checking whether a build is ready to distribute to testers.' While it doesn't explicitly mention alternatives or exclusions, the purpose is specific enough to guide an agent to select this tool over similar siblings when the goal is TestFlight beta readiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only', which signals no side effects, and further describes what the response includes (internal group flag, public link sharing enabled). This is sufficient for a simple list tool, though it doesn't cover error handling or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence beginning with 'Read-only' followed by the action. It contains no fluff or redundant information; every word contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, no output schema, no annotations), the description is fairly complete. It explains what is returned (groups with internal and public link flags) and that it is read-only. It does not describe pagination or error cases, but for a list operation this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter (appId) with a clear description of accepted values, so schema coverage is 100%. The description does not add extra meaning to the parameter beyond what the schema already provides. Baseline 3 is appropriate since the schema carries the semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lists TestFlight beta tester groups for an app' with a specific verb and resource. It also distinguishes itself from siblings by noting it lists groups, not adds builds or manages localizations. The inclusion of examples ('Internal Testers') and output details (internal group status, public link sharing) makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is a read-only operation for listing beta groups, implying it should be used to retrieve group information rather than modify it. However, it does not explicitly name alternatives or when-not-to-use scenarios, so it falls short of a 5. The 'Read-only' tag gives enough guidance for safe use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly discloses read-only behavior, the non-mutating nature ('never writes'), and that it 'suggests the next one' (not just the latest). It doesn't describe return format or error behavior, but for a read-only tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the most important information front-loaded ('Read-only. Finds the highest build number...'). No wasted words or repetition, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with no output schema, the description covers what it does, when to use it, and its non-mutating nature. However, it could be slightly more explicit about the return value (e.g., whether it returns the latest and/or suggested build numbers), but the intent is clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for all three parameters. The description adds context by mentioning 'optionally scoped to a marketing version and/or platform', which maps to the version and platform parameters, but doesn't add meaningful syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Finds') and clear resource ('highest build number (CFBundleVersion) already uploaded for an app'), with optional scoping by version/platform. This distinguishes it from siblings like asc_builds_list (which lists builds) and asc_build_get (which fetches a specific build).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this before an Xcode MCP build/archive step to decide what build number to set.' It also explains when not to use it ('this server never writes to the Xcode project itself'), but it doesn't explicitly name alternative tools, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only' and adds valuable context about the return content (state plus validation errors/warnings). It does not cover failure behavior or authentication, but for a simple read-only status checker, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence broken into two short fragments. It leads with 'Read-only' and the verb 'Gets', immediately conveying the action and safety. Every word contributes meaning, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one parameter, no output schema, and no nested objects. The description adequately covers what it does, what input it expects (contextually via asc_build_upload), and what it returns (state and errors). It lacks edge-case behavior (e.g., invalid ID), but for this level of simplicity, the coverage is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for the only parameter, buildUploadId, with a description that states it is returned by asc_build_upload. The tool description repeats this same information, adding no new semantic value beyond what the schema already conveys. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it gets the state of a build upload, listing the possible states (AWAITING_UPLOAD, PROCESSING, FAILED, COMPLETE). It also distinguishes this from sibling tools like asc_build_status by explicitly tying it to 'a build upload started with asc_build_upload'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: after starting a build upload with asc_build_upload. It does not explicitly mention when not to use it or offer alternatives, but the pairing with asc_build_upload is a strong implicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that this is a partial update and mentions the dryRun preview behavior, which is valuable. Yet it does not explain what happens to unspecified fields (merge semantics), nor does it state permissions or error cases, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'Write' and 'Partially updates', and every word adds value. There is no redundancy or filler, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params, no output schema, no annotations), the description covers the core operation, the target fields, the locale requirement, and dryRun. It lacks details on response format or creation semantics, but for a partial update tool the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, but the description compensates by enumerating all updatable fields (description, keywords, promotionalText, whatsNew, supportUrl, marketingUrl). It also clarifies the dryRun parameter's role (preview as old→new diff) and the locale requirement (must be explicit), adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('updates') and a precise resource ('localized App Store metadata for a version/locale'), listing the exact fields involved. It clearly distinguishes from sibling tools like asc_app_info_localization_update (app-level) and asc_beta_build_localization_update (beta-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for version/locale metadata updates, and the locale must be explicit. However, it does not explicitly name alternatives when not to use it, though the scope is evident and excludes app-level or beta-level localizations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the tool never returns the demo account password, only a boolean flag (`demoAccountConfigured`). It also explicitly labels itself 'Read-only,' which is important for trust. Missing are details like permissions required or error handling, but for a simple getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'Read-only. Gets...' and no filler. Every clause adds value: read-only status, field list, and an explicit security caveat. Highly concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema and no output schema, the description provides a solid overview of what the tool returns, including a specific field name (`demoAccountConfigured`) and the critical exclusion of the password. It does not describe response shape or error cases, but for this scope it is sufficiently complete to guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both appId and version have descriptions), so the baseline is 3. The description adds little beyond that, only indirectly associating 'version' with the version parameter. It does not elaborate on parameter formats or edge cases, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Gets') and resource ('reviewer-only info for a version'), and enumerates the exact fields returned (contact name/phone/email, demo account requirement/name, review notes). It also distinguishes from siblings like asc_review_update by emphasizing this is read-only and focused on reviewer-only data, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is read-only, retrieves specific reviewer-only fields, and explicitly excludes the demo account password (only returns whether one is configured). This implies when to use it (when you need review contact/notes) and when not (if you need the password). However, it does not explicitly name alternative tools for those cases, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and explicitly states 'Read-only,' disclosing the non-mutating behavior. It also explains that sets are organized one per device display type, giving insight into the output structure. It lacks deeper details like pagination or error behavior, but is adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that begins with 'Read-only' and states the action and scope concisely. Every word contributes meaningful detail, with no redundancy or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list operation with three well-documented parameters and no output schema, the description provides sufficient context: it states the read-only nature, what is listed, and the required scope (version/locale). It does not enumerate return fields, but that is beyond minimal expectations for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters with descriptive text (e.g., appId as 'Bundle id, app name, or App Store Connect app id'). The description adds conceptual context about screenshot sets but does not significantly enhance understanding of the parameters themselves, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it lists App Store screenshot sets for a given version/locale, with a specific example (APP_IPHONE_67). This distinguishes it from sibling tools like asc_screenshot_upload or asc_versions_list, which address different resources or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to read screenshot sets for a specific app version and locale. It does not explicitly mention alternatives or exclusions, but the read-only nature and resource focus imply the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the behavioral burden. It discloses a key failure mode ('Fails if the locale already exists') and a dryRun option. It also labels the operation as 'Write' upfront. However, it does not mention permissions or what the response looks like, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, but the leading 'Write.' duplicates the title's '[Write]'. Every other sentence adds value: purpose, failure condition/alternative, and dryRun support. The structure is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description covers the main functionality, failure mode, alternative tool, and dryRun. It also provides a concrete locale example. Missing details include the specific privacy policy parameter semantics and expected output, but these are not critical for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (4 of 8 parameters have descriptions). The description adds context by grouping 'name, subtitle, privacy policy' as the localized fields, and gives an example locale. However, it does not clarify the distinct privacy policy parameters (privacyPolicyUrl, privacyChoicesUrl, privacyPolicyText), which remain ambiguous. This partially compensates for the schema gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Creates app-level localized fields (name, subtitle, privacy policy) for a new locale'. It uses specific verbs and identifies the resource. It distinguishes from the update tool by explicitly noting 'Fails if the locale already exists — use asc_app_info_localization_update for existing locales'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs the alternative: 'Fails if the locale already exists — use asc_app_info_localization_update for existing locales.' This directly names the sibling tool for existing locales, making the usage context clear. The mention of dryRun also signals a preview option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It explicitly states read-only behavior, specifies the data points included, and explains the sort order. This is substantial, though it doesn't cover potential edge cases like pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with 'Read-only' front-loaded, then the action, followed by a parenthetical enumerating fields and ordering. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool returns and its ordering, and the schema provides comprehensive parameter details. For a simple list tool with no output schema, this is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for both appId and limit (including default and max/min). The description adds no additional parameter semantics beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists uploaded builds for an app, enumerates the fields returned (build id, version/build number, upload date, processing state, expiry), and notes ordering (most recent first). This distinguishes it from siblings like asc_build_get and asc_build_latest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: listing all builds for an app. However, it doesn't explicitly contrast with alternatives such as asc_build_get or asc_build_latest, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description begins with 'Read-only,' which is a key behavioral disclosure since no annotations are provided. It also specifies exactly what data is returned (processing state and expiration flag) and implies the tool does not have side effects. This adds meaningful context beyond the schema, though it does not discuss auth, rate limits, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the critical 'Read-only' safety info, then states the exact purpose and examples, followed by the usage guidance. Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is complete. It covers the tool's purpose, return content, and even the typical workflow context (poll after upload). The presence of sibling tools does not create a need for more details, as the description already differentiates and fully explains the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both appId and buildId have detailed descriptions. The tool description does not add additional semantics about these parameters beyond referring to 'a build.' Since the schema already fully documents the parameters, the description provides no extra value, aligning with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Gets') and resource ('processing state and expiration flag for a build'), specifying concrete example states (PROCESSING, VALID, INVALID, FAILED). It distinguishes itself from sibling tools like asc_build_get (full build info) and asc_build_upload_status (focused on upload) by explicitly saying it gets 'just' the processing state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'use this to poll after an upload.' It clearly implies when to use this tool, but does not explicitly state when not to use it or name alternative tools for other needs. This is clear context but lacks exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explains the multi-step process (create upload, chunked send, MD5 checksum) and that processing continues on Apple's servers, which is valuable context. However, it does not mention permissions, rate limits, or potential side effects such as overwriting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every sentence adds value—covering file types, the upload mechanism, and follow-up steps. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex upload operation, the description covers the essential context: what the tool does, how it does it, and what to do next. The lack of an output schema is mitigated by explaining that processing continues on Apple's servers and directing to status tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the parameters are mostly self-explanatory. The description adds minimal parameter-level detail beyond what the schema already provides, such as file paths and versions, but does not compensate for the uncovered 20%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a build binary (.ipa/.pkg) to App Store Connect, with specific file formats and platforms listed. It distinguishes itself from sibling tools like asc_build_upload_status by describing the upload process itself and pointing to follow-up steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance: poll asc_build_upload_status and then asc_builds_list to monitor the upload's completion. It implies the tool is for initiating uploads, but does not explicitly state when not to use it or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It clearly states the operation is read-only and adds valuable nuance about the isFree field being null when no schedule is configured. This goes beyond a simple 'get' but does not cover potential error conditions or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately signals 'Read-only' and then succinctly lists what is retrieved. Every word adds value, with no redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description provides a complete summary of return values, including the conditional null behavior of isFree. This compensates fully for the missing output schema and covers the essential contextual information an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the appId parameter with its description, and the tool description adds no additional parameter-specific semantics. Since schema coverage is 100%, the baseline score of 3 is appropriate—the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Gets' and names the resource 'app pricing' with precise details about what is returned: schedule configured, base territory, and isFree status. It clearly distinguishes from the sibling asc_pricing_set_free by explicitly stating 'Read-only' and describing the read semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Read-only' prefix clearly indicates this tool is for reading pricing data, not modifying it, which provides clear context for when to use this tool versus the write-oriented sibling asc_pricing_set_free. However, it does not explicitly name alternatives or exclusions, 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.
Behavior4/5
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 discloses that the operation is a write ('Write.'), that it is a partial update (only provided fields), and that dryRun produces an 'old → new diff without applying it,' which is a significant safety behavior not otherwise documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with 'Write' and the core action, and every clause adds value—enum values, deprecated values, and dryRun behavior. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 30-parameter mutation tool with no output schema and no annotations, the description provides essential context: partial update semantics, current enum values, and a non-destructive preview mechanism. While it doesn't cover every parameter or return behavior, the key operational aspects are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description summarizes the allowed enum values ('NONE/INFREQUENT/FREQUENT') and warns that older '*_OR_MILD/*_OR_INTENSE' values are deprecated, reinforcing the schema's own descriptions for enum fields. It also adds detail to the dryRun parameter by explaining the diff output format, which is more specific than the schema's 'Preview only, do not apply'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Partially updates the age rating questionnaire for an app' with a specific verb and resource, and it distinguishes itself from the sibling read tool 'asc_age_rating_get' and other update tools by naming the age rating questionnaire as the target. The mention of 'Apple's current field set and enum values' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool's purpose—updating the age rating questionnaire—which naturally directs an agent to use it for write operations on age ratings. It does not explicitly exclude other tools, but the context of sibling 'get' and 'update' tools makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses 'Read-only' behavior and enumerates the exact fields returned (name, subtitle, privacy policy URL/text, privacy choices URL) for every locale. However, it does not mention pagination, error behavior, or required permissions, which would add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the operation and scope, the second contrasts with a related sibling. No redundant words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter list operation with no output schema, the description is largely sufficient: it defines purpose, scope, fields, and differentiation from the closest sibling. It lacks notes on pagination or empty result behavior, but these are minor given the limited scope of localizations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes appId fully (100% coverage), and the description adds no parameter-specific semantics beyond tool-level behavior. The description's 'for every locale' clarifies scope but not the parameter format or constraints, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists app-level localized fields... for every locale' with a specific verb and resource. It also explicitly distinguishes itself from asc_metadata_get, identifying the boundary between app-level and per-version fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names asc_metadata_get as an alternative and explains exactly what it covers differently ('per-version fields like description/keywords'), providing clear guidance on when to use this tool versus the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently reveals that updates are partial (only supplied fields change) and that dryRun previews changes as an old → new diff, which goes beyond simple mutation semantics. It stops short of detailing permissions, reversibility, or return values, but the core behaviors are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences that front-load the verb 'Write' and immediately state the update semantics and dryRun capability. Every sentence contributes value without redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description provides a solid overview: partial update, field list, and dryRun behavior. However, it omits what the non-dryRun response looks like and does not discuss error conditions or prerequisites beyond 'existing locale', leaving some gaps for a comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description compensates by explicitly listing the updatable fields (name, subtitle, privacy policy URL/text, privacy choices URL) and clarifying the dryRun parameter's diff behavior. While not every parameter gets a detailed explanation, the grouping and dryRun description add meaningful context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Partially updates') and resource ('app-level localized fields'), enumerating the exact fields (name, subtitle, privacy policy URL/text, privacy choices URL) and scope ('for an existing locale'). This distinguishes it from sibling tools like create or get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an existing locale' implies when to use this tool (updating an existing localization) versus creating a new one, and the dryRun feature is mentioned as a preview option. However, it does not explicitly name alternatives or provide exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 core behavior: adds the build, making it available to testers, and the prerequisite that the build must already exist. While it does not mention permissions, reversibility, or error cases, for a simple write operation the description covers the essential behavioral traits. A score of 4 is justified because it goes beyond the bare minimum with the prerequisite and exclusion, but lacks some depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that pack the core action, outcome, prerequisite, and a sibling pointer. It starts with 'Write.' to immediately signal the operation type. Every sentence adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter write tool with no output schema and no annotations, the description provides the essential context: what it does, when to use it, and what is required. It could be more complete by mentioning response behavior or error cases, but the existing information is sufficient for an agent to confidently invoke the tool. The overall context is covered well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the three parameters (appId, group, buildId) with meaningful descriptions. The tool description does not add any additional parameter-level semantics or syntax details beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Adds an already-uploaded build to a TestFlight beta group') and the outcome ('making it available to that group's testers'). It also distinguishes from sibling tools by explicitly noting it does not upload builds, which sets it apart from asc_build_upload. The verb 'Adds' is unambiguous and the resource (TestFlight beta group) is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: the build must already exist in App Store Connect, and it directs the user to asc_builds_list for checking existing builds. It also states a clear when-not ('this tool does not upload builds'), effectively pointing to an alternative. This is a strong example of telling the agent when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the operation fails if the locale exists, supports dryRun, and notes that fields can be filled in later via asc_metadata_update. It does not mention authorization or return values, but the core write behavior and error condition are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with a 'Write.' prefix, followed by clear purpose, error condition, and key feature (dryRun). Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, 3 required, no output schema, and no annotations, the description provides a solid overview of the tool's operation, failure mode, and relationship to asc_metadata_update. It does not mention success return values, but that is less critical for a create operation. The description is sufficiently complete for an agent to select and invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, so the description must compensate. It conveys that fields are optional and provides an example for locale, but it does not elaborate on the six optional metadata fields (keywords, whatsNew, supportUrl, etc.). The field names are fairly self-explanatory, but the description adds limited parameter-level detail beyond what the schema already gives for appId, locale, version, and dryRun.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Creates') and resource ('a new localization for a version') with a concrete example (adding ja to en-US). It also distinguishes itself from the sibling asc_metadata_update by explicitly noting that it is for new locales, while updates are for existing ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (new localization), when it fails (if locale already exists), and points to the alternative asc_metadata_update for existing locales. It also clarifies that fields are optional now or later, reinforcing the intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Read-only' and discloses the locale behavior ('returns all locales unless one is given'), which is a valuable behavioral nuance. It does not mention authorization, rate limits, or error handling, but this is sufficient for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'Read-only,' and every word adds value. It avoids restating schema details and efficiently conveys the core purpose and a key behavioral caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only metadata getter, the description covers the resource, the fields returned, the read-only nature, and locale behavior. While there is no output schema, the listing of fields partially compensates; the exact response structure is not described, but this is not critical for a simple get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters, so baseline is 3. The description adds meaningful context beyond the schema by explaining that locale is optional and that omitting it returns all locales, which is not obvious from the schema's 'Optional locale to filter to.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'localized App Store metadata' and lists specific fields (description, keywords, promotional text, what's new, support URL, marketing URL). It distinguishes this read tool from write siblings like asc_metadata_update by stating 'Read-only' and 'Gets... for a version.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only intent and target (a version's metadata) are clear, but it does not explicitly contrast with similar getters such as asc_version_get or asc_app_info_localization_get. No exclusion or alternative guidance is provided, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the price is scheduled (not immediate), that Apple automatically equalizes $0 across territories, that paid pricing is unsupported, and that dryRun is available. This is rich behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core action, then add limitations and dryRun support. The redundant 'Write.' prefix is minor but overall the description is immediately scannable and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write tool with no output schema, the description covers the action, territorial behavior, limitations, and dryRun. It stops short of explaining what the user should do after scheduling (e.g., verify with asc_pricing_get), leaving a slight gap in the full workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (appId, dryRun, baseTerritory are all described). The description adds a little extra context by explaining that scheduling occurs in the base territory and that dryRun is supported, but it does not significantly expand on parameter formats or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: sets the app's price to free by scheduling $0 in the base territory. It also specifies the resource (app pricing) and distinguishes from the sibling asc_pricing_get by focusing on the write action and explicitly noting that paid price points are not supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want the app free) and provides a key exclusion: paid price points are not supported. It also highlights dryRun support as a safe preview option. However, it does not explicitly name alternative tools for paid pricing or verification, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It declares 'Read-only' upfront, explains that each check reports pass/fail/warning/manual_required, defines the `ready` flag semantics, and highlights limitations like export compliance being 'if detectable' and privacy questionnaire being always manual. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads 'Read-only' and the core purpose before listing checked areas. The list is long but logically organized and every clause adds information. It is slightly verbose due to the comprehensive list, but appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains what the tool returns (pass/fail/warning/manual_required per check and the aggregate `ready` flag) and covers key edge cases (detectable export compliance, manual privacy questionnaire). This gives an agent enough context to invoke the tool and interpret results without needing a schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (appId, version, locale) already have descriptive schema entries, so the baseline is 3. The description reinforces that the check operates on app/version/build and mentions locale-specific items like metadata and screenshots, but it does not add substantial new parameter-level detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb + resource: 'Runs a comprehensive readiness check before submitting a version for App Review' and enumerates the exact domains checked. This clearly distinguishes it from sibling tools that perform individual lookups or updates, making the aggregate preflight purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'before submitting a version for App Review.' It also warns that the App Privacy questionnaire is 'always manual_required — no public API,' implying the agent cannot automate that step. However, it doesn't explicitly name alternatives or say when not to use it, so it's clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does an excellent job: it discloses the diffing behavior ('unchanged fields are never re-written'), failure isolation ('One category failing doesn't stop the others'), exclusions, and dryRun support. This gives the agent a complete picture of side effects and safety without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. The first sentence front-loads the verb, resource, and scope; the second explains diffing and failure tolerance; the third covers exclusions and dryRun. Every sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex sync tool with no output schema, the description covers the key behavioral aspects, scope, exclusions, and dryRun. It does not detail the exact return/report format, but it does say categories are 'reported separately' and dryRun 'preview[s] every change,' which is reasonably complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some context about projectRoot (reads .appstore/appstore.yml) and mentions dryRun preview, but the schema already documents parameter meanings. No significant extra syntax or usage detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Write' and clearly states it reads .appstore/appstore.yml and syncs a specific set of categories (App Info, version metadata, availability, age rating, review info, pricing, content rights) to App Store Connect. This distinguishes it from the many sibling get/update tools by framing it as a bulk SSOT-driven sync, not a single-resource mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use when you want to sync from a local SSOT config, and it explicitly calls out that screenshots and App Privacy are not covered. However, it does not name alternative sibling tools (e.g., asc_screenshot_upload) for those excluded actions, so it stops short of explicit when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It explicitly warns 'DESTRUCTIVE' and states 'Permanently removes', making the irreversible nature clear. It also scopes the action to a single screenshot. It does not mention auth needs or rate limits, but for a destructive operation, the key safety trait is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the 'DESTRUCTIVE' warning, and every word serves a purpose. It is concise and well-structured, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations, but the description covers the essential aspects: what it does, the destructive consequence, and how to get the required ID. It lacks some operational details like error handling or return values, but given the low complexity, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes screenshotId as 'App Store Connect appScreenshot id to delete.' The description adds meaning by specifying where to obtain this id (from asc_screenshot_sets_list results), which helps the agent understand the provenance of the parameter value. This goes beyond the schema's basic definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Permanently removes a single screenshot from App Store Connect.' The verb 'removes' and resource 'screenshot' are specific, and the action is distinguished from sibling tools like asc_screenshot_upload (upload) and asc_screenshot_sets_list (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite: 'Get the screenshot id from asc_screenshot_sets_list results (each set's screenshots) before calling this.' This tells the agent exactly how to obtain a valid input and implies the tool should be used only when deleting a screenshot. However, it lacks explicit 'when not to use' or alternative tool guidance beyond the prerequisite, so a perfect score is not warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It labels the tool as 'Read-only' and specifies exact output fields, giving a clear behavioral contract. It doesn't discuss pagination or rate limits, but these are less critical for a zero-parameter listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. It front-loads the action and safety label, then lists output fields and usage guidance. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description covers all essentials: what it does, what it returns, and when to use it. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is trivially 100%. The baseline for zero params is 4, and the description adds no parameter-specific semantics because none are needed; it explains what the tool does instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Lists all apps visible to this App Store Connect account') and enumerates the returned fields (name, bundle id, SKU, primary locale, app id). It clearly distinguishes itself from siblings like asc_app_get by framing this as the discovery step before other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover which apps exist before calling other tools,' providing clear when-to-use context. However, it does not mention when not to use it or name alternative tools, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses irreversible state changes ('cannot be trivially undone'), mandatory preflight dependency, automatic refusal on check failure, and the always-required native confirmation dialog. It even explains the tool will not act silently even if called, which is critical for an agent to anticipate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the destructive warning and packs the action, preflight, and confirmation into efficient sentences with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (destructive, no output schema, no annotations), the description covers the action, safety dependencies, and user-interaction requirements. It provides sufficient context for an agent to understand the tool's role and invocation constraints, including the preflight prerequisite and refusal behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so the description's lack of parameter detail is acceptable. No additional semantics beyond what the schema provides; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Submits a version for App Review via the current ReviewSubmission API' with a specific verb and resource. The 'DESTRUCTIVE / RELEASE-CLASS' prefix and reference to preflight distinguish it from sibling tools like asc_version_create or asc_submission_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Always runs asc_release_preflight first and refuses to proceed if any check fails,' providing a clear prerequisite and execution order. It also notes it 'never submits silently' and requires human confirmation, guiding when the agent should invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and discloses key behaviors: full replacement (destructive), live fetch for 'ALL', rejection of unknown codes before changes, and dryRun preview. This goes beyond basic mutation disclosure and helps the agent anticipate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four succinct sentences, front-loaded with 'Write' and the core action. Every sentence provides essential information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description adequately covers the tool's destructive nature, input constraints, validation behavior, and preview capability. It is complete for an agent to safely invoke the tool and interpret its effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, but the description adds significant value by explaining territory code formats, the 'ALL' expansion behavior, unknown-code rejection, and dryRun's purpose—information not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Replaces') and resource ('full set of territories an app is available in'), clearly distinguishing it from sibling tools like asc_availability_get. The leading 'Write' label also signals the operation type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context that this is a full replacement operation, with guidance on territory codes and the 'ALL' literal. It does not explicitly name alternatives or exclusions, but the sibling list includes a read counterpart, making the usage context sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 clearly discloses read-only behavior, polling at intervals, timeout handling, terminal states (VALID/COMPLETE vs FAILED/INVALID), and the exact return value categories (SUCCESS, FAILED, TIMEOUT, CANCELLED) plus additional payload details. This is unusually complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two well-structured sentences. It front-loads the read-only, polling nature, then provides terminal states and return details without any redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a polling tool with no output schema, the description is complete: input contract, mutually exclusive parameters, timeout and interval behavior, terminal states, and return value meaning are all covered. It gives an agent everything needed to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters with 100% coverage, giving a baseline of 3. The description adds the critical mutual-exclusivity requirement ('Give exactly one of buildId or buildUploadId') and connects timeout and pollIntervalSeconds to the polling behavior, which adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Read-only (polls, doesn't change anything)' and states it waits for a build or build upload to reach a terminal state. It distinguishes itself from sibling status tools like asc_build_status by emphasizing the polling/waiting behavior and terminal-state detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use when you need to wait for processing to finish, with an explicit instruction to pass exactly one of buildId or buildUploadId. However, it does not name alternative tools or explicitly state when not to use it (e.g., for a one-shot status check).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![appstore-connect-mcp MCP server](https://glama.ai/mcp/servers/tomoki013/appstore-connect-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tomoki013/appstore-connect-mcp)

Score Badge

Copy to your README.md:

[![appstore-connect-mcp MCP server](https://glama.ai/mcp/servers/tomoki013/appstore-connect-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tomoki013/appstore-connect-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tomoki013/appstore-connect-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server