Skip to main content
Glama

What's New and listing links

optimizer_set_links
Idempotent

Sets What’s New text and listing links (Apple marketing/support/privacy; Google Play contact website/email) for the next publish, keeping omitted fields and clearing values with empty strings.

Instructions

Set What's New and the listing links written by the next publish. Apple: whatsNew, marketingUrl, supportUrl, privacyUrl for the main language (or every published language with allLanguages). Google Play: marketingUrl is the contact website, plus contactEmail. Omitted fields stay; empty strings clear. publish must be true for publish_listing to write them. Links must start with https://.

Input Schema

NameRequiredDescriptionDefault
publishNoInclude these in the next publish.
whatsNewNoApp Store What's New for the next version.
projectIdYesProject id (from get_overview).
privacyUrlNoPrivacy policy URL (Apple).
supportUrlNoSupport URL (Apple).
allLanguagesNoApple: write to every published language, not only the main one.
contactEmailNoContact email (Google Play).
marketingUrlNoMarketing URL (Google: contact website).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.7

TDQS

A4.5/5.0
Behavior5/5

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

Goes well past the annotations (which only cover readOnly=false, idempotent=true, destructive=false) by disclosing merge semantics ('Omitted fields stay; empty strings clear'), the URL format constraint, and the language-scope behavior of allLanguages. These are non-obvious mutation traits an agent cannot infer from structured fields.

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?

Dense and front-loaded with the resource and staging scope first, then platform specifics, then the caveats. The opening sentence is slightly awkward ('the listing links written by the next publish') but every sentence carries actionable 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 an 8-parameter mutation with no output schema, it covers the essentials: staging, merge/clear semantics, cross-platform field mapping, and the URL constraint. It does not describe validation failures or whether a preview is returned, but the return-value burden is lighter here and the calling guidance is sufficient.

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 adds real meaning: it maps fields to platforms (Apple: whatsNew/marketingUrl/supportUrl/privacyUrl; Google: marketingUrl as contact website plus contactEmail) and defines the empty-string-clear and https:// rules. Only minor gaps remain, such as what happens when a field is omitted for one platform only.

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?

Starts with a specific verb+resource ('Set What's New and the listing links') and immediately scopes it as staged for the next publish, which separates it from the sibling publish_listing that actually writes them. An agent can tell what is modified and when it takes effect.

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?

Explicitly states the precondition 'publish must be true for publish_listing to write them', which is the key routing rule against the write sibling. It stops short of a full when/when-not comparison, but the dependency on publish_listing is unambiguous.

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