App Store & Google Play

appstore-play-mcp

App Store Connect と Google Play に対応する読み取り専用の MCP サーバーです。両ストアで共通のツールセットを使えるため、「公開中のもの、審査中のもの、ユーザーから不満が出ているものは？」と、一度に確認できます。

> Which of my apps have a release that isn't live yet?

  Pocket Herbarium (App Store)
    app-store: 2.1.0 (214) — in review
  Pocket Herbarium (Google Play)
    production: 2.0.3 (208) — rolling out at 20%
    beta: 2.1.0 (214) — live

両ストアにアプリをリリースしていて、同じものを扱うのに別々のコンソール、認証方式、用語を使うことにうんざりしている個人開発者向けです。

ここでは一切書き込みを行いません。 メタデータの編集、提出、審査への返信はできません。すべてのツールに readOnlyHint が付与されており、これが守られなくなった場合はテストスイートが失敗します。

30 秒で試す

Apple キーも Google サービスアカウントも不要です。

npx -y appstore-play-mcp --demo

デモモードでは、架空の 2 アプリを運営する開発者向けのフィクスチャを提供します。審査で止まっているバージョンや、20％の段階的ロールアウトなど、確認する価値のある状態も含まれています。

npx @modelcontextprotocol/inspector npx -y appstore-play-mcp --demo

ツール

appId は get_releases と get_reviews で省略可能です。省略すると、ツールはすべてのアプリを対象にします。これがポートフォリオ表示です。

2 つのストアで共通の用語

App Store には appVersionState を持つ appStoreVersions があり、Play には status とロールアウト率を持つリリースを格納するトラックがあります。どちらも以下のように正規化されます。

各ストア固有の表記は rawState に保持されるため、翻訳によって情報が失われることはありません。

レビューも同様に扱いますが、1 つだけ例外があります。レビューの発生元について、各ストアが報告する内容は同じではないため、共通のフィールドにはしていません。

言語を国フィールドにまとめれば統一された形式はすっきり見えたでしょうが、誤った情報を報告することになります。そのため、各ストアには実際に把握している情報だけが設定されます。

セットアップ

MCP Registry に io.github.JohnBilousov/appstore-play-mcp として登録されているため、レジストリを読み取るクライアントは自動的に見つけられます。

どちらのストアも単独で動作します。どちらか一方、両方、またはどちらも設定しない（フィクスチャを使用する）ことができます。

export ASC_KEY_ID=XXXXXXXXXX
export ASC_ISSUER_ID=00000000-0000-0000-0000-000000000000
export ASC_KEY_PATH=/path/to/AuthKey_XXXXXXXXXX.p8

export PLAY_SERVICE_ACCOUNT_PATH=/path/to/service-account.json
export PLAY_PACKAGES=com.example.app,com.example.other

{
  "mcpServers": {
    "stores": {
      "command": "npx",
      "args": ["-y", "appstore-play-mcp"],
      "env": {
        "ASC_KEY_ID": "XXXXXXXXXX",
        "ASC_ISSUER_ID": "00000000-0000-0000-0000-000000000000",
        "ASC_KEY_PATH": "/path/to/AuthKey_XXXXXXXXXX.p8",
        "PLAY_SERVICE_ACCOUNT_PATH": "/path/to/service-account.json",
        "PLAY_PACKAGES": "com.example.app"
      }
    }
  }
}

claude mcp add stores -- npx -y appstore-play-mcp

知っておくべきプラットフォームの制限

以下はストア側の制約であり、サーバー側の制約ではありません。

• Play ではアプリを一覧表示できません。 そのため、PLAY_PACKAGES が必要です。
• Play のレビューをさかのぼれるのは約 1 週間分で、レビューがあるアプリに限られます。
• Play のトラックデータは「編集」内でしか読み取れません。 そのため、ここでの読み取りでは一時的な編集を開始し、finally ブロックで削除します。コミットされることはないため、アプリは変更されません。ただし、これが読み取り専用サーバーで POST を行う理由です。
• App Store のレビューは地域ごとに分かれており、ストアページへの反映が数時間遅れることがあります。

設計上の注意点

2 つの認証情報、1 つのインターフェース。 AppStoreClient と PlayClient はどちらも StoreClient を実装し、DemoStoreClient もフィクスチャ上で 3 つ目の実装を提供します。ツールが接続先のストアによって処理を分岐することはありません。

片方のストアが失敗しても、呼び出し全体が失敗することはありません。 読み取りはストア間およびアプリ間で並列に実行され、どちらかの軸で発生した失敗も例外としてスローせずに収集されます。Play が停止していても、App Store のレビューは返されます。Play の失敗はテキストに示され、unavailable にも記載されるため、モデルはユーザーに回答が不完全であることを伝えられます。空のリストと認証情報の不備が同じように見えてはなりません。この 2 つが区別されることをテストで確認しています。

エラーには解決策が含まれます。 Play の 403 は、サービスアカウントにアクセス権がない可能性、またはプロジェクトで Android Publisher API が無効になっている可能性を示します。404 は list_apps を呼び出すよう指示します。通常、モデルはユーザーの介入なしに問題を解決できます。

トークンはキャッシュされ、有効期限の早い段階で更新されます。 Apple では ES256（20 分）、Google では RS256 → OAuth2（1 時間）を使用し、どちらも有効期限の 1 分前に更新することで、境界での呼び出しの競合を防ぎます。Play 側では、実行中のトークン交換もメモ化されます。listApps() はパッケージごとに編集を並列で開始するため、これがなければ、同時に呼び出された各処理はまだキャッシュされたトークンを見つけられず、それぞれ独自のトークンを発行してしまいます。

開発

git clone https://github.com/JohnBilousov/appstore-play-mcp && cd appstore-play-mcp
npm install
npm run build
npm test          # tool surface + both auth clients against a mocked fetch, real key material throughout
npm run lint      # eslint
npm run format    # prettier --write
npm run inspect

CI では、プッシュとプルリクエストのたびに typecheck、lint、format:check、test、build を実行します。

src/
  index.ts          CLI entry, stdio transport
  config.ts         env → Config; either store optional, fixtures as the floor
  server.ts         tools + the registry that fans reads across stores
  schemas.ts        zod input and output shapes
  format.ts         human-readable summaries next to structuredContent
  stores/
    types.ts        shared vocabulary + state normalisation
    appstore.ts     App Store Connect (ES256 JWT)
    play.ts         Google Play (service account → OAuth2)
    demo.ts         fixtures
test/
  server.test.ts    tool surface, state normalisation, portfolio sweeps — over a real MCP transport
  stores/
    appstore.test.ts  ES256 signing verified against the public key, token caching, error mapping
    play.test.ts       RS256/OAuth2 exchange, the transient-edit cleanup, the concurrency fix above

リリース

公開には npm の信頼できるパブリッシング（OIDC）を使用するため、NPM_TOKEN シークレットは不要です。漏えいや期限切れの心配もありません。npmjs.com で一度だけ設定します。パッケージの Settings → Trusted publishing → GitHub Actions で、organization は JohnBilousov、このリポジトリ、ワークフローファイル名は publish.yml に設定します。

リリースするには、package.json、server.json、src/server.ts の VERSION のバージョンをそろえて更新します（ずれがないことをテストで確認します）。コミットしてプッシュした後、一致する vX.Y.Z タグで GitHub Release を公開します。これにより .github/workflows/publish.yml が起動し、テストスイートを実行して、provenance を付けて npm に公開します。パッケージページには、レジストリ上の名前だけでなく、この正確なコミットとワークフローの実行への検証済みリンクが表示されます。

ロードマップ

• App Store Connect からの販売・ダウンロードレポート（ベンダー番号が必要です）
• Play Developer Reporting API からのクラッシュと ANR のバイタル情報
• TestFlight ビルドとテスターグループ
• stdio に加えて Streamable HTTP トランスポートに対応

貢献を歓迎します。特に、両方のストアにアプリを公開していて、ここに記録する価値のある制限に遭遇した方からの貢献をお待ちしています。

ライセンス

MIT © Ivan Bilousov