Skip to main content
Glama
Sign In
app-store-connect-mcp

app-store-connect-mcp

by devinwang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

builds_pre_release_version_get_to_one_relationship

Fetch the pre-release version relationship for a specific build ID to identify the linked pre-release version in App Store Connect.

Instructions

GET /v1/builds/{id}/relationships/preReleaseVersion (GET /v1/builds/{id}/relationships/preReleaseVersion)

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": {
      "id": "<id>"
    },
    "name": "builds_pre_release_version_get_to_one_relationship"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesthe id of the requested resource

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

C2/5.0
Behavior2/5

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

No annotations are provided, and the description only implies a read via the GET verb. It doesn't state whether the relationship may be empty, what a null/absent linkage means, or any auth behavior expected for the relationship fetch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short, but the parenthetical merely duplicates the exact same string, so half the text is wasted rather than front-loading useful information.

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

Completeness2/5

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

For a relationship fetch with one path param and no output schema, the description should indicate what the returned linkage represents (the build's associated pre-release version). It omits this entirely, leaving return semantics unexplained.

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 coverage is 100% with a single documented 'id' parameter, so the schema carries the parameter semantics. The description adds nothing beyond the path template, matching the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is effectively just the endpoint URL repeated twice ('GET /v1/builds/{id}/relationships/preReleaseVersion'), which restates the tool name rather than explaining in plain terms that it fetches the pre-release version associated with a build. It conveys a verb (GET) and resource path but adds no interpretive meaning beyond the name.

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

Usage Guidelines1/5

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

There is no guidance on when to use this relationship endpoint versus siblings like builds_pre_release_version_get_to_one_related or pre_release_versions_get_instance. No context, prerequisites, or alternatives are provided.

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