Skip to main content
Glama
erayendes

Heimdall App Store Connect MCP

by erayendes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

apps__get

Read-onlyIdempotent

Fetch app details like bundle ID, SKU, and primary locale from App Store Connect by app name, bundle ID, or numeric Apple ID.

Instructions

Read one app by ID, including bundle ID, SKU and primary locale. [GET /v1/apps/{id}]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesApp name, bundle ID (com.example.app) or numeric Apple ID.
includeNocomma-separated list of relationships to include Pull related records in the same call. Without it, checking a relationship costs one extra call per row returned.
fields_appsNothe fields to include for returned resources of type apps 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_apps
      Added value: +{
+  "description": "the fields to include for returned resources of type apps Return only these attributes. A full row set can exceed 200 KB.",
+  "items": {
+    "enum": [
+      "accessibilityUrl",
+      "name",
+      "bundleId",
+      "sku",
+      "primaryLocale",
+      "isOrEverWasMadeForKids",
+      "subscriptionStatusUrl",
+      "subscriptionStatusUrlVersion",
+      "subscriptionStatusUrlForSandbox",
+      "subscriptionStatusUrlVersionForSandbox",
+      "contentRightsDeclaration",
+      "streamlinedPurchasingEnabled",
+      "accessibilityDeclarations",
+      "appEncryptionDeclarations",
+      "appStoreIcon",
+      "ciProduct",
+      "betaTesters",
+      "betaGroups",
+      "appStoreVersions",
+      "appTags",
+      "preReleaseVersions",
+      "betaAppLocalizations",
+      "builds",
+      "betaLicenseAgreement",
+      "betaAppReviewDetail",
+      "appInfos",
+      "appClips",
+      "appPricePoints",
+      "endUserLicenseAgreement",
+      "appPriceSchedule",
+      "appAvailabilityV2",
+      "inAppPurchases",
+      "subscriptionGroups",
+      "gameCenterEnabledVersions",
+      "perfPowerMetrics",
+      "appCustomProductPages",
+      "inAppPurchasesV2",
+      "promotedPurchases",
+      "appEvents",
+      "reviewSubmissions"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • removedInput schema / properties / id / description
      Removed value: -"Resource identifier."
    • changedInput schema / properties / include / description
      Previous value: -"comma-separated list of relationships to include"New value: +"comma-separated list of relationships to include Pull related records in the same call. Without it, checking a relationship costs one extra call per row returned."
  4. First observedv1.3.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is fully consistent with them — no contradiction. The description adds light context about the response contents (bundle ID, SKU, primary locale) and the endpoint path. The schema's include parameter note about relationship call costs is useful behavioral context, but it lives outside the description itself, so the added value is modest.

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 short sentences: the action is front-loaded ('Read one app by ID'), followed by the specific returned attributes and a compact endpoint suffix. There is zero filler — every word carries meaning and the structure is easy to scan.

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-resource GET, the combination of strong annotations, a fully-described schema, and a pointed description leaves little ambiguity about how to invoke it correctly: identifier formats, optional include relationships, and field selection are all covered. Missing explicit error/auth expectations are minor because annotations already flag the safety profile and these are tool-family-wide concerns rather than tool-specific gaps.

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 each parameter well-documented: id lists all three accepted identifier forms, include explains comma-separated relationships and the per-row call cost, and fields_apps flags the >200KB row size trade-off. The description adds only a marginal hint that the default response includes bundle ID, SKU, and primaryLocale, so the baseline 3 holds without the description needing to compensate.

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 ('Read one app by ID') plus the salient returned attributes (bundle ID, SKU, primary locale). This differentiates it from the many sibling relationship getters (apps__ci_product__get, apps__game_center_detail__get) and the plural apps__list by making plain it returns one core app record. However, it doesn't explicitly name a sibling alternative, so it falls short of a full 5.

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 given about when to select this tool over the dozens of sibling 'apps__*__get' relationship getters or apps__list for searching. The only usage hints live inside the parameter descriptions (e.g., include's 'costs one extra call per row'), which help invoke the tool but not choose it. An agent must infer tool selection from the name and description alone.

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