Skip to main content
Glama
Sign In
app-publish-mcp

app-publish-mcp

by mikusnuz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

apple_submit_for_review

Creates or resumes an App Store review submission, attaches the version idempotently, and submits it while keeping the submission ID for recovery.

Instructions

Create or resume an App Store review submission, attach the version idempotently, and submit it while preserving the submission ID for safe recovery

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "appId": "<appId>",
      "versionId": "<versionId>"
    },
    "name": "apple_submit_for_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
appIdYesApp ID
platformNoPlatform of the version being submittedIOS
versionIdYesApp Store Version ID to submit
submissionIdNoExisting READY_FOR_REVIEW submission ID to resume after an interrupted call

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.7.0
    • addedInput schema / properties / appId
      Added value: +{
+  "description": "App ID",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / platform
      Added value: +{
+  "default": "IOS",
+  "description": "Platform of the version being submitted",
+  "enum": [
+    "IOS",
+    "MAC_OS",
+    "TV_OS",
+    "VISION_OS"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / submissionId
      Added value: +{
+  "description": "Existing READY_FOR_REVIEW submission ID to resume after an interrupted call",
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / properties / versionId / description
      Previous value: -"App Store Version ID"New value: +"App Store Version ID to submit"
    • addedInput schema / properties / versionId / minLength
      Added value: +1
    • changedInput schema / required
      Previous value: -[
-  "versionId"
-]New value: +[
+  "appId",
+  "versionId"
+]
  2. First observedv0.3.1

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It does add real value by disclosing idempotent attachment and preservation of the submission ID for safe recovery, which is genuinely useful mutation context. It still omits permissions, failure modes (e.g. what happens if the version is already submitted), and whether the operation is partially applied on error.

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?

A single dense sentence with the create/resume/attach/submit sequence front-loaded and no filler. It is packed but every clause maps to a real behavior, so the brevity is earned rather than under-specified.

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?

For a multi-step mutation with no annotations and no output schema, the definition explains the happy path and recovery via submissionId but leaves out the resulting state, error/rollback behavior, and how it relates to the granular submission siblings. Adequate but with clear gaps for a state-changing submission tool.

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 already documents all four parameters, including the resume semantics of submissionId. The description adds no syntax, constraints, or interpretation beyond what the schema provides; baseline 3 is appropriate.

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?

Specific verbs and resource: creates/resumes a review submission, attaches the version, and submits it. However it bundles the work of three sibling tools (apple_create_review_submission, apple_add_review_submission_item, apple_submit_review_submission) without acknowledging them, so an agent cannot tell from this text alone why it should pick the composite over the granular path.

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 phrase 'resume... after an interrupted call' implies the recovery scenario, but there is no explicit when-to-use-vs-alternatives guidance against the sibling submission tools, no prerequisite state (e.g. version must be READY_FOR_REVIEW), and no exclusions. Usage is inferable 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