Skip to main content
Glama
Sign In
appforshare-mcp

appforshare-mcp

Official
by appforshare
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Saved release defaults of store apps

release_defaults
Read-only

Retrieve saved release defaults for shared App Store and Google Play apps, including What's New per language, phased release, and Google Play track/rollout settings. They only prefill release forms.

Instructions

Saved release defaults of the shared App Store and Google Play apps: What's New per language, phased release on or off (App Store), and the Google Play track and rollout percent used when promoting. They only fill in forms; nothing is sent to a store from them. Without app, every shared app. Read only. Pro and Team.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "release_defaults"
  }
}

Input Schema

NameRequiredDescriptionDefault
appNoBundle id, package name or app id from release_status (optional)
storeNoOnly when the same bundle id is on both stores

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.7

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it explains these values are inert form prefill data that never reach a store, and it discloses a 'Pro and Team' plan restriction, which annotations do not convey.

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?

Four short sentences, front-loaded with the resource and its contents, followed by scope and behavioral caveats. Dense but every sentence carries information; 'Pro and Team' is terse but decipherable as a plan gate.

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?

With no output schema, the description carries the burden of describing what comes back, and it does so by enumerating the stored fields per store. The only gap is the return shape (single object vs. list when no app is given), which the agent must infer from 'Without app, every shared app.'

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 would be 3, but the description adds the meaning of omitting the optional app parameter ('every shared app'), which the schema does not state. The store enum's disambiguation condition is left to the schema, which already covers it.

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?

The description names the resource precisely (saved release defaults for shared App Store and Google Play apps) and enumerates its contents: What's New per language, phased release, Google Play track and rollout percent. It is clearly a read-side counterpart to set_release_defaults, though it never names that sibling explicitly.

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?

It clarifies intent ('they only fill in forms; nothing is sent to a store') and the no-app default ('every shared app'), which helps an agent understand when this is the right call. However, it never states when to prefer set_release_defaults or that this should precede a promotion, so the when/when-not routing is only implied.

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