Skip to main content
Glama
ForgeHQ-Agents

mcp-appstore-reviews

by ForgeHQ-Agents
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

mcp-appstore-reviews

A small, reviews-only MCP server for the Apple App Store, backed by the App Store Connect API. It lets an agent read customer reviews and publish or delete developer responses — and deliberately nothing else.

Why so narrow?

The capability boundary is the trust guarantee. This server exposes only the three review tools below. There is intentionally no build, release, submission, pricing, in-app-purchase, certificate, profile, or beta-tester tool, so the App Store Connect key you give it can't be used to do any of those things. Scope the key itself narrowly too (the Customer Support role is enough).

It is also dependency-free — pure Node 18+ (fetch + built-in crypto), no third-party packages — so there is no supply chain to audit beyond this one file (index.mjs).

Related MCP server: App Store Connect MCP

Tools

Tool

Description

list_reviews

List reviews for an app (newest first by default), including any existing developer response and its id. Filters: territory, rating, sort (recent/favorable/critical), limit.

respond_to_review

Publish a developer response to a review (reviewId, responseBody).

delete_review_response

Delete a developer response by its responseId (from list_reviews).

Authentication

Create an App Store Connect API key (Users and Access → Integrations → App Store Connect API). Two kinds of key work:

  • Team key — needs the Customer Support role (enough to manage reviews without Admin's broader powers), but only an Admin can generate it. Supply the Issuer ID along with the Key ID and .p8.

  • Individual key — any user can generate their own (no Admin needed) and it inherits that user's permissions. It has no Issuer ID: leave APP_STORE_CONNECT_ISSUER_ID unset and supply just the Key ID and .p8.

Then provide:

Env var

What

APP_STORE_CONNECT_ISSUER_ID

Issuer ID shown at the top of the Integrations page — team keys only; omit for individual keys

APP_STORE_CONNECT_KEY_ID

Key ID of the API key

APP_STORE_CONNECT_PRIVATE_KEY_PATH

Path to the downloaded .p8 private key file

The private key is read only to sign a short-lived ES256 JWT for Apple; it is never logged, copied, or sent anywhere but Apple's API.

Run

# stdio MCP server
APP_STORE_CONNECT_ISSUER_ID=... \
APP_STORE_CONNECT_KEY_ID=... \
APP_STORE_CONNECT_PRIVATE_KEY_PATH=/path/to/AuthKey_XXXX.p8 \
npx -y github:ForgeHQ-Agents/mcp-appstore-reviews

The agent passes the app's numeric App Store ID as appId (find it in App Store Connect → your app → App Information, or in the app's App Store URL).

Test

npm test   # node --test, zero dependencies

License

MIT

Available Tools

3 tools
delete_review_responseA

Delete an existing developer response. Takes the response id (the response.id field surfaced by list_reviews), not the review id.

ParametersJSON Schema
NameRequiredDescriptionDefault
responseIdYesThe developer-response id from list_reviews

TDQS

A4.8/5.0
Behavior4/5

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

Describes the destructive action (delete) but lacks mention of irreversibility or permissions; however, for a simple delete operation, the description is mostly adequate.

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?

Two concise sentences with no wasted words. The critical guidance is placed first.

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?

Given the tool's simplicity (one parameter, no output schema), the description covers purpose, parameter source, and usage nuance, leaving no significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage with clear description of the parameter. The description adds extra value by clarifying it is not the review id, preventing misuse.

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?

Clear verb+resource: 'Delete an existing developer response.' Distinguishes from sibling tools list_reviews and respond_to_review by focusing on deletion.

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 required parameter and warns against using the review id instead of the response id, providing clear guidance on correct usage.

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

list_reviewsA

List customer reviews for an app, newest first by default. Each review includes its id, star rating, title, body, reviewer nickname, territory, date, and the existing developer response (with its id) if one exists. Use the response id with delete_review_response.

ParametersJSON Schema
NameRequiredDescriptionDefault
appIdYesApp Store app id (the numeric Apple ID of the app)
territoryNoOptional ISO territory filter, e.g. 'USA', 'GBR'
ratingNoOptional exact star rating filter, 1–5
sortNoSort order: recent (default), favorable (highest first), critical (lowest first)
limitNoMax reviews to return, 1–200 (default 50)

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided; description carries full burden. Discloses default sort, output fields (star rating, title, body, etc.), and mention of existing developer response. Does not discuss rate limits or auth, but as a read operation, these are less critical.

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?

Three short, front-loaded sentences with zero fluff. Each sentence adds essential information: purpose, output details, and cross-reference to sibling.

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?

Given no output schema, description compensates by listing output fields. Parameter details are covered by schema. Tool is straightforward; description is complete enough for an agent to use correctly.

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%, baseline 3. Description adds value by elaborating on default sort ('newest first') and output fields, which help understand parameter effects (e.g., sort parameter).

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?

Clearly states it lists customer reviews, specifying 'for an app' and 'newest first by default'. Distinguishes from siblings by mentioning the response id can be used with delete_review_response.

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 describes the tool's purpose and links to sibling tools via response id usage. Lacks explicit when-not-to-use or alternative scenarios, but context is clear enough.

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

respond_to_reviewA

Publish a public developer response to a customer review. One response per review — if the review already has a response, delete it first with delete_review_response, then respond again.

ParametersJSON Schema
NameRequiredDescriptionDefault
reviewIdYesThe review id from list_reviews
responseBodyYesThe response text to publish

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, so description carries the burden. It discloses the publish operation, the one-response limit, and the need to delete first. However, it does not mention potential moderation, character limits, or visibility latency. Still, it adds significant context beyond a simple 'publish'.

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?

Two sentences, front-loaded with purpose, followed by a key usage constraint. No extraneous information. Every sentence earns its place.

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 simple mutation with 2 params and no output schema, the description covers the main usage context (publish, one-per-review, deletion prerequisite). Missing details like return value (success/error), permissions, or public visibility timeline. Adequate but not exhaustive.

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 descriptions already explaining each parameter. The description adds minimal additional meaning for the parameters: it clarifies that reviewId comes from list_reviews and responseBody is the text. This does not significantly enhance understanding beyond the schema.

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?

Description clearly states the verb 'Publish' and the resource 'public developer response to a customer review'. It distinguishes from sibling tools 'delete_review_response' and 'list_reviews' by explicitly mentioning the one-response-per-review constraint.

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?

Provides explicit guidance: use only if no existing response, otherwise delete first using delete_review_response. Names the alternative tool and gives a clear procedural step.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observeddelete_review_response
    • First observedlist_reviews
    • First observedrespond_to_review
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: listing reviews, responding to a review, and deleting a response. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (list_reviews, respond_to_review, delete_review_response).

Tool Count5/5

Three tools cover the essential operations for app store review responses: list, respond, and delete. The count is well-scoped for this domain.

Completeness4/5

Covers the full lifecycle of review responses (read, create, delete). Minor gap: no direct update for a response (requires delete+create), but the documentation clarifies the intended workflow.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers