Skip to main content
Glama
yuraist

App Store Connect MCP Server

by yuraist
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

submit_for_review

Destructive

Submits an app version for App Store review by resolving or reusing a draft submission, attaching the version, and setting it submitted; use the returned submission ID to resume after failures.

Instructions

Submit an app version for App Store review: resolve/reuse a draft submission, attach the version and set submitted=true. Separate from TestFlight beta review. On failure inspect and resume the returned submission ID.

Input Schema

NameRequiredDescriptionDefault
appIdYesThe App Store Connect app ID
platformNoPlatform to submit for
versionIdNoExplicit app version ID; otherwise resolves one editable version
submissionIdNoExisting draft submission ID to resume

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / submissionId
      Added value: +{
+  "description": "Existing draft submission ID to resume",
+  "type": "string"
+}
    • addedInput schema / properties / versionId
      Added value: +{
+  "description": "Explicit app version ID; otherwise resolves one editable version",
+  "type": "string"
+}
  2. First observedv0.1.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare the risky profile (destructiveHint=true, idempotentHint=false, openWorldHint=true); the description adds real value beyond that by exposing the multi-step internal flow (resolve/reuse draft, attach version, set submitted=true) and a failure/resume path. It still doesn't say what is irreversible about a submission, e.g. that review is queued and the submitted flag cannot simply be un-set.

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 dense sentences with zero filler, front-loading the action and followed by the disambiguation and failure path in priority order. Nothing could be cut without losing information.

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 mutation tool with no output schema but full annotation coverage, the description covers purpose, sibling disambiguation, internal steps, and recovery. Missing only the consequences of a successful submit (locked state, review queue timing) that would let an agent warn the user before acting.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by explaining where submissionId comes from ("resume the returned submission ID") — an output-to-input relationship the schema doesn't state. The versionId/platform interaction is left to the schema's own descriptions.

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?

States a specific verb and resource ("Submit an app version for App Store review") plus the internal mechanics (resolve/reuse draft submission, attach version, set submitted=true). It explicitly distinguishes itself from submit_beta_review ("Separate from TestFlight beta review"), which is the nearest-sounding sibling.

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

Usage Guidelines4/5

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

Gives an explicit when-not (TestFlight beta review is the other path) and a recovery rule ("On failure inspect and resume the returned submission ID"). It stops short of naming the exact recovery tool (get_review_submission) or stating preconditions such as the version needing to be in an editable state.

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