Skip to main content
Glama
Sign In
appforshare-mcp

appforshare-mcp

Official
by appforshare
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Save release defaults of a store app

set_release_defaults
Idempotent

Saves per-app release defaults for App Store and Google Play—what's new text, phased rollout, Play track and percentage—inside AppForShare only, never sent to stores.

Instructions

Save the release defaults of one shared store app: whatsNew (list of { language, text }, replaces the saved list; App Store up to 4000 characters, Google Play 500), phased (App Store, true or false), playTrack and playPercent (Google Play; percent 100 = everyone, null = draft). Fields left out keep their value; null clears one. Only saved in AppForShare, never sent to a store. Ask the person first and pass confirm: true. Pro and Team, Developer role.

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": {
      "app": "<app>",
      "confirm": "<confirm>"
    },
    "name": "set_release_defaults"
  }
}

Input Schema

NameRequiredDescriptionDefault
appYesBundle id, package name or app id
storeNo
phasedNo
confirmYes
whatsNewNo
playTrackNo
playPercentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.7

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing partial-update semantics ('fields left out keep their value; null clears one'), that whatsNew replaces rather than appends, platform applicability per field, store-side length limits, and that nothing is pushed to a store. It also flags the human-confirmation requirement and plan/role restrictions, which annotations cannot express.

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 paragraph that front-loads the resource and then walks the fields, with zero filler sentences. The parenthetical style is compact, though the platform-qualifier clauses make it slightly harder to scan than a bulleted listing would be.

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 7-parameter mutation with no output schema and thin schema descriptions, this covers nearly everything an agent needs: platform scoping, null semantics, confirmation, entitlements, and the fact that saving is local-only. The only unstated piece is what a successful call returns or how errors surface.

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?

With only 14% schema description coverage the description carries most of the load: it defines whatsNew's item shape and replacement behavior, phased's App Store-only boolean nature, playTrack's Google Play scope, and playPercent's 100 = everyone / null = draft meaning. The app and store parameters are left to the schema (store only implicitly via 'App Store' vs 'Google Play' mentions), so a small gap remains.

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 ('Save the release defaults of one shared store app') and scopes it to a single app, which cleanly separates it from the read-side sibling release_defaults. An agent knows exactly what is written without opening the schema.

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 concrete preconditions: ask the person first and pass confirm: true, and the tool is limited to Pro and Team with the Developer role. It does not explicitly point at a sibling (e.g. release_defaults for reading current values), so routing guidance is clear but not exhaustive.

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