App Store Connect MCP

Overview Schema Source Related Servers Discussions Admin

List builds

asc_list_builds

Read-only

Lists an app's builds newest first, returning build number, marketing version, platform, processing state, and expiry; use filters to narrow by version, build number, or processing state.

Instructions

List an app's builds, newest first, with build number, marketing version, platform, processing state and expiry.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "appId": "<appId>"
    },
    "name": "asc_list_builds"
  }
}

Input Schema

Name	Required	Description
`appId`	Yes
`limit`	No	Default 25
`version`	No	Marketing version (CFBundleShortVersionString), e.g. 2.3.0
`buildNumber`	No	Build number (CFBundleVersion)
`processingState`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 18, 2026

TDQS

B3.3/5.0

Behavior3/5

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

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

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

Conciseness5/5

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

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

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

Completeness3/5

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

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

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

Parameters3/5

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

Schema coverage is 60%, so appId and processingState lack descriptions. The description enumerates returned fields rather than explaining the filter parameters, and 'platform'/'expiry' are not even inputs, so it adds only marginal meaning over the schema. Baseline 3 for partially covered parameters.

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

Purpose4/5

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

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

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

Usage Guidelines2/5

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

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

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