Loading ToolBench
Model Context Protocol server for Apple App Store Connect API operations. Provides tools for managing apps, builds, TestFlight, subscriptions, analytics, reviews, and other ASC functionality.
ASC MCP demonstrates solid definition quality with consistently present schemas, descriptions, and parameter documentation. All 8 tools have explicit input schemas with proper type definitions and enum constraints. Descriptions are substantive and informative, particularly for the analytics tools which provide detailed guidance on report types, workflows, and data integrity constraints. Tool annotations are correctly applied. However, output schemas are not visible in the source code for most tools, and some parameter descriptions could be more actionable regarding error recovery and prerequisite steps. The server follows strong naming conventions (verb_noun pattern) and shows good parameter constraint discipline (enums, numeric ranges, regex patterns). Schema normalization logic in ToolMetadataPolicy is production-grade.
Create an App Store accessibility declaration for an app and device family. Optional support flags describe the app's accessibility capabilities.
Delete an App Store accessibility declaration.
Get one App Store accessibility declaration by ID.
List App Store accessibility declarations for an app. Returns declaration IDs, device family, publication state, support flags, and pagination info.
List accessibility declaration relationship identifiers for an app without fetching full declaration resources.
Update an App Store accessibility declaration. Boolean values set attributes; explicit null clears nullable Apple attributes.
Output schemas missing from source code for most tools. While analytics tools have output schema logic in ToolMetadataPolicy.outputSchema(), accessibility tools' return structures are not visible. LLMs cannot reliably plan downstream tool calls without knowing the exact fields returned.
Parameter descriptions lack actionable error recovery guidance. For example, accessibility_create does not explain what happens if an app_id is invalid or if a declaration already exists for that device_family. analytics_sales_report mentions size limits and cell restrictions but does not guide how to recover from oversized reports.
accessibility_create and accessibility_update descriptions do not explain prerequisites or when each tool should be called. A user might not know whether to call accessibility_create first or if accessibility_list should be used for discovery. Dependency hints are missing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2025-06-18+ | v2 |
Get a combined analytics summary for an app in a single call. Fetches 4 report types with bounded sequential processing and returns all results together. Each report is integrity-checked and limited to 64 MiB after decompression, 256 columns, 1,000,000 scanned rows, 10,000,000 scanned data cells, 100,000 matched rows, and 1,000,000 retained cells; oversized sections fail without partial summaries. Sections returned: - downloads: Units, proceeds, by country/product type (from SALES/SUMMARY/DAILY) - subscriptions: All version 1_3 standard, introductory, promotional, offer-code, and win-back active counts; marketing opt-ins, billing retry, grace period, and reported/lower-bound subscriber semantics (from SUBSCRIPTION/SUMMARY/DAILY) - subscription_events: Renewals, cancellations, trials, upgrades, downgrades (from SUBSCRIPTION_EVENT/SUMMARY/DAILY) - revenue: Per-subscriber transaction data with proceeds (from SUBSCRIBER/DETAILED/DAILY) Each section has status "success" or "error". Partial success is returned when at least one section succeeds; the tool returns an error when every section fails. Example use cases: - "How did my app do yesterday?" → analytics_app_summary with the latest available completed report date - "Show me downloads and revenue for app X" → analytics_app_summary with app_id filter
Get sales, subscription, and download reports from App Store Connect. Returns structured JSON with parsed TSV data, a report-type summary, and optional individual rows. Gzip integrity and decoded size are validated, with limits of 64 MiB decompressed, 256 columns, 1,000,000 scanned rows, 10,000,000 scanned data cells, 100,000 matched rows, and 1,000,000 retained cells; larger reports fail without returning partial summaries. Monetary summaries use Decimal accumulation, retain numeric proceeds_by_currency for compatibility, and include proceeds_by_currency_exact strings without binary floating-point loss. FIRST_ANNUAL, INSTALLS, SUBSCRIPTION_OFFER_CODE_REDEMPTION, and WIN_BACK_ELIGIBILITY use an honest row-count summary; set summary_only=false to inspect their report-specific columns. Report types and their use cases: - SALES (version 1_0): Downloads, updates, re-downloads, proceeds. Frequency: DAILY/WEEKLY/MONTHLY/YEARLY. Sub-type: SUMMARY. - SUBSCRIPTION (version 1_3): Active standard-price, free/pay-up-front/pay-as-you-go introductory, promotional, offer-code, and win-back counts, plus marketing opt-ins, billing retry, grace period, and subscriber counts. Frequency: DAILY. Sub-type: SUMMARY. Apple's Subscribers cell is blank when a record represents 3 or fewer subscriptions, so total_subscribers is retained as a compatibility alias for the reported lower bound; subscriber_rows_suppressed and total_subscribers_is_lower_bound make suppression explicit. - SUBSCRIPTION_EVENT (version 1_3): Subscriber activity — new subscriptions, renewals, upgrades, downgrades, cancellations, reactivations, refunds, conversions from trial. Frequency: DAILY. Sub-type: SUMMARY. - SUBSCRIBER (version 1_3): Transaction-level subscriber activity with anonymous Subscriber IDs, purchase dates, proceeds. Frequency: DAILY. Sub-type: DETAILED. - SUBSCRIPTION_OFFER_CODE_REDEMPTION (version 1_0): Offer code redemptions. Frequency: DAILY. Sub-type: SUMMARY. - PRE_ORDER (version 1_0): Pre-order units. Frequency: DAILY/WEEKLY/MONTHLY/YEARLY. Sub-type: SUMMARY. - INSTALLS: Monthly SUMMARY/DETAILED reports use version 1_2; yearly DETAILED and SUMMARY_CHANNEL/SUMMARY_INSTALL_TYPE/SUMMARY_TERRITORY reports default to version 1_1. - FIRST_ANNUAL (version 1_0): DAILY/DETAILED or YEARLY/SUMMARY. - WIN_BACK_ELIGIBILITY (version 1_0): DAILY/SUMMARY. Typical workflows: 1. Installs/downloads: SALES + SUMMARY + DAILY 2. Active subscribers: SUBSCRIPTION + SUMMARY + DAILY 3. Trial conversions, cancellations, renewals: SUBSCRIPTION_EVENT + SUMMARY + DAILY 4. Per-subscriber transaction history: SUBSCRIBER + DETAILED + DAILY 5. Revenue by product: SALES + SUMMARY + DAILY
next_url parameter in pagination tools (accessibility_list, accessibility_list_relationships) lacks clear documentation on exactly what it expects. The description states 'Apple continuation URL from the previous response' but does not explain whether the entire URL string should be passed as-is, how it interacts with other filters, or what happens if it becomes stale.
analytics_sales_report and analytics_app_summary have extremely detailed descriptions (>3000 chars each) that, while comprehensive, may exceed optimal token efficiency. The detailed workflow examples and edge-case documentation are valuable but could be split into inline comments or separate reference docs rather than embedded in the description.