Skip to main content
Glama
Sign In
erayendes

Heimdall App Store Connect MCP

by erayendes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

app_store_version_experiment_treatment_localizations__get

Read-onlyIdempotent

Retrieves a single App Store version experiment treatment localization by ID, with optional related records and selected fields.

Instructions

Read one App Store version experiment treatment localization by ID. [GET /v1/appStoreVersionExperimentTreatmentLocalizations/{id}]

Input Schema

NameRequiredDescriptionDefault
idYesID from the matching list call.
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_appStoreVersionExperimentTreatmentLocalizationsNothe fields to include for returned resources of type appStoreVersionExperimentTreatmentLocalizations Return only these attributes. A full row set can exceed 200 KB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.8.0
    • changedInput schema / properties / fields_appStoreVersionExperimentTreatmentLocalizations / items / enum
      Previous value: -[
-  "locale",
-  "appStoreVersionExperimentTreatment",
-  "appScreenshotSets",
-  "appPreviewSets"
-]New value: +[
+  "locale",
+  "appStoreVersionExperimentTreatment",
+  "appScreenshotSets",
+  "appPreviewSets",
+  "placements"
+]
    • changedInput schema / properties / include / items / enum
      Previous value: -[
-  "appStoreVersionExperimentTreatment",
-  "appScreenshotSets",
-  "appPreviewSets"
-]New value: +[
+  "appStoreVersionExperimentTreatment",
+  "appScreenshotSets",
+  "appPreviewSets",
+  "placements"
+]
  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_appStoreVersionExperimentTreatmentLocalizations
      Added value: +{
+  "description": "the fields to include for returned resources of type appStoreVersionExperimentTreatmentLocalizations Return only these attributes. A full row set can exceed 200 KB.",
+  "items": {
+    "enum": [
+      "locale",
+      "appStoreVersionExperimentTreatment",
+      "appScreenshotSets",
+      "appPreviewSets"
+    ],
+    "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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description only adds the underlying REST endpoint path — no mention of what a missing ID yields, whether sparse fieldsets affect the shape, or any auth/scoping requirement.

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?

Two short sentences with the operation front-loaded; the endpoint annotation is compact and useful for mapping to the API. No filler, though it is terse to the point of under-informing.

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?

There is no output schema, so the description carries the burden of saying what comes back — locale, related screenshot/preview sets, placements — and it says nothing. For a get tool whose value depends on the returned payload, this is the notable 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?

Schema description coverage is 100%, and the schema itself explains include and fields_* semantics (saving extra calls, 200 KB row limits). The description adds nothing beyond 'by ID', so baseline 3 applies.

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 Store version experiment treatment localization by ID'), which is unambiguous and matches the tool name. It does not, however, distinguish itself from sibling read/single-record tools or explain how it relates to the matching list call.

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?

'by ID' implies the caller must already have an ID, but the description never says where to get it (the schema does) or when to prefer this over the sibling treatment-level get or the localization list variant. Usage is implied rather than stated.

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

Deploy Server

Other Tools