Skip to main content
Glama

Publish listing to the store

publish_listing
Destructive

Publishes an owner-approved app listing and all ready locale drafts to App Store Connect or Google Play Console after explicit confirmation, making changes live to real users.

Instructions

DESTRUCTIVE / LIVE: pushes the chosen listing and every ready locale draft to App Store Connect or Google Play Console, changing what real users see. Only call after the owner has reviewed the exact listing text and explicitly told you to publish in this conversation; never on your own initiative and never as part of a larger plan they approved in general terms. Requires a connected console. The app then shows the owner a confirmation dialog listing the store, app, version, locales and fields; nothing is published unless they click Publish there (no answer within ~2 minutes = denied, error code not_approved). Background job once approved; follow with wait_for_jobs and report the outcome.

Input Schema

NameRequiredDescriptionDefault
approvalYesQuote the owner's explicit go-ahead.
projectIdYesProject id (from get_overview).
ownerApprovedYesMust be true: the owner explicitly approved publishing this listing.
versionStringNoApp version to attach the listing to (see get_next_version); default: the app's suggestion.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.7

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the in-app confirmation dialog, what the owner sees there (store, app, version, locales, fields), the ~2 minute timeout, the resulting not_approved error code, and that publishing happens as a background job. These are non-obvious behaviors an agent could not infer from destructiveHint/openWorldHint alone.

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?

Front-loaded with the "DESTRUCTIVE / LIVE" label, then preconditions, then mechanics, then next step. Despite its length, every sentence carries operational weight for a high-risk irreversible tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description covers the async job model, the failure code, and the follow-up tool to call. Nothing critical is missing for an agent to safely invoke and then verify this destructive operation.

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 projectId, ownerApproved, approval, and versionString are all documented in the schema. The description reinforces the approval intent but adds no new syntax or format meaning beyond what the schema already provides, so the baseline of 3 applies.

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?

"DESTRUCTIVE / LIVE: pushes the chosen listing and every ready locale draft to App Store Connect or Google Play Console" names the exact verb, resource, and target systems. It clearly distinguishes this from read-only siblings like get_publish_preview by stating that it changes what real users see.

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

Usage Guidelines5/5

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

Explicitly states the when ('only call after the owner has reviewed the exact listing text and explicitly told you to publish in this conversation') and the when-not ('never on your own initiative and never as part of a larger plan they approved in general terms'). It also names the prerequisite (connected console) and the required follow-up (wait_for_jobs).

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