Skip to main content
Glama
Sign In
erayendes

Heimdall App Store Connect MCP

by erayendes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

app_store_version_experiment_treatment_localizations__create

Create a localization for a specific App Store version experiment treatment. Use this function to define translated assets and localized content for your A/B test setups within App Store Connect.

Instructions

Create an App Store version experiment treatment localization. [POST /v1/appStoreVersionExperimentTreatmentLocalizations]

Input Schema

NameRequiredDescriptionDefault
bodyYesJSON:API request body (Apple schema: AppStoreVersionExperimentTreatmentLocalizationCreateRequest).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.8.0
    • addedInput schema / properties / body / properties / data / properties / relationships / properties / placements
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "id": {
+            "type": "string"
+          },
+          "type": {
+            "enum": [
+              "appAssetLibraryPlacements"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "type"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.3.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so safety behavior is covered. The description adds the POST endpoint but no extra context such as whether the parent treatment must exist or what the created localization affects, leaving it at minimum viable.

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 clear sentence plus the endpoint, with no wasted text. The operation and HTTP route are front-loaded and easy to scan.

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 input schema fully documents the nested body, including the required treatment relationship and locale attribute, and annotations cover mutation behavior. However, for a complex create operation with no output schema, the description could say more about required relationships or expected outcome, making it minimally complete rather than rich.

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%, including a description of the JSON:API body. The description adds no parameter meaning beyond naming the operation, so baseline 3 is appropriate when the schema already 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 states a specific verb and resource: 'Create an App Store version experiment treatment localization,' and the endpoint confirms the exact API operation. It is immediately distinguishable from sibling get/list/delete/update tools for the same resource.

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 verb 'Create' implies usage, but there is no explicit guidance on when to use this versus the localization get/list/delete tools or when a treatment must already exist. Usage is inferable but not spelled out.

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