app-store-connect-mcp

Apple の2つのコマースAPI ― App Store Connect（1,263 操作）と App Store Server API / StoreKit 2（30 操作）― を、5つのツールの背後で、秘密鍵は macOS キーチェーンに保管し、結果に影響を与える書き込みは明示的な確認を経て実行する MCP サーバーです。

1,293 operations · 5 tools · key never on disk · verified against the live APIs

このように構築した理由

App Store Connect の MCP サーバーはいくつか存在します。それぞれが問題の一部を解決しています。本サーバーは、それぞれの正しかった部分を取り入れ、間違っていた部分を排除しました。

本サーバーは3つ目の方法を採用しています。カバレッジは Apple の仕様の性質に依存し、誰かが何個のエンドポイントをラップしたかには依存しません。また、モデルは価格を変更できるプロセス内でコードを実行することは決してありません。

サンドボックスについて

コードモードの前提は、生成された JavaScript が Node の vm 内で安全に実行されるというものです。しかし、それは正しくありません。Node 自身のドキュメントでは、vm はセキュリティ機構ではないと述べており、グローバルとして注入されたホストオブジェクトは、自身のプロトタイプチェーンを介してホストレルムを戻してしまいます。

spec.constructor.constructor('return process.env.HOME')()   // → /Users/you

そのサンドボックスの忠実な再現に対して検証した結果、ホスト環境を返すことが確認されました。timeout オプションも役に立ちません。これは同期的な実行のみを制限するため、async のビジーループは永久に実行され、イベントループを枯渇させます。

パラメータ化されたディスパッチは、同じカバレッジとトークンコストを実現し、エスケープされるインタプリタを必要としません。

Related MCP server: App Store Connect MCP Server

認証情報

秘密鍵はキーチェーンに属します。Apple は .p8 を一度だけダウンロードさせます。ディスク上の平文のコピーは漏洩の可能性があるコピーです。

ASC_KEY=keychain:my-asc-key          # recommended
ASC_KEY=/path/to/AuthKey.p8          # works, but plaintext
ASC_PRIVATE_KEY='-----BEGIN…'        # discouraged: `ps -E` exposes it

キーチェーンアイテムは、裸の PEM または base64 JSON を保持できます。

{ "issuerID": "…", "keyID": "…", "privateKeyPEM": "-----BEGIN PRIVATE KEY-----\n…" }

エンベロープ形式が推奨されます。識別子が鍵素材と一緒に移動するため、ASC_KEY_ID がそれが示す鍵と同期しなくなることがありません。この不一致は、不透明な 401 としてのみ表面化します。

security add-generic-password -s my-asc-key -a api -w "$(
  jq -nc --arg i "$ISSUER" --arg k "$KEYID" --arg p "$(cat AuthKey.p8)" \
    '{issuerID:$i,keyID:$k,privateKeyPEM:$p}' | base64
)"

インストール

git clone https://github.com/abd3lraouf-studios/app-store-connect-mcp
cd app-store-connect-mcp
npm install && npm run build

{
  "mcpServers": {
    "app-store-connect": {
      "command": "node",
      "args": ["/path/to/app-store-connect-mcp/dist/index.js"],
      "env": {
        "ASC_KEY": "keychain:my-asc-key",
        "ASC_BUNDLE_ID": "com.example.app"
      }
    }
  }
}

ASC_BUNDLE_ID は、App Store Server API 呼び出しにのみ必要です。Apple は bid クレームなしの Server API トークンを拒否します。

ツール

読み取りと書き込みは別々のツールです。なぜなら、Claude Code は標準の destructiveHint アノテーションを無視しますが、_meta["anthropic/requiresUserInteraction"] は尊重するからです。そして、そのフラグはツールごとに設定されます。単一のディスパッチャでは操作ごとにこれを変えることができません。asc_write はこのフラグを持つため、bypassPermissions 下でもユーザーにプロンプトを表示します。これは、--no-confirm でオフにできるプロセス内ゲートよりも強力な保証です。

リソース

モデルが @asc: を使って意図的に取得できる参考資料:

インラインで返すには大きすぎる結果は切り捨てられません。リストは収まるサイズにトリミングされ、その切り捨てがリクエストの絞り方とともに明示され、完全なレスポンスはクライアントがコンテキストを消費せずに読み取れるリソースとして保持されます。JSON 構造を途中で切断すると、モデルは解析不能なデータを受け取ります。静かに切り捨てるのはさらに悪いです。なぜなら、部分的なリストは完全なものとして読み取られるからです。

プロンプト

4つのワークフローで、/mcp__asc__<name> として利用可能です:

release-readiness · pricing-audit · review-triage · testflight-status

それぞれが複数の呼び出しを連鎖させます（スラッシュコマンドでラップされた1つのリクエストは同義語であり、ワークフローではありません）。また、sort が customerReviews で拒否される、レビューテキストが信頼できない入力であるなどのトラップをエンコードしています。

書き込みの安全性

HTTP メソッドは結果の重大性の貧弱な代理指標です。PATCH /v1/subscriptionPrices と PATCH /v1/appInfos/{id} はどちらも書き込みですが、顧客への請求額を変更するのは前者のみであり、どちらも繰り返しても元に戻りません。操作にはリスク階層が付与されます:

デフォルトでは、下位5つの階層は実行せずに確認トークンを返します。トークンはハッシュによって正確な操作、パス、クエリ、ボディにバインドされるため、安価な呼び出しで取得して高価な呼び出しに使用することはできません。1回限りの使用で、5分で期限切れになります。

--read-only    block every write        --confirm     confirm every write
--no-confirm   never confirm            (default)     confirm the five tiers above

クライアントがelicitationをサポートしている場合、asc_writeは直接ユーザーに確認を求め、メソッド、パス、ボディ、階層を表示します。それ以外の場合は、ハッシュによって正確な操作、パス、クエリ、ボディにバインドされた確認トークンにフォールバックするため、安価な呼び出しに対して発行されたトークンを高価な呼び出しに使用することはできません。elicitationを宣言しても提供できないクライアントは、そのまま通過せずにフォールバックします。dry_run はリクエストを送信せずに正確に報告します。

トランスポート

node dist/index.js                       # stdio (default)
node dist/index.js --transport http --http-token "$(openssl rand -hex 32)"

HTTP は 127.0.0.1 にバインドし、ベアラトークンなしでは起動を拒否します。このプロセスは App Store の価格を変更できる鍵を保持しています。認証なしでリッスンすべきではありません。ループバック以外にバインドすると警告が表示され、TLS 終端プロキシまたは SSH トンネルとの組み合わせが最適です。

Apple の更新への追随

npm run fetch:specs   # re-download both descriptions
npm run build         # recompile the operation index
npm run verify        # drift check + live calls against both APIs

2つの API は、必要に応じて異なる方法でソースが取得されています:

• App Store Connect — Apple は実際の OpenAPI 3.0 ドキュメントを公開しています。これはダウンロードされ、スリムなインデックス（360KB、元の仕様は3.3MB）にコンパイルされるため、検索は高速で、完全なドキュメントは1つの操作を説明するためだけに開かれます。

• App Store Server — Apple は OpenAPI ドキュメントを公開していません。ドキュメントは散文です。信頼できる機械可読記述は Apple 自身のクライアントである apple/app-store-server-library-node で、すべてのエンドポイントはリテラルな makeRequest 呼び出しです。fetch:specs は、固定されたリリースタグでそのソースからエンドポイントセットを解析し、verify はそれを src/storekit.ts のカタログと差分比較します。

そのカタログの2つの詳細は、ドキュメントが示唆するものと矛盾しており、どちらも動作に影響します:

• ホストは api.storekit.apple.com / api.storekit-sandbox.apple.com です。古い api.storekit.itunes.apple.com という名前はこの API を提供しなくなりました。

• 一括更新延長ステータスのパスは、セグメントを {productId}/{requestIdentifier} の順序に配置します。逆順ではありません。

検証

npm run verify は読み取り専用で、実際の呼び出しを行います。最終実行日:

1. Catalogue drift — src/storekit.ts vs Apple’s client
  ✓ all 30 Apple endpoints present in the catalogue
  ✓ no endpoints in the catalogue that Apple does not define

2. App Store Connect API — live
  ✓ apps_getCollection → 2 apps
  ✓ apps_getInstance / builds / appStoreVersions → HTTP 200
  ✓ pagination walked 3 pages
  ✓ bogus id → structured 404

3. App Store Server API (StoreKit 2) — live
  ✓ storekit token carries bid;  connect token correctly omits it
  ✓ getTransactionInfo / getAllSubscriptionStatuses / getTransactionHistory v2
      → authenticated and routed (Apple errorCode 4000006)
  ✓ getNotificationHistory (30d window) → HTTP 200

14 passed, 0 failed

StoreKit プローブは意図的に無効なトランザクション ID を使用します。シグナルは応答の形状です。構造化された Apple の errorCode は、リクエストが認証されルーティングされたことを証明します。一方、401 は認証されていないことを証明します。

堅牢性

• タイムアウトとリトライ。 読み取りは 408/429/5xx でリトライします。書き込みは 429 のみでリトライします。この場合、Apple は処理前にリクエストを拒否しています。あいまいに失敗した書き込みはあいまいとして報告され、再送されることはありません。重複した POST は報告された失敗よりも悪影響です。

• レート制限。 文書化された時間あたりの制限と文書化されていない分あたりの制限の両方に対してペーシングされ、Apple 自身の x-rate-limit ヘッダー（鍵を共有する他のクライアントを考慮）によって補正されます。x-request-id は Apple サポート向けに公開されます。

• ホストピン留め。 すべての URL は、links.next ページネーションカーソルを含め、Apple の3つの API ホストの許可リストに対してチェックされます。カーソルはサーバーから提供された入力です。それを盲目的にたどると、ベアラトークンが指定されたホストに渡されてしまいます。

• レスポンス整形。 links とリンクのみの relationships は削除され、links.next は保持されます。実際の価格ポイント一覧では 60% 以上小さくなります。

• ライフサイクル。 stdio サーバーは stdin EOF およびシグナルで終了し、署名鍵を保持したまま孤立して残ることはありません。

既知の制限

• JWS レスポンスはデコードされますが、検証されません。 StoreKit ペイロードは Apple によって署名されて到着します。チェーンを検証するには Apple のルート証明書が必要です。デコードされた値は *_decoded フィールドに表示され、未検証とラベル付けされます。署名を確認せずに購入の証明として扱わないでください。

• リスク階層はパターンマッチングによってメソッドとパスから決定されます。意図的に慎重になっていますが、書き込みの前に階層だけを信頼せず、asc_describe_endpoint を読んでください。

• キーチェーンストレージは macOS のみです。 他の環境では、制限されたパーミッションを持つファイルパスを使用してください。

• --no-confirm はゲートを完全に無効にします。CI 向けに存在しますが、インタラクティブエージェントのデフォルトとしては不適切です。

ライセンス

MIT