Which integrations are available for this server?

Access App Store Connect data for listing apps, analytics, sales reports, app versions, downloads summary, and customer reviews. Retrieve official App Store ratings and review metadata via the iTunes Lookup API.

How do I use App Store Connect MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@App Store Connect MCP Server List my apps on App Store Connect" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

App Store Connect MCP Server

by Fourni-j

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Unofficial App Store Connect MCP Server

An MCP server that gives AI assistants structured access to App Store Connect data. Built for ASO (App Store Optimization) analysis, download tracking, and performance monitoring.

The server returns agent-friendly JSON with natural-language summaries, pre-computed aggregations, and conversion rates — so an AI agent can interpret App Store data without needing domain-specific knowledge of Apple's raw report formats.

Related MCP server: asc-mcp

Quick Start

Prerequisites

You need an App Store Connect API key. Create one at App Store Connect > Users and Access > Integrations > App Store Connect API.

Install

git clone https://github.com/Fourni-j/appstore-connect-MCP.git
cd appstore-connect-MCP
npm install
npm run build

Configure your MCP client

Add to your MCP client config (e.g., claude_desktop_config.json):

{
  "mcpServers": {
    "appstore-connect": {
      "command": "node",
      "args": ["/path/to/appstore-connect-MCP/dist/index.js"],
      "env": {
        "ASC_KEY_ID": "your-key-id",
        "ASC_ISSUER_ID": "your-issuer-id",
        "ASC_PRIVATE_KEY_PATH": "/path/to/AuthKey_XXXX.p8",
        "ASC_VENDOR_NUMBER": "your-vendor-number"
      }
    }
  }
}

Environment Variables

Variable	Required	Description
`ASC_KEY_ID`	Yes	API key ID from App Store Connect
`ASC_ISSUER_ID`	Yes	Issuer ID from App Store Connect
`ASC_PRIVATE_KEY_PATH`	Yes	Path to the `.p8` private key file
`ASC_VENDOR_NUMBER`	For sales/downloads	Vendor number from Payments and Financial Reports

First command

Ask your AI assistant:

"List my apps on App Store Connect"

Tools

list_apps

List all apps in the account. Returns each app's id, name, bundleId, and sku. The returned id is used as appId in all other tools.

Parameters: limit (optional, default 50, max 200)

get_app_metadata

Get localized metadata: title, subtitle, keywords, description, and promotional text for all locales. Useful for ASO review.

Parameters: appId (required)

get_analytics_report

Get analytics data for an app across five categories:

Category	Metrics
`APP_STORE_ENGAGEMENT`	Impressions, page views, taps, conversion rates
`COMMERCE`	Downloads by type, device, territory
`APP_USAGE`	Sessions, active devices
`FRAMEWORK_USAGE`	Framework adoption
`PERFORMANCE`	Crashes, launch time

Returns aggregated data per period by default, with totals and breakdowns by source/device/territory. For engagement, COMMERCE download data is automatically merged, including the conversion rate (Total Downloads / Unique Impressions) matching App Store Connect's definition exactly.

Set raw: true for granular per-territory/device/OS rows.

Always specify granularity (DAILY or MONTHLY). Without it, Apple mixes monthly and daily instances. MONTHLY covers completed months only; DAILY covers recent days. For a full picture, make two calls.

Parameters: appId (required), category (required), granularity (optional but recommended), startDate (optional), endDate (optional), raw (optional), limit (optional)

get_sales_report

Download and parse sales/installs reports as structured JSON. Apple's raw TSV column names are mapped to readable camelCase keys. Each row includes a productTypeLabel with a human-readable description.

Parameters: reportType (required), reportSubType (required), frequency (required), vendorNumber (optional — falls back to ASC_VENDOR_NUMBER), reportDate (optional)

get_app_store_versions

List app versions with their App Store state (READY_FOR_SALE, IN_REVIEW, etc.), creation date, and platform. Useful for correlating releases with metric changes.

Parameters: appId (required), limit (optional, default 10, max 50)

get_downloads_summary

Get first-time download counts aggregated by period. Automatically uses daily granularity for ranges under 32 days, monthly otherwise. Only counts new installs (excludes updates, re-downloads, IAPs, and subscriptions).

Parameters: appId (required), startDate (optional), endDate (optional)

get_customer_reviews

Get customer reviews and ratings for an app. Returns individual written reviews with aggregated statistics (average rating, star distribution), plus the official App Store rating from the iTunes Lookup API.

The App Store rating includes all ratings (silent star taps + written reviews) and varies by country — set storeCountry to get the rating for a specific market.

Parameters: appId (required), rating (optional, 1-5), territory (optional, 3-letter code like USA, FRA), sort (optional, default -createdDate), startDate (optional), endDate (optional), storeCountry (optional, 2-letter ISO code, default US), limit (optional, default 500, max 1000)

How Analytics Reports Work

Analytics reports use Apple's asynchronous reporting flow. This is different from the other tools — it doesn't return data from a single API call.

The flow:

Report request — The server creates an ONGOING analytics report request for your app
Report generation — Apple processes the request and produces report instances (one per time period)
Segment download — Each instance contains segments (gzipped TSV files) that the server downloads and parses

First-time setup: The very first call for a given app creates the report request and returns a "pending" status. Apple needs time (typically a few hours, sometimes up to 24h) to generate the initial reports. Subsequent calls return data immediately.

Why it can be slow: Even after initial setup, fetching analytics involves multiple chained API calls. For large date ranges with many instances, this can take 10-30 seconds.

See Apple's Analytics Reports documentation for the full API reference.

Response Format

All tools return JSON with an agent-friendly structure:

{
  "summary": "APP_STORE_ENGAGEMENT analytics from 2026-02-01 to 2026-02-28: 28 periods...",
  "status": "ready",
  "granularity": "daily",
  "dateRange": { "from": "2026-02-01", "to": "2026-02-28" },
  "totals": { "Impression": 50000, "Page view": 8000, "Tap": 3200 },
  "uniqueTotals": { "Impression": 40000, "Page view": 7000, "Tap": 2800 },
  "conversionRates": {
    "tapRate (Unique Taps / Unique Impressions)": "7.00%",
    "pageViewRate (Unique Page Views / Unique Impressions)": "17.50%",
    "conversionRate (Total Downloads / Unique Impressions)": "4.50%"
  },
  "downloads": {
    "totalDownloads": 1800,
    "firstTimeDownloads": 1500,
    "redownloads": 300,
    "updates": 500
  },
  "periods": [
    {
      "date": "2026-02-01",
      "counts": { "Impression": 1800, "Page view": 290, "Tap": 115 },
      "uniqueCounts": { "Impression": 1400, "Page view": 250, "Tap": 100 },
      "conversionRates": { "...": "..." },
      "bySource": { "App Store Browse": 900, "App Store Search": 700 },
      "byDevice": { "iPhone": 1400, "iPad": 400 },
      "downloads": { "totalDownloads": 60, "firstTimeDownloads": 50, "redownloads": 10 }
    }
  ]
}

{
  "summary": "DAILY SALES/SUMMARY report for 2026-02-15: 12 rows.",
  "totalRows": 12,
  "truncated": false,
  "data": [
    {
      "title": "My App",
      "sku": "com.example.myapp",
      "units": "5",
      "customerPrice": "0",
      "productType": "1",
      "productTypeLabel": "Free or Paid App (Universal)",
      "countryCode": "US",
      "device": "iPhone"
    }
  ]
}

{
  "summary": "App Store rating (US): 4.58 from 178 ratings. 42 written reviews (avg 3.26). Distribution: 5★=16, 4★=10, 3★=8, 2★=3, 1★=5.",
  "appId": "123",
  "storeRating": {
    "averageRating": 4.58,
    "ratingCount": 178,
    "currentVersionAverageRating": 4.58,
    "currentVersionRatingCount": 178
  },
  "totalReviews": 42,
  "averageRating": 3.26,
  "ratingDistribution": { "1": 5, "2": 3, "3": 8, "4": 10, "5": 16 },
  "truncated": false,
  "reviews": [
    {
      "id": "review-id",
      "rating": 5,
      "title": "Great app!",
      "body": "Love the barcode scanning feature.",
      "reviewerNickname": "user123",
      "territory": "USA",
      "createdDate": "2026-03-01T00:00:00Z"
    }
  ]
}

{
  "error": "ASC_VENDOR_NUMBER environment variable is not set. Find your vendor number in App Store Connect > Payments and Financial Reports."
}

Error responses also set isError: true on the MCP result object.

Local Testing

Run tool handlers directly against the real App Store Connect API:

# Set environment variables first
export ASC_KEY_ID="your-key-id"
export ASC_ISSUER_ID="your-issuer-id"
export ASC_PRIVATE_KEY_PATH="/path/to/AuthKey_XXXX.p8"
export ASC_VENDOR_NUMBER="your-vendor-number"

# Run all tools
npx tsx scripts/test-tools.ts

# Run a specific tool
npx tsx scripts/test-tools.ts list-apps
npx tsx scripts/test-tools.ts get-analytics-report
npx tsx scripts/test-tools.ts get-customer-reviews

Development

npm run build        # Compile TypeScript
npm test             # Run tests (94 tests)
npm run test:watch   # Watch mode
npm start            # Start the MCP server

Contributing

Contributions are welcome. Please open an issue first to discuss what you'd like to change.

License

MIT License — see LICENSE for details.

Available Tools

7 tools

get_analytics_reportA

Get analytics report data for an app. Categories: APP_STORE_ENGAGEMENT (impressions, page views), COMMERCE (purchases, sales), APP_USAGE (sessions, active devices), FRAMEWORK_USAGE, PERFORMANCE (crashes, launch time). Returns aggregated metrics by default (totals + breakdown by source, device). Set raw=true for granular per-territory/device/OS rows. IMPORTANT: always set granularity (DAILY or MONTHLY) — without it, Apple returns a mix of monthly and daily instances which is misleading. MONTHLY only covers completed months; DAILY only covers recent days (Apple rolls up older daily data into monthly). To get a full picture spanning past months and the current month, make two calls: one MONTHLY and one DAILY. Requires appId from list_apps.

ParametersJSON Schema

Name	Required	Description
`raw`	No	If true, return raw rows instead of aggregated summary. Default false.
`appId`	Yes	App Store Connect app ID (from list_apps)
`limit`	No	Max raw rows to return when raw=true (default 500)
`endDate`	No	End date (YYYY-MM-DD)
`category`	Yes	Analytics report category
`startDate`	No	Start date (YYYY-MM-DD)
`granularity`	No	Report granularity. Always specify this — DAILY for recent days, MONTHLY for older data. Without it, Apple mixes monthly and daily instances together.

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: default aggregated metrics, effect of raw=true, behavior of granularity (monthly vs daily), and the misleading mix without it. It also notes the return type differences and prerequisites.

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?

The description is well-structured and front-loaded with the main purpose. However, it is a bit lengthy; a slightly more concise presentation while retaining all critical information could improve it.

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 complexity (7 parameters, no output schema, no annotations), the description covers all necessary aspects: how to use, pitfalls, required inputs, and data nuances. It is fully complete for an AI agent to select and invoke the tool correctly.

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?

Despite 100% schema coverage, the description adds substantial meaning beyond the input schema: explains the raw parameter's effect, clarifies the importance and semantics of granularity, and provides context for dates. This greatly aids the agent in correctly invoking the tool.

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?

The description clearly states that this tool retrieves analytics report data for an app and lists specific categories (APP_STORE_ENGAGEMENT, COMMERCE, etc.), which differentiates it from sibling tools like get_downloads_summary and get_sales_report.

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 on always setting granularity, explains the two-call strategy for full data, mentions required appId from list_apps, and warns against omitting granularity. This far exceeds the minimum requirement for usage guidelines.

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

get_app_metadataA

Get localized metadata for an app: title, subtitle, keywords, description, and promotional text for all locales. Useful for ASO review. Requires appId from list_apps.

ParametersJSON Schema

Name	Required	Description	Default
`appId`	Yes	App Store Connect app ID (from list_apps)

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Does not disclose whether tool is read-only, idempotent, requires authentication, or has rate limits. Only implies a read operation through naming and description.

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 contain all essential information: purpose, fields, use case, and prerequisite. No extraneous text.

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 one parameter and no output schema, the description adequately covers the tool's function. Missing details about output format or locale behavior, but overall complete for its simplicity.

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?

Only one parameter (appId) with schema description stating 'App Store Connect app ID (from list_apps)'. The description mentions this prerequisite, adding slight context beyond the schema, but schema coverage is already 100%.

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 the verb 'Get' and the resource 'localized metadata for an app', enumerating specific fields (title, subtitle, etc.) and providing use case (ASO review). Distinguishes from sibling 'list_apps' by requiring its output as input.

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?

Provides explicit context for use ('ASO review') and prerequisite ('Requires appId from list_apps'). However, does not explicitly state when not to use or mention alternatives among siblings.

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

get_app_store_versionsB

List app versions with their App Store state (READY_FOR_SALE, IN_REVIEW, etc.), creation date, and platform. Useful to correlate releases with metric changes. Requires appId from list_apps.

ParametersJSON Schema

Name	Required	Description	Default
`appId`	Yes	App Store Connect app ID (from list_apps)
`limit`	No	Max number of versions to return

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It implies read-only via 'List' but does not explicitly state that, nor does it mention authorization needs, error behavior, or rate limits. The limit parameter's behavior is not elaborated.

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?

The description is brief with two sentences, front-loading the core purpose. It is efficient, though could be more structured with separate usage and output sections.

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

Completeness3/5

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

Given the lack of an output schema and annotations, the description partially covers what the tool returns (state, date, platform) but omits details on response structure, pagination, and error handling. It is adequate for basic use 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 for both parameters. The description adds value by indicating the source of appId ('from list_apps'), but does not enhance the limit parameter beyond what the schema already provides.

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?

The description clearly states the tool lists app versions with specific fields (state, date, platform) and specifies the source for the required appId. It is distinct from sibling tools which focus on analytics, metadata, or reviews.

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?

The description gives a use case ('correlate releases with metric changes') and notes the prerequisite (appId from list_apps), but does not provide guidance on when not to use this tool or compare to alternatives.

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

get_customer_reviewsA

Get customer reviews and ratings for an app. Returns individual written reviews with aggregated rating statistics (average rating, star distribution). Also fetches the official App Store rating (average + count) from the iTunes Lookup API — set storeCountry (2-letter ISO code, default 'US') to get ratings for a specific country. Written reviews can be filtered by star rating, territory (3-letter code like 'USA', 'FRA'), and date range. Sorted by newest first by default. Requires appId from list_apps.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	Sort order (default: -createdDate, newest first)	-createdDate
`appId`	Yes	App Store Connect app ID (from list_apps)
`limit`	No	Max reviews to fetch (default 500, max 1000)
`rating`	No	Filter by star rating (1-5)
`endDate`	No	Filter reviews on or before this date (YYYY-MM-DD)
`startDate`	No	Filter reviews on or after this date (YYYY-MM-DD)
`territory`	No	Filter by territory code (e.g. 'USA')
`storeCountry`	No	ISO 2-letter country code for App Store rating lookup (default 'US'). Ratings vary by country.	US

TDQS

A4.3/5.0

Behavior4/5

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

Discloses behavior: returns written reviews, aggregated stats, fetches iTunes rating, supports filtering by rating/territory/date, default sorting, and limit. No annotations provided, so description carries burden effectively.

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?

Multiple sentences, each adding value. Structure is front-loaded with main purpose. Could be slightly more concise but not wasteful.

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?

Fairly complete given 8-param tool with no output schema. Covers sources, filtering, sorting, prerequisite. Lacks pagination details but limit implies single request. Adequate.

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%, but description adds context: explains storeCountry's purpose (iTunes Lookup API), territory as 3-letter code, and default sorting. Enhances understanding beyond 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 it retrieves customer reviews and ratings, including aggregated statistics and iTunes API ratings. Differentiates well from sibling tools like list_apps and analytics tools.

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?

States prerequisite appId from list_apps and describes various filtering options. Does not explicitly compare to siblings, but purpose is distinct. Could mention when not to use.

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

get_downloads_summaryA

ParametersJSON Schema

Name	Required	Description
`appId`	Yes	App Store Connect app ID (Apple Identifier, from list_apps)
`endDate`	No	End date (YYYY-MM-DD). Defaults to today.
`startDate`	No	Start date (YYYY-MM-DD). Defaults to 3 months ago.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses granularity logic (daily for <32 days, monthly otherwise) and exclusion criteria for download types. Does not describe error handling or rate limits, but coverage is good for a simple query tool.

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?

Four sentences, each serving a distinct purpose: purpose, granularity, count scope, and requirements. No redundant or unnecessary information; highly efficient.

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

Completeness3/5

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

Given no output schema, the description does not explain the return format or fields of the summary. It covers purpose, parameters, and behaviors, but lacks detail on response structure, which is a gap.

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%. Description adds value by specifying default values for startDate (3 months ago) and endDate (today), and clarifying that appId comes from list_apps. This enhances understanding beyond schema descriptions.

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 the tool gets first-time download counts aggregated by period. Distinguishes from siblings like get_sales_report by specifying it only counts new installs, excluding updates, re-downloads, and IAPs.

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?

Provides clear guidance on what the tool counts (new installs only) and requirements (ASC_VENDOR_NUMBER env var, appId from list_apps). However, it does not explicitly list when not to use it or compare to all siblings.

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

get_sales_reportA

Download and parse App Store Connect sales/installs reports. Returns structured rows with fields: title, units, customerPrice, developerProceeds, countryCode, device, productType, etc. Vendor number is auto-resolved from ASC_VENDOR_NUMBER env var if not provided.

ParametersJSON Schema

Name	Required	Description
`frequency`	Yes	Report frequency
`reportDate`	No	Report date (YYYY-MM-DD). Defaults to most recent available.
`reportType`	Yes	Type of report
`vendorNumber`	No	Vendor number from App Store Connect. If omitted, uses the ASC_VENDOR_NUMBER environment variable.
`reportSubType`	Yes	Report sub-type

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden. It discloses that the tool returns structured rows with specific fields and auto-resolves vendor numbers from environment variables. However, it does not mention important behavioral traits like authentication needs, rate limits, or whether it is read-only.

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?

The description is two sentences, front-loading the core purpose and output, then adding a key detail about vendor number. Every sentence earns its place with no wasted words.

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 the complexity (5 parameters, 3 required, 3 enums) and absence of an output schema, the description compensates by listing common output fields. It could mention default date behavior, but it is largely complete.

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. The description adds value by explaining the vendor number auto-resolution from environment variables and listing output fields, which are not in 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?

The description uses a specific verb ('Download and parse') and resource ('App Store Connect sales/installs reports'), clearly distinguishing it from sibling tools like 'get_analytics_report' or 'get_downloads_summary'. It also lists output fields, reinforcing its purpose.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions automatic vendor number resolution but does not state prerequisites, limitations, or when not to use it.

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

list_appsA

List all apps in the App Store Connect account. Returns each app's id, name, bundleId, and SKU. Use the returned id as appId in all other tools.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max number of apps to return

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does not disclose pagination behavior or the effect of the 'limit' parameter; the phrase 'List all apps' conflicts with a limit parameter that defaults to 50, implying incomplete listing. No read-only hint is given.

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 concise sentences with no fluff. The purpose is stated first, followed by return fields and usage guidance. 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?

Given no output schema, the description explains return fields and the important usage of the ID. However, it lacks details about pagination, limit behavior, and potential empty results. Otherwise, it is fairly complete for a simple list tool.

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?

The input schema already describes the 'limit' parameter with default, min, max, and type (100% coverage). The description does not add additional semantic meaning 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?

The description clearly states 'List all apps in the App Store Connect account' and specifies the returned fields (id, name, bundleId, SKU). This distinguishes it from sibling tools which focus on analytics, metadata, versions, reviews, etc.

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?

The description provides clear guidance: 'Use the returned id as appId in all other tools.' This implies it is the entry point for obtaining app IDs, though it could explicitly state to use this tool first.

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.

7 tool updatesv0.1.0Jul 13, 2026
- First observedget_analytics_report
- First observedget_app_metadata
- First observedget_app_store_versions
- First observedget_customer_reviews
- First observedget_downloads_summary
- First observedget_sales_report
- First observedlist_apps

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.2/5.0

Scored 2026-07-13 12:05 across 7 tools

Disambiguation5/5

Each tool targets a distinct aspect of App Store Connect data: app listing, analytics, metadata, versions, reviews, downloads, and sales. There is no overlap in functionality; descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: 'get_' for specific data retrieval and 'list_' for enumeration. The pattern is predictable and uniform.

Tool Count5/5

Seven tools cover the essential read-only operations for an App Store Connect server. The count is well-scoped, covering key data categories without being overwhelming.

Completeness5/5

The tool set provides comprehensive coverage for retrieving app data: analytics, metadata, versions, reviews, downloads, and sales. There are no obvious gaps given the read-only scope.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
ChrysaiOAuth
com.chrysai.www
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Data Platforms Developer Tools App Automation
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

App Store MCP Server
E-commerce & Retail Search Research & Data
LaurMost
A
license
A
quality
A
maintenance
An open-source MCP server for live Apple App Store competitor research, enabling AI agents to search apps, fetch metadata, compare competitors, and retrieve reviews and top charts as structured JSON.
Updated 2 months ago (2026-07-10 16:48 UTC)
7
MIT
asc-mcp
Developer Tools Marketing
Hiru-ge
A
license
B
quality
C
maintenance
An unofficial MCP server for the App Store Connect API that enables automation of app management, reviews, TestFlight, analytics, and release processes through natural language.
Updated 2 months ago (2026-07-16 14:00 UTC)
63
52 npm
2
MIT
ASO-Copilot
Marketing Search
Aero25x
A
license
Not graded
quality
B
maintenance
MCP server for managing App Store Optimization: add apps, track keywords, pull health reports, spy on competitors, find keyword opportunities, and write AI copy suggestions.
Updated 2 months ago (2026-07-29 12:55 UTC)
5
MIT
ASOHawk
Marketing Research & Data
prodocik
F
license
Not graded
quality
B
maintenance
MCP server for App Store Optimization, enabling AI agents to read rankings, keywords, competitors, reviews, and revenue, and manage metadata with human approval.
Updated 9 days ago (2026-09-06 12:49 UTC)
11
-

Unofficial App Store Connect MCP Server

Table of Contents

Quick Start

Prerequisites

Install

Configure your MCP client

Environment Variables

First command

Tools

list_apps

get_app_metadata

get_analytics_report

get_sales_report

get_app_store_versions

get_downloads_summary

get_customer_reviews

How Analytics Reports Work

Response Format

Local Testing

Development

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers