Skip to main content
Glama
erayendes

Heimdall App Store Connect MCP

by erayendes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

apps__builds__list

Read-onlyIdempotent

List app builds sorted by upload date, newest first. Accepts app name, bundle ID, or Apple ID; supports pagination and field selection.

Instructions

List builds uploaded for an app, newest first when sorted by -uploadedDate. [GET /v1/apps/{id}/builds]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesApp name, bundle ID (com.example.app) or numeric Apple ID.
limitNomaximum resources per page
next_urlNoAbsolute links.next URL from a previous response.
fields_buildsNothe fields to include for returned resources of type builds Return only these attributes. A full row set can exceed 200 KB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.3.0
    • changedInput schema / properties / id / description
      Previous value: -"ID from the matching list call."New value: +"App name, bundle ID (com.example.app) or numeric Apple ID."
  2. Changed1 schema field changedv2.0.1
    • addedInput schema / properties / id / description
      Added value: +"ID from the matching list call."
  3. Changed3 schema fields changedv2.0.0
    • addedInput schema / properties / fields_builds
      Added value: +{
+  "description": "the fields to include for returned resources of type builds Return only these attributes. A full row set can exceed 200 KB.",
+  "items": {
+    "enum": [
+      "version",
+      "uploadedDate",
+      "expirationDate",
+      "expired",
+      "minOsVersion",
+      "lsMinimumSystemVersion",
+      "computedMinMacOsVersion",
+      "computedMinVisionOsVersion",
+      "iconAssetToken",
+      "processingState",
+      "buildAudienceType",
+      "usesNonExemptEncryption",
+      "preReleaseVersion",
+      "individualTesters",
+      "betaGroups",
+      "betaBuildLocalizations",
+      "appEncryptionDeclaration",
+      "betaAppReviewSubmission",
+      "app",
+      "buildBetaDetail",
+      "appStoreVersion",
+      "icons",
+      "buildBundles",
+      "buildUpload",
+      "perfPowerMetrics",
+      "diagnosticSignatures"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • removedInput schema / properties / id / description
      Removed value: -"Resource identifier."
    • changedInput schema / properties / next_url / description
      Previous value: -"Absolute `links.next` URL from a previous response, to fetch the next page. When set, all other parameters are ignored."New value: +"Absolute links.next URL from a previous response."
  4. First observedv1.3.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already communicate read-only and idempotent behavior. The description adds a useful detail about sort ordering ('newest first when sorted by -uploadedDate'), but does not disclose pagination behavior or other response characteristics. With annotations covering safety, this is adequate but not exceptional.

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 compact sentence conveys the core action and scope, followed by the endpoint reference. No filler or redundancy. The most important 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 simple read-only list operation, the description combined with full schema coverage and safety annotations is mostly complete. Pagination behavior is left implicit via the limit and next_url parameters, but this is a minor gap given the 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?

Schema description coverage is 100%, so the schema fully documents all four parameters. The description does not need to repeat parameter details. It adds a small hint about uploadedDate ordering, but the 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?

Description states a specific verb and resource: 'List builds uploaded for an app.' It also clarifies the resource scope ('for an app'), which distinguishes it from broader endpoints like builds__list. The endpoint reference adds precision.

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 builds belonging to a specific app, but it does not explicitly contrast it with alternatives such as builds__list or builds__get. There is no explicit when-to-use or when-not-to-use guidance.

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

Deploy Server

Other Tools