app-store-connect-mcp

App Store Connect MCP Server

価格設定の鍵を渡さずに、Claude に App Store Connect アカウントを使わせましょう。 App Store Connect API と App Store Server API （StoreKit 2）をカバーする MCP サーバーです。1,293 の操作を 13 個のツールで提供し、Claude Code、Claude Desktop、 Cursor など、Model Context Protocol に対応するあらゆるものから利用できます。

1,293 operations · 13 tools · key never on disk · Apple signatures verified

flowchart LR
    A["Claude<br/>Cursor · any MCP client"] -->|"search · call · write"| B["app-store-connect-mcp<br/>13 tools"]
    B --> C{"risk tier"}
    C -->|"READ · 811 ops"| D["Apple<br/>App Store Connect API"]
    C -->|"WRITE · 482 ops"| E["ask a human first"]
    E -->|approved| D
    E -->|declined| F["nothing is sent"]
    B --> G["App Store Server API<br/>StoreKit 2 · signatures verified"]

    style E fill:#ffe8b3,stroke:#c98a00,color:#000
    style F fill:#ffd6d6,stroke:#c00,color:#000
    style D fill:#d6f5d6,stroke:#2a2,color:#000
    style G fill:#d6f5d6,stroke:#2a2,color:#000

インストールしないでください

本当に。午後の時間を使うもっと安価な方法がありますし、今すぐタブを閉じたほうがよい人も何種類かいます。

とにかく実行してくれるエージェントが欲しい方。 このサーバーは、価格を変更したり、何かを削除したり、アカウントにアクセスできるユーザーを変更したりする前に、いったん止まって確認します。しかも確認する相手はエージェント自身ではなく、あなたです。それが煩わしいと感じるなら、そのとおりです。それがこの製品の仕様です。

すべてのエンドポイントを個別のツールとして使いたい方。 エンドポイントごとに登録するサーバーもあります。あなたのサーバーでは、ひとつの質問に答える前にツール定義だけでコンテキストを数十万トークン消費することになります。このサーバーが登録するのは 11 個で、残りは検索して見つけます。

tool definitions loaded into context, before you ask anything

  one tool per endpoint   ███████████████████████████████████   >100k tokens
  this server             ▌                                       ~1k tokens

Windows または Linux を使っていて、Keychain を使いたかった方。 Keychain への保存は macOS 専用です。それ以外ではファイルパスを使えますが、このサーバーのよさが最も発揮されるのは macOS です。

App Store の紹介文を書かせたい方。 レビューとローカライズは取得できます。しかし、マーケティング用の文章を創作して公開することはありません。それを可能にするフラグもありません。

販売する製品での利用を検討している方。 まずライセンスをお読みください。社内利用は無料ですが、再販売はできません。

まだ読んでいますか？ それなら、以下はおそらくあなたに向けた内容です。

実行しないこと

ここでのエンジニアリングの大半は、あえて実行しないことに費やされています。そのため、まずはその点から正直にお伝えします。

生成されたコードは実行しません。 大規模な API をカバーする洗練された方法は、モデルに JavaScript を書かせて、サンドボックス内で eval することです。しかし、Node の vm はサンドボックスではありません。Node 自身のドキュメントにもそう書かれています。また、ホストオブジェクトをひとつでも渡せば、プロトタイプチェーンを通じて実行環境全体が漏れ出します。

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

これは実際に稼働している MCP サーバーのサンドボックスを再現したもので、ホームディレクトリが返されます。15 秒のタイムアウトも役に立ちません。制限されるのは 同期 コードだけなので、async ループは永久に実行されます。このサーバーがディスパッチするのはコードではなく、パラメーターです。同じ範囲をカバーし、トークンコストも同じで、抜け道はありません。

書き込みを読み取りのように見せかけることはできません。 読み取りと書き込みは別々のツールです。asc_write には _meta["anthropic/requiresUserInteraction"] が含まれており、Claude Code は bypassPermissions の場合でもこれを尊重します。モデルが説得して回避することはできません。回避できるのは、サーバーを --no-confirm で起動するオペレーターだけです。このオプションはフラグ、プロンプト、トークンをまとめて取り除くため、応答する人がいない状態で実行できます。

価格設定の意図をこちらで決めることはありません。 preserve_current_price はデフォルト値のない必須パラメーターです。Apple のデフォルトは false で、既存のサブスクライバーは新しい価格に移行されます。これを必須にすることで、その判断を明示し、人が確認できるようにしています。

質問に答えるために、継続的な義務を作成することはありません。 アナリティクスを取得するにはレポートリクエストが必要ですが、accessType: ONGOING はクエリではなく、アカウントに対する継続的な義務です。このツールはレポートを読み取りますが、黙って作成することはありません。

レビューをサニタイズしたと装うことはありません。 カスタマーレビューのテキストは見知らぬ人が書いたもので、そのままモデルのコンテキストに入ります。レビューを含む結果の 先頭 には、それが報告対象のデータであり、従うべき指示ではないことを示す注記が付きます。インジェクションの文言を意図的にフィルタリングしていません。攻撃者が繰り返し対策を練るゲームであり、そのようなフィルターを通過できることは、実現できない安全性を示唆してしまうからです。

確認していない署名を問題ないとは言いません。 詳細は以下をご覧ください。

インストール

Claude Code の場合、1 行で実行できます：

claude mcp add --scope user app-store-connect \
  --env ASC_KEY=keychain:my-asc-key \
  --env ASC_BUNDLE_ID=com.example.app \
  --env ASC_APP_APPLE_ID=1234567890 \
  -- npx -y @abd3lraouf/app-store-connect-mcp

クローンもビルドも不要です。先に読んでおきたい場合は、ソースからインストールすることもできます：

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

または、Claude Desktop、Cursor などの場合：

{
  "mcpServers": {
    "app-store-connect": {
      "command": "npx",
      "args": ["-y", "@abd3lraouf/app-store-connect-mcp"],
      "env": {
        "ASC_KEY": "keychain:my-asc-key",
        "ASC_BUNDLE_ID": "com.example.app",
        "ASC_APP_APPLE_ID": "1234567890"
      }
    }
  }
}

次に、*「App Store Connect の接続を確認して」*と依頼します。これにより asc_status が実行され、軽量なリクエストを 1 回送って認証情報を検証し、不足しているものがあれば具体的に知らせます。

キーは Keychain に保管してください

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

識別子とキーの情報が一緒に扱われるよう、base64 JSON として保存します。これにより 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
)"

13 個のツール

コアツールは 5 つあり、すべてをカバーします。

複合ツールは 8 つあり、単一の呼び出しでは表現できない API の連鎖に対応します。リクエストを 1 つ保存するだけのツールは除外しました。Apple の変更に永続的に追従する必要があるうえ、asc_call ですでにできること以上の利点がないためです。

sequenceDiagram
    participant M as Claude
    participant S as this server
    participant A as App Store Connect
    participant U as Apple asset host

    M->>S: asc_upload_screenshot(set, file)
    S->>A: POST /v1/appScreenshots (fileName, fileSize)
    A-->>S: id + uploadOperations[]
    loop each byte range
        S->>U: PUT bytes at offset, Apple's headers
        Note over S,U: pre-signed URL — no bearer token sent
    end
    S->>A: PATCH uploaded=true + MD5 checksum
    A-->>S: assetDeliveryState
    S-->>M: state, and how to clean up if it failed

さらに、4 つのリソース（@asc:cookbook、@asc:enums、@asc:risk、@asc:sources）と、スラッシュコマンドとしての4 つのワークフロー（/mcp__asc__release-readiness、pricing-audit、review-triage、testflight-status）があります。

書き込みの安全性

HTTP メソッドは、操作の影響を測る指標として適切ではありません。PATCH /v1/subscriptionPrices とPATCH /v1/appInfos/{id}はどちらも書き込みですが、顧客への請求額を変更するのは一方だけであり、どちらも同じ操作を繰り返しても元には戻りません。そのため、すべての操作にティアが設定されています（件数は App Store Connect のものです。StoreKit 2 では読み取りが 14 件、書き込みが 16 件追加されます）。

flowchart TD
    A["asc_write called"] --> B{"--read-only?"}
    B -->|yes| Z["blocked"]
    B -->|no| N{"--no-confirm?"}
    N -->|yes| S["send it"]
    N -->|no| C{"risk tier"}
    C -->|"WRITE"| S["send it"]
    C -->|"REVENUE · DESTRUCTIVE<br/>INFRASTRUCTURE · ACCESS · RELEASE"| D{"client supports<br/>elicitation?"}
    D -->|yes| E["ask the person<br/>method · path · body · tier"]
    D -->|no| F["issue a token<br/>hash-bound to this exact request"]
    E -->|accepted| S
    E -->|declined| Z
    F --> G["caller repeats the call<br/>with the token"]
    G --> S

    style Z fill:#ffd6d6,stroke:#c00,color:#000
    style E fill:#ffe8b3,stroke:#c98a00,color:#000
    style F fill:#ffe8b3,stroke:#c98a00,color:#000
    style S fill:#d6f5d6,stroke:#2a2,color:#000

下位 5 つのティアでは、実行前に確認を求めます。クライアントがエリシテーションに対応している場合は、メソッド、パス、本文、ティアを表示して、あなたに直接確認します。それ以外の場合は、操作、パス、クエリ、本文のハッシュに紐付けられた確認トークンを発行します。そのため、低リスクの呼び出しで取得したトークンを高リスクの呼び出しに使うことはできません。エリシテーションに対応していると称するクライアントがそれを実行できない場合は、そのまま実行せず、代替の確認方法に切り替えます。

--read-only    block every write       --confirm     confirm every write
--no-confirm   never confirm           (default)     confirm the five tiers above
dry_run: true  report the exact request without sending it (a parameter of asc_write)

--no-confirmは無人実行モードであり、例外はありません。エリシテーションのプロンプトも、確認トークンもなくなり、書き込みツールはrequiresUserInteractionの宣言を停止するため、Claude Code も処理を中断しません。これ以外の方法では、無人実行に回答できない確認を求めてしまいます。

署名の検証

JWS をデコードすれば、バイト列が何を示しているかがわかります。検証すれば、それを Apple が発行したことがわかります。この違いがここで特に重要なのは、ペイロードが 「この人は有料サブスクリプションの加入者か？」 の証拠となるためです。デコードされていても検証されていないトランザクションは、偽造されたトランザクションとまったく同じ形をしています。

署名付きのフィールドはすべて、certs/に同梱されたApple Root CA - G3を基に検証します。そのため、ネットワーク障害によって検証が無効になることはありません。チェーン検証、有効期限、失効、バンドルと環境のチェックには Apple 独自のライブラリを使用します。もっともらしい実装が不正な入力を受け入れてしまうのは、まさにこうした部分だからです。

結果は応答全体ではなくフィールドごとに示されます。200 件の履歴のうち署名が 1 つだけ不正なケースこそが重要です。

"signedTransactionInfo_decoded":      { "productId": "premium.monthly" },
"signedTransactionInfo_verification": { "verified": true }

検証を実行できない場合でも、ペイロードはデコードされ、すべてのフィールドにその旨が示されます。何も表示しないことが、最も危険な結果です。

比較

功績は正当に認めるべきです。ここでのアイデアのいくつかは、 erayendes/app-store-connect-mcp とTrialAndErrorAI/appstore-connect-mcp を読んで着想を得ました。コードは一切コピーしていません。特に Heimdall は、この分野で最も開発が進んだサーバーです。プロファイル別に整理された 890 個の型付きツールが必要なら、代わりにそちらをお使いください。優れたサーバーですが、こちらとは異なる選択です。

レシート

主張は簡単にできます。ここに挙げるのは検証可能な内容です：

378 tests · 90% line coverage · offline, no credentials, runs on every PR

• 署名検証の両方向。 すべてを拒否する検証器も、正常に動作しているように見えてしまいます。そのため、検証器が必須としている Apple の 2 つの OID を含む生成済みチェーンで、受け入れる経路を証明します。一方、偽造、改ざん、誤ったバンドル、誤った環境のペイロードはすべて拒否されます。
• プロトコルのバージョンは仮定ではなく、実測しています。 Claude Code 2.1.235 が MCP 2025-11-25 をネゴシエートし、elicitation を宣言することを、プローブサーバーに接続させて記録しています。そのため、ここでは SDK v1 を使用します。v2 パッケージが実装するのは 2026-07-28 で、elicitation は MRTR に置き換えられます。asc_write が人間に確認を求めるのは elicitation によるものです。
• HTTP モックには nock ではなく MSW を使用します。nock は node:http をパッチしますが、Node のグローバルな fetch は undici を使うため、完全に迂回します。つまり、何もインターセプトできず、しかもそれに気づけません。
• 1 つのテストで実際のバイナリを起動し、標準出力のすべての行が JSON として解析できることを検証します。余計な console.log が 1 つあるだけで JSON-RPC チャネルが壊れますが、プロセス内のハーネスではそれを検出できないためです。

npm test              # 378 tests, offline
npm run verify        # 14 read-only checks against the live APIs
npm run fetch:specs   # re-download both API descriptions from Apple

Apple の最新情報への対応

カバレッジを決めるのは、誰かがラップしたエンドポイントの数ではなく、Apple の仕様です。

• App Store Connect — 1,263 件の操作、仕様 v4.4.1。Apple が公開している OpenAPI ドキュメントをダウンロードし、スリムなインデックスにコンパイルします（3.3MB の仕様に対して 360KB）。
• App Store Server — 30 件の操作。この API については Apple が OpenAPI ドキュメントを公開していないため、固定したリリースタグの Apple 独自のクライアントライブラリからエンドポイント一式を解析し、verify の実行ごとにこのリポジトリのカタログと差分を確認します。
• 列挙型テーブルはすべて生成されます。全 90 個が対象です。他所で広くコピーされているクックブックには、Apple に存在しない eventState の値が記載され、実際に存在する 2 つの値が欠落しています。ここでは生成することで、そうしたことが起こらないようにしています。
• 毎週のジョブで両方を再取得し、Apple 側に変更があればブランチを作成します。

トランスポート

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

HTTP はループバックにバインドされ、ベアラートークンがなければ起動を拒否します。Host と Origin も検証します。検証しないと、ブラウザページからループバックにバインドされたサーバーへ同一オリジンとしてアクセスでき、トークンだけでは防御できないためです。

Docker は distroless でビルドされ、非 root ユーザーとして実行されます。stdio には docker run -i が必要で、-t は指定しないでください。TTY によって JSON-RPC ストリームが壊れます。

スキル

サーバーは質問に答えます。しかし、正しい回答からモデルが誤った結論を導くことまでは防げません。たとえば、地域を USA ではなく US と入力したためにリストが空になる、30 件中 1 ページだけをアカウント全体と見なす、買い切り商品を販売するアプリについて「サブスクリプションなし」と判断する、といったケースです。いずれもレスポンスは 200 なので、捕捉できるエラーはありません。

そうした判断を支える機能は、Claude Code スキルとして提供されます：

npx -p @abd3lraouf/app-store-connect-mcp asc-mcp-skill

~/.claude/skills/app-store-connect にインストールされます（./.claude/skills にインストールする場合は --scope project、チェックアウトをシンボリックリンクして編集内容を即時反映する場合は --link を指定します）。settings.json には何も追加しません。

このスキルは API の概要ではなく、結論を出す前に実行するチェック項目の一覧です。導出できるものを手作業でコピーすることはありません。列挙型テーブルもエンドポイント一覧も含みません。また、スキル内のすべてのツール名、リソース URI、プロンプト、列挙型の値が、src/ または Apple の仕様に引き続き由来していることをテストで検証します。

失敗が記録されます

現在、失敗はトランスクリプト内のツール結果としてのみ存在します。会話が終わると、Apple サポートが求める唯一の値である Apple の x-request-id も、モデルが試みて見つけられなかった操作の証拠も、失われてしまいます。

現在は両方が failures.jsonl に書き込みます。サーバーは自身の HTTP、ネットワーク、握りつぶされた失敗を記録し、スキルはサーバーから見えない失敗、つまり 200 で返された解釈上の失敗を記録します。

npm run triage        # what keeps failing, and what the cookbook never warned about

書き込み先の優先順位は次のとおりです。設定されている場合は ASC_FAILURE_LOG_DIR（この場合、ほかの場所には書き込みません。明示的に指定した保存先がいつの間にか別の保存先に変わるくらいなら、保存先がないほうがましです）。それ以外の場合は、このパッケージの作業中のチェックアウト（src/ と .git/ を含むことで判別します。どちらも npm pack では公開されません）。それ以外の場合は、インストールされたスキル自身のディレクトリ。それ以外の場合は ~/.claude です。

チェックアウトもインストール済みのスキルもないマシンでは、ASC_FAILURE_LOG=1 で有効にしない限り、何も書き込みません。ASC_FAILURE_LOG=0 を設定すると、どこでも無効になります。

書き込まれないもの：リクエストヘッダーとリクエスト本文は、決して記録しません。記録するのは本文のキーだけです。これは、appStoreReviewDetails の本文に実際に使われている demoAccountPassword が含まれるためです。レスポンスのペイロードは Apple のエラーオブジェクトに縮約されます。事前署名済みアセット URL は、署名がパスに含まれているため、ホスト名として記録されます。JWT、ベアラートークン、PEM ブロック、メールアドレスのローカル部は、さらなる防御策としてサニタイズされます。

レコードは O_APPEND ディスクリプターへの、サイズ上限のある単一の書き込みとして追記されます。そのため、サーバーとスキルはロックなしで同じファイルを共有できます。この保証は POSIX に基づくもので、NFS では成立しません。ASC_FAILURE_LOG_DIR はローカルディスクを指すようにしてください。

既知の制限

いずれにせよ見つかることなので、率直に記載します。

• リスクの階層は、メソッドとパスのパターンマッチングで判定します。意図的に慎重にしていますが、あくまでヒューリスティックです。書き込みの前に asc_describe_endpoint を読んでください。
• キーチェーンストレージは macOS 専用です。 それ以外の環境では、アクセス権を制限したファイルパスを使用してください。
• --no-confirm はすべてのゲートを無効にします。対象はトークン、エリシテーション、requiresUserInteraction フラグです。CI と無人エージェント向けのオプションであり、人がいる環境では適切なデフォルト設定ではありません。
• --no-online-checks は OCSP をスキップするため、失効した証明書を受け入れることになります。
• 失敗ログのロックフリー追記は、O_APPEND のアトミック性に依存していますが、ネットワークファイルシステムでは保証されません。npm run triage は破損した行を無視して処理を続けますが、ネットワークマウントではレコードが失われることがあります。
• 署名の受け入れパスは、置き換えた信頼アンカーを使って検証済みであり、Apple の信頼アンカーを使ったものではありません。実際に Apple が署名したペイロードを取得するには、実際の顧客トランザクションが必要です。チェーンのロジックには Apple 自身のライブラリを使用しています。

リリース

バージョンを上げてマージすれば完了です。どちらのレジストリもワークフロー自身の OIDC ID で認証するため、ローテーションするトークンも覚えておくタグもありません。

npm run release:version patch     # or minor, major, or an exact version
git commit -am "Release v1.0.1" && git push

CI は、まだ npm に公開されていないバージョンを検知すると、すべてのゲートを実行してから npm と MCP Registry に公開し、コミットにタグを付けて GitHub Release を作成します。トリガーはタグではなくバージョンなので、ジョブは冪等です。再実行しても、何も公開されません。

ライセンス

Business Source License 1.1。社内利用、評価、開発は無料です。ホステッドサービスや組み込みサービスとして第三者に提供する場合、または商用製品に含めて再配布する場合は、ライセンスが必要です。2030-08-19 に Apache-2.0 に切り替わります。

Apple の OpenAPI 記述とルート証明書は、このライセンスではなく Apple の利用条件に基づいてここに同梱されています。NOTICE を参照してください。

Apple、App Store、App Store Connect、StoreKit、TestFlight は Apple Inc. の商標です。このプロジェクトは Apple と提携していません。