mcp-pulse

mcpcost

その MCP サーバーは稼働していますか？コンテキストウィンドウをどれだけ消費しますか？

ライブボード：mcpcost.ulehla.dev

mcpcost は公式 MCP レジストリ内のすべてのリモートサーバーを調査し、それぞれについて次の情報を記録します。

• initialize と tools/list に応答するかどうかと、その速度
• ネゴシエートされたプロトコルのバージョン
• 認証が必要かどうか、使用する方式（WWW-Authenticate から取得）、およびクライアントがアクセスする方法：動的クライアント登録を使う OAuth、発行元から取得したクライアント ID を使う OAuth、またはサーバーの公開 OAuth メタデータから読み取ったキー
• 支払いを要求するかどうか（HTTP 402）
• ツールの数と、その定義に必要なトークン数

mcpcost：自分のサーバーにはどれだけのコストがかかりますか？

npx mcpcost                     # reads Claude Code, Claude Desktop, Cursor, VS Code, Windsurf and Gemini CLI configs
npx mcpcost --config .mcp.json  # one file
npx mcpcost --budget 30000      # exit 1 when the total is above the budget, for CI
npx mcpcost --claude            # exact counts from the Anthropic count_tokens endpoint (free, needs ANTHROPIC_API_KEY)
npx mcpcost mcp                 # the same measurements as an MCP server over stdio, for your agent

クライアントと同じ方法ですべての設定済みサーバーを起動し、ツールを一覧表示して、サーバーごとのトークンコストと合計コストを出力します。packages/mcpcostを参照してください。

認証が必要なサーバー

401 を返すサーバーには接続できますが、認証情報を取得するまでは測定されません。認証情報は一度保存すれば、その URL の以降のすべての測定で使用されます。

npx mcpcost auth https://mcp.linear.app/mcp                                   # OAuth: register, consent in the browser, store the tokens
npx mcpcost auth https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer ghp_…"   # an API key instead
npx mcpcost auth --list                                                       # what is stored, without the secrets

OAuth フローは MCP 認可仕様に従います。ディスカバリー、動的クライアント登録、PKCE、127.0.0.1 でのコールバックを行います。人が関与する必要があるのは、同意画面の操作だけです。その後、トークンは ~/.mcpcost/credentials.json（モード 0600、または $MCPCOST_CREDENTIALS）に保存され、npx mcpcost はその URL にトークンを送信し、更新されたトークンはファイルに書き戻されます。

ボードも同じ処理を行います。npm run credentials:push がファイルを D1 テーブル credentials にコピーします。毎日の実行では、プローブ前に認証情報を読み込み、プローブ後に更新済みトークンを書き戻し、サーバーに「認証情報を使って測定済み」の印を付けます。サービスがリフレッシュトークンを無効にするか、期限切れにした場合は、再度同意画面の操作が必要です。

認証情報がなくても、ボードでは多くの認証が必要なサーバーのツールセットを確認できます。ツールの定義はトークンに依存しないため、発行元のリポジトリが npm または PyPI にパッケージを登録していれば、probe/derive-packages.ts がそれを見つけ、毎週のコンテナー実行でプレースホルダー値を使って測定します。その場合、サーバーページには「発行元のパッケージから」と表示されます。probe/derived-aliases.json は、レジストリエントリにリポジトリ名がない一部のサーバーを対応付けます。

CI で GitHub Action として使用する

- uses: ondraulehla/mcpcost@v1
  with:
    config: .mcp.json   # one or more config files, one per line
    budget: 30000       # fail when the tool definitions cost more than this

ジョブのサマリーには、すべてのサーバーとその結果およびコストを記載した表に加え、最も高コストなツールが表示されます。40 000 トークンのサーバーを追加するプルリクエストはチェックに失敗します。正確なトークン数を無料の count_tokens エンドポイントから取得するには、claude: true を設定し、ANTHROPIC_API_KEY を env に追加してください。デフォルトでは o200k_base による推定値が使われます。出力は tokens、servers、over-budget です。

プルリクエストでは、アクションがベースブランチ上の同じ設定ファイルも測定し、差分を 1 件のコメントとして投稿します。コメントには、追加、削除、変更されたサーバー、サーバーごとのトークン差分、新しい合計、予算の判定が含まれます。コメントはプッシュのたびに更新され、重複して投稿されることはありません。この機能にはジョブに pull-requests: write が必要です。権限がない場合、ステップは警告を出しますが、チェックは引き続き実行されます。無効にするには comment: false を設定します。完全なワークフローは .github/examples/mcp-budget.yml にあります。

Claude Code では、プラグインとして

Claude Code のセッションで：

/plugin install mcpcost --marketplace ondraulehla/mcpcost

またはシェルから：claude plugin marketplace add ondraulehla/mcpcost、続けて claude plugin install mcpcost@mcpcost を実行します。

このプラグインは、設定ファイルに対して npx mcpcost を実行して結果を読み取る /mcpcost:measure スキルと、ボードの MCP サーバーを追加します。これにより Claude は、設定ファイルに追加する前にサーバーを検索したり、プローブを実行したりできます。プラグイン自体が消費するのは、コンテキスト内のスキルの説明ひとつと、Claude Code がツール検索の対象として扱う4つのツールです。

ボード

mcpcost.ulehla.dev は D1 データベースからエッジでレンダリングされ、毎晩更新されます。読み込むスクリプトは、テーマ切り替えと、Cookie を使わずにページビューをカウントする Cloudflare Web Analytics のビーコンのみです。

• 概要：応答するサーバーの割合、トークンコストのパーセンタイル、任意のサーバーを確認するフォーム
• 確認：毎日の実行と同じ手順で、ひとつの URL にライブでプローブを実行します。正確なトークン数はブラウザーで計算します
• 統計：原因別の結果、トークンコストとツール数のパーセンタイル、最も重いツールセット、プロトコルのバージョン、認証方式、トランスポート、最大手の公開元
• サーバー：名前、タイトル、説明、ホストを対象にした全文検索（単語の先頭一致なので、git copilot で GitHub Copilot サーバーが見つかります）、結果・プロトコル・トランスポートによるフィルター、7種類の並べ替え、共有可能な通常の URL で表せるすべてのフィルター
• サーバーページ：ステータス、レイテンシー、プロトコル、機能、最もコストの高いツール、同じツールセットを持つサーバー、履歴、バッジ、メールアラート：サーバーが応答しなくなったとき、復旧したとき、またはツールセットやトークンコストが変化したときにメールで通知します
• 比較：2〜5台のサーバーを並べて比較します。ステータス、アクセス、ツール、正確なトークン数、200k のコンテキストウィンドウに占める割合、レイテンシー、最安値、差を表示します。/compare?s=<name>&s=<name> からアクセスでき、各サーバーページからリンクされています
• 追跡：レジストリにないサーバーも、確認ページから追跡できます。毎日のプローブでは url/<host>/<path> という名前で計測されます
• ホスト：実際に提供する個別のツールセット数とともに、最大手の公開元500件を表示します
• レポート：毎月1ページの MCP レジストリの現状。日次実行の結果に基づいており、すべてのサーバーを収録した CC BY 4.0 のデータセットもあります

エージェントとスクリプト向け

• JSON：/api/s/<name>.json、/api/lookup.json?url=…（エンドポイント URL に対応するボード上の行。プローブは実行しません）、/api/servers.json?q=…&status=ok&sort=tokens、/api/check.json?url=…、/api/summary.json。リスト API は、同一のアドレスから10秒間に最大6件のリクエストを受け付けます。応答は3時間キャッシュされます。
• レジストリ用の証拠データを再確認するには、最新の実行結果を参照してください：/data/mcpcost-evidence-latest.json.gz（modelcontextprotocol/registry#1715 の行形式。日次実行ごとに更新されます）。インデックスは /data/mcpcost-evidence-latest.index.json です。
• Streamable HTTP を使用する認証なしの MCP サーバー：https://mcpcost.ulehla.dev/mcp。ツールは lookup_server、search_servers、compare_servers、check_server、registry_summary です。レジストリのマニフェストは site/server.json です。
• /llms.txt にすべてが記載されています。/tokens では、MCP サーバーがコンテキストトークンをどれだけ消費するかという一般的な質問に回答します。

ボード上の各サーバーには、ページとバッジがあります：

[![mcpcost](https://mcpcost.ulehla.dev/badge/io.github.you/your-server.svg)](https://mcpcost.ulehla.dev/s/io.github.you/your-server)

初回の全件実行、2026-10-03

レジストリには最新のエントリーが38 942件ありました。そのうち24 294件にはリモートエンドポイントがあり、プローブは40分ですべてに接続しました。

結果	サーバー数	割合
稼働中：initialize と tools/list が成功	12 975	53 %
認証が必要（401、403）	5 836	24 %
MCP ではない：HTTP 200 だが有効な MCP 応答なし	1 800	7 %
見つからない（404、405、410）	881	4 %
DNS なし	728	3 %
レート制限（429）	500	2 %
支払いが必要（402）	434	2 %
サーバーエラー（5xx）	349	1 %
その他	307	1 %
TLS エラー	259	1 %
タイムアウト	204	1 %
接続拒否	21	0 %

応答した12 975台のサーバーについて：

• ツール一式のトークン数は中央値が1 727、90パーセンタイルが7 429、99パーセンタイルが28 200です
• 208台のサーバーは20 000トークンを超え、46台は50 000トークンを超え、3台は200kウィンドウ全体を超えます
• 最も重いのはcom.replynodes/mcpで、ツールが66個、トークン数は431 925です
• サーバーあたりのツール数は中央値が8個、最多は1 385個です
• initializeのレイテンシは中央値が455 ms、90パーセンタイルが1.5 sです
• 60 %がプロトコル2025-11-25をネゴシエートし、24 %は依然として2025-03-26、4 %は2024-11-05を使用しています
• 122台のサーバーはプロトコル2026-07-28で応答しますが、現在のTypeScript SDKはこれを拒否します

レジストリには偏りがあります。16 534個のホストのうち、16 161個はサーバーを1つ公開しています。5つのホストが合わせて6 000件を超えるエントリーを公開しています。その内訳は、ほぼ同一のエントリーを2 365件持つWorkersのサブドメインが1つ、エントリーを1 716件持ち、そのうち1 321件がinitializeでJSON-RPCエラーを返すゲートウェイが1つ、そして276件すべてが402を返すホストが1つです。

月次レポートとデータセット

/report/2026-10 は「MCP レジストリの現状、2026 年 10 月」です。レジストリの数値、初回の全件実行から 2026-10-24 の実行までに変化したこと、トークンコスト、認証、急増した項目、プロトコルのバージョン、レジストリでは検出できないこと、そして 6 文でまとめた手法を掲載しています。このページは runs テーブルのみを読み取ります（月の開始から実行日までの実行を、1 回のクエリで取得）。また、1 日間キャッシュされるため、無料枠のコストはかかりません。/report には各月が一覧表示されます。site/src/lib/reports.ts には、レポートごとに固定する実行日を指定した項目があります。付属するデータセット data/mcpcost-2026-10.json.gz はサイト上にあり、調査したサーバーごとに 1 行で、名前、ホスト、トランスポート、ステータス、HTTP ステータス、認証スキームと種類、プロトコルのバージョン、ツール数、o200k の推定値、Claude の正確なカウント、調査時刻が含まれます。各行の数値は、その日の該当サーバーに対して /api/s/<name>.json が返す値です。ライセンスは CC BY 4.0 です。ドキュメントの先頭には、ライセンス、フィールド一覧、引用情報が記載されています。probe/dataset.ts は毎日の実行で data/latest/dataset.json とその gzip ファイルを書き出します（実行アーティファクトに保存）。また、--publish site/public/data/mcpcost-YYYY-MM.json.gz を指定すると、サイズが 10 MB 未満の場合に gzip ファイルをサイトにコピーします。静的ファイルは Worker より先に配信され、リクエスト料金がかかりません。ファイルがそれより大きい場合は、代わりに GitHub リリースのアセットとして公開します。月次データを公開するには、プローブを実行するか実行アーティファクトを data/latest にダウンロードし、node --import tsx probe/dataset.ts --publish site/public/data/mcpcost-YYYY-MM.json.gz を実行してから、reports.ts に月を追加し、ページを作成し、そのファイルとともにコミットします。

同じ実行の結果は、レジストリの再確認を裏付ける証拠としても公開されます。行の形式は modelcontextprotocol/registry#1715 で合意されたもので、entry、checked_at、check（エンドポイントまたはパッケージ）、state（alive、auth、transient、dead、unknown）、evidence が含まれます。probe/dataset.ts は毎日、データセットの隣にこのファイルを書き出します。月次のコピーは /data/mcpcost-evidence-YYYY-MM.json.gz です。最新の実行結果は常に /data/mcpcost-evidence-latest.json.gz にあり、その隣には /data/mcpcost-evidence-latest.index.json（実行日、状態別および確認方法別のエントリー数、サイズ、SHA-256、形式）があります。どちらのファイルも git には含まれません。プローブはこのファイルを evidence-<run id> アーティファクトとして保持し、deploy.yml はビルドのたびに site/public/data に配置します。これはプローブの実行が成功するたびと、プッシュのたびに行われるため、プッシュによってサイトから削除されることはありません。probe/evidence-latest.ts は完全でないファイルを拒否し、その場合、サイトには既存のファイルが残ります。プローブ実行後のデプロイでは、その時点の main をビルドします。これは手動デプロイと同じで、独立したワークフロー実行となるため、プローブが失敗することはありません。

仕組み

registry ──▶ probe/run.ts ──▶ data/raw/probe-run.json
                                   │
                        probe/build-data.ts
                                   │
               data/latest/{servers,summary,hosts}.json
                                   │
                           probe/to-sql.ts ──▶ import.sql ──▶ D1
                                                                │
                              site/ (Astro on Workers) ◀────────┘

• packages/mcpcost/ ライブラリと CLI mcpcost。レジストリクライアント、リモートおよび stdio プローブ、設定の検出、トークンカウントを提供します
• probe/ バッチランナーとデータパイプライン
• site/ ダッシュボード。Workers 上で Cloudflare アダプターを使用する Astro 7 で、FTS5 検索を用いて D1 からレンダリングします。SVG バッジを備え、クライアント JavaScript はテーマ切り替えとアナリティクスビーコン以外に使用しません
• .github/workflows/probe.yml 毎日、プローブ、カウント、build-data、to-sql、D1 へのインポートを含むパイプライン全体を実行します。実行の summary.json、servers.json、hosts.json はワークフローアーティファクトとして保存されます。次回の実行ではそれとの差分を取り、無料枠の 1 日あたり 100 000 行の書き込み上限内で、変更された行のみをインポートします
• .github/workflows/deploy.yml site/ に変更があったときにサイトをデプロイします

方法

• トランスポート。 プローブは公式の TypeScript SDK をクライアントとして使用します。まず Streamable HTTP を試し、それしか利用できないリモートサーバーでは SSE を使用します。
• GET ストリームなし。 プローブは SDK の単独 GET リクエストに 405 を返すため、サーバーからクライアントへのストリームを開きません。プローブはサーバー起動メッセージを必要とせず、ストリームが開いている間 tools/list が停止するサーバーもあります（DeepWiki は 15 秒間ストリームを維持し、その間 POST に応答しませんでした）。
• 正確なトークン数。 毎日の実行では、稼働中の各サーバーについて Anthropic の count_tokens エンドポイントに問い合わせます。また、GEMINI_API_KEY が設定されている場合は Gemini の countTokens エンドポイントにも問い合わせます（CLI：--gemini）。まず Anthropic では、サーバーのツールとマーカーツールを使ったリクエストと、マーカーツールのみを使ったリクエストをそれぞれ 1 回送り、その差分から claude-opus-5-5 におけるツールのコストを算出します。2 回目のカウントでは、各ツール名に Claude Code の mcp__<server>__ プレフィックスを付けます。エンドポイントは無料で、モデルは呼び出しません。ツール定義が変更された場合にのみ、サーバーを再度カウントします。約 5 % のサーバーはエンドポイントが受け付けないスキーマを公開しているため、その場合は推定値と理由が表示されます。
• 推定値。 各ツールを name、description、input_schema を含むコンパクトな JSON にシリアライズし、o200k_base トークナイザーでカウントします。中央値では、正確なカウントは推定値の約 1.9 倍です。推定にキーは不要で、すべてのサーバーで同じ方法を使用します。
• 同一のツールセット。 ツール名とスキーマサイズをソートしたもののハッシュによって、異なる名前で同一のツールを提供するサーバーを識別します。
• タイムアウト。 リクエストごとに 15 秒です。1 つのホストに対して同時に実行されるプローブは最大 1 つです。
• アクセスの取得。 401 または 403 を返すサーバーについて、プローブは OAuth 保護リソースのメタデータ（RFC 9728）と、最初の認可サーバーのメタデータ（RFC 8414、次に OpenID Discovery）を読み取ります。対象は認可サーバー、スコープ、公開者のガイド、動的クライアント登録（RFC 7591）、PKCE、グラントタイプです。サーバーページでは「アクセスの取得」と表示され、JSON API では authKind と authMetadata として表示されます。少数のリクエストを 2～4 回行いますが、トークンも同意も不要で、プローブの結果は変わりません。
• 識別。 すべてのリクエストに User-Agent mcpcost/<version> (+https://github.com/ondraulehla/mcpcost) が含まれます。サーバーを除外するには、レジストリ名を添えて issue を作成してください。

実行する

npm install
npm run probe -- --sample 200 --per-host 2        # a sample, results in data/samples/
npm run probe -- --all --out data/raw/probe-run.json
node --import tsx probe/build-data.ts --in data/raw/probe-run.json --out data/latest
node --import tsx probe/to-sql.ts --in data/latest --out data/latest/import.sql
npm test --workspaces --if-present

ローカルの D1 に対して、サイトをローカルで実行します。

cd site
npm run db:schema:local && npm run db:import:local
npm run dev

MCP エンドポイントは、SDK を使わずに initialize、tools/list、ping と site/src/lib/mcp-snapshot.json に記載された通知に応答し、それ以外のリクエストはすべて SDK に渡します。スナップショットには SDK 自身の応答を使用する必要があり、そうでない場合はサイトのビルドが失敗します。ツール定義を変更した後は、npm run mcp:snapshot -w site を実行し、新しいファイルを同じコミットに含めてください。ビルド時にも実行される npm test -w site は、2 つの応答をバイト単位で比較します。

共有リンクにはカードが表示されます。カードは site/public/og/ にある 1200x630 の PNG です。デフォルトのカードのほか、10 月のレポート、比較、統計それぞれのカードがあります。site/src/lib/og.ts にカードとそのテキストが記載されています。レイアウトはページのカードを og:image と twitter:image に設定します。ページごとに独自の画像をレイアウトに渡すこともできます。npm run og -w site を実行すると、satori と resvg（WebAssembly として）を使ってカードを再生成します。node_modules のフォントと Layout.astro のカラー トークンを使用し、オフラインで実行できます。npm test -w site は、コミット済みのカードが現在スクリプトで生成されるものと異なる場合に失敗します。カード、フォント、またはカラー トークンを変更した後は、新しい PNG を同じコミットに含めてください。日々変わる数値は古くなるため、カードには含まれていません。カードは静的ファイルなので、Worker より先に配信され、リクエストも発生しません。GitHub リポジトリのソーシャルプレビューにデフォルトのカードを使うには、リポジトリの設定の「ソーシャルプレビュー」で site/public/og/default.png をアップロードしてください。

アラートメールの送信には送信ドメインが必要です。Cloudflare Email Sending（Workers Paid プランを利用し、site/wrangler.jsonc に send_email バインディングを設定）または Resend（そこでドメインを検証し、npx wrangler secret put RESEND_API_KEY を実行）のいずれかを使用してください。設定がない場合、監視フォームには確認メールを送信できなかったと表示されます。

デプロイには、mcpcost という名前の D1 データベースを持つ Cloudflare アカウントが必要です（wrangler d1 create mcpcost を実行し、ID を site/wrangler.jsonc に設定してください）。ワークフローでは、リポジトリシークレット CLOUDFLARE_API_TOKEN（Workers Scripts: Edit、D1: Edit）と CLOUDFLARE_ACCOUNT_ID が必要です。どちらのワークフローも、実行のたびに site/schema.sql と site/migrations/ 内の未適用ファイルを適用します。表示されるトークン数に関する 2 つのインデックス（マイグレーション 007 と 008）は例外です。各ビルドでサーバーごとに 1 行を書き込むため、プローブのワークフローがインポートの 1 日前に 1 つを適用し、インポートが残りの書き込み枠を使えるようにします。新しいデータベースでは、これらを一度手動で適用する必要があります。

エッジルール

Workers Free プランでは、Worker が応答したリクエストはすべてカウントされます。403 もページと同様です。2026-10-22 と 23 に、ホスティングアドレス（Meta のクラウド、Alibaba Cloud、RapidSeedbox）から Chrome のユーザーエージェントを使ったスクレイパーが、リストのバリエーションを毎時 4 000 件生成し、Worker が拒否していたにもかかわらず、アカウントの 1 日あたりのリクエスト上限 100 000 件を使い切りました。それらを止める処理は Worker の前に実行する必要があります。site/edge/rules.mjs が API 経由でゾーンの WAF ルールを書き込みます。処理は冪等です。

• ホスト全体で、Meta の学習用クローラー meta-externalagent をブロックするカスタムルールです。これは robots.txt を無視する検証済みボットで、2026-10-24 05:42 UTC までの 12 時間に Worker の 31 000 件のリクエストのうち 28 000 件を占めましたが、閲覧者を送ってきません（リンクのプレビューに使われる facebookexternalhit はブロックされません）
• 検証済みボットを除き、ホスト全体でこれらのネットワークをブロックするカスタムルールです
• 検証済みボット以外からのすべてのリストのバリエーション（/servers?…）にマネージドチャレンジを適用するカスタムルールです。ブラウザーなら一度通過できますが、スクリプトは通過できません。リスト API（/api/servers.json）は対象外です。スクリプトやエージェントはチャレンジを通過できないため、API はレート制限ルールの下で公開されたままです
• リストのバリエーションにアクセスする検証済みボットをブロックするカスタムルールです。robots.txt では全員に対してこれらを許可していないため、検索エンジンがアクセスすることはありません。また、Meta のクローラー（Chrome のエージェント文字列を使う meta-externalagent）は 2026-10-23 に毎時 3 000 件のバリエーションを巡回していました
• Free プランで使える 1 つのレート制限ルールです。同一アドレスから 10 秒間に 6 件を超えるリストのバリエーションへのアクセスがあると、10 秒間ブロックします

CLOUDFLARE_API_TOKEN=… node site/edge/rules.mjs --dry-run   # shows what it would write
CLOUDFLARE_API_TOKEN=… node site/edge/rules.mjs

Edge rules ワークフロー（.github/workflows/edge.yml）は、main でファイルが変更されたとき、または手動で、CLOUDFLARE_ZONE_TOKEN シークレットを使ってスクリプトを実行します。このトークンには、ゾーンに対する Zone: Zone WAF: Edit と Zone: Zone: Read の権限が必要です。プローブのトークンにはどちらの権限もありません。site/src/middleware.ts のミドルウェアは、ゾーンのルールでは認識されない workers.dev ホストに対する同じ拒否処理を、二重の防御層として維持します。

監視

site/edge/watch.mjs は、指定した時間帯に誰がボードを閲覧し、どれだけのコストがかかったかを示します。アカウントの分析データから Worker のリクエスト数と D1 の行数を時間あたりで集計し、Worker のログから、その背後にあるネットワーク、エージェント、URL の形式を調べます。Watch the edge ワークフロー（.github/workflows/watch.yml）は毎時実行され、前回のスケジュール実行からの期間を対象とします（GitHub はスケジュール実行を遅らせたり、実行を飛ばしたりすることがあります）。しきい値は、その期間で最も多かった 1 時間の値に適用されます。しきい値（1 時間あたりの Worker リクエスト数 5 000 件、クローラーを名乗らないエージェントによる単一ネットワークからのリクエスト数 800 件、名乗りにかかわらない単一ネットワークからのリストのバリエーション 300 件、D1 の行数 100 万件。設定変数は WATCH_*）を超えると、実行結果が赤になり、edge-watch ラベル付きの issue を作成するか、既存の issue にその時間帯を追記します。表にはネットワークが表示されます。その ASN を site/edge/rules.mjs の SCRAPER_ASNS に追加すると、Edge rules ワークフローが Worker の前でそのネットワークをブロックします。レポートには、その時間帯に最も多くの行を読み取った D1 クエリも表示されます。ゾーントークンに Zone: Analytics: Read の権限があれば、ゾーンが Worker の前で停止したアクセスも確認できます。

CLOUDFLARE_API_TOKEN=… CLOUDFLARE_ACCOUNT_ID=… node site/edge/watch.mjs                                   # the last hour
CLOUDFLARE_API_TOKEN=… CLOUDFLARE_ACCOUNT_ID=… node site/edge/watch.mjs 2026-10-22T22:00:00Z 2026-10-23T06:00:00Z   # one night

quiet をオンにして手動で実行した場合、レポートの書き込みのみを行います。過去の期間を振り返っても、issue は作成されず、すでに報告済みの時間帯を理由に実行結果が赤になることもありません。

gh workflow run watch.yml -f from=2026-10-24T19:00:00Z -f quiet=true

以前のホスト

2026-10-15 までは、サイトは mcp-pulse.ulehla.dev でした。以前のホストは Worker のルートとして残され、site/src/middleware.ts のミドルウェアが、そこへのすべてのリクエストに対して mcpcost.ulehla.dev への 301 を返します。

静的アセットは Worker より先に配信され、Astro アダプターもミドルウェアより先にプリレンダリングされたページを配信するため、site/public/ 内のファイルやプリレンダリングされたページは、以前のホストで 200 を返します。wrangler.jsonc の run_worker_first を設定しても変わりません。そのため、robots.txt、llms.txt、方法論のページはルートとなり、クローラーが読み込むすべてのページはミドルウェアを通ります。静的ファイルのまま残るのは、ファビコン、/_astro/ 内のフォント、/og/ 内のソーシャルカード、/data/ 内のデータセット、検索エンジンの確認ファイルのみです。

Worker をまったく呼び出さずにそれらもリダイレクトするには、Cloudflare ダッシュボードで ulehla.dev ゾーンにリダイレクトルールを追加します（Rules、Redirect Rules、Create rule）。

• When incoming requests match: Hostname equals mcp-pulse.ulehla.dev
• Then: Dynamic redirect、expression concat("https://mcpcost.ulehla.dev", http.request.uri.path)、status code 301、preserve query string on

リダイレクトルールは Worker と静的アセットより先に実行されるため、このルールですべてのパスが対象になります。ゾーンルールでは検知されない workers.dev ホストには、ミドルウェアがフォールバックとして残ります。

リリース

v0.Y.Z タグを作成すると、Release ワークフロー（.github/workflows/release.yml）が開始されます。5 つのファイルに記載されたバージョンがタグのバージョンと一致することを確認し（node scripts/version.mjs --check）、テストと npm run check -w site を実行して、パッケージを作成します。その後、provenance 付きでパッケージを npm に公開し、site/server.json を MCP レジストリに公開して、GitHub リリースを作成します。npm トークンも OTP も mcp-publisher login も不要です。npm はワークフローファイルを信頼し（trusted publishing）、レジストリは実行時の GitHub OIDC トークンを受け取ります。

npmjs.com で一度だけ設定します。初回リリース当日に行ってください。新しい trusted publisher は、2 日以内に公開しないと期限切れになります。

1. パッケージ mcpcost を開き、Settings に進みます。Trusted Publisher セクションで GitHub Actions を選択します。
2. Organization or user：ondraulehla。Repository：mcpcost。Workflow filename：release.yml。Environment name：空欄。
3. Allowed actions で npm publish を許可します。2026-09-03 以降に作成された trusted publisher では npm stage publish のみが許可され、ステージングされたバージョンは 2FA による承認を待ちます。
4. 保存します。npm 11.15.0 以降と 2FA を使用して、シェルからも同じ設定ができます：npm trust github mcpcost --file release.yml --repo ondraulehla/mcpcost --allow-publish。

初回リリース後、Settings の Publishing access で「Require two-factor authentication and disallow tokens」を設定すると、トークンを使ったすべての公開が停止します。ワークフローによる公開は引き続き実行されます。

リリース：

node scripts/version.mjs patch       # or minor, or 0.3.5: sets the version in the five files
git commit -am "mcpcost 0.3.5: …"    # the message of this commit becomes the release notes
git push origin main
git tag v0.3.5 && git push origin v0.3.5

• タグを作成する前に設定をテストするには、Actions、Release、Run workflow の順に選択し、「Dry run」ボックスにチェックを入れます。チェックを実行し、npm publish --dry-run とレジストリへのログインを行いますが、何も公開しません。「npm did not accept this workflow」という警告は、npmjs.com の trusted publisher の設定が一致していないことを意味します。ドライランでは、許可されたアクションの確認は行われません。
• 注釈付きタグ（git tag -a v0.3.5 -m "…"）では、そのメッセージがリリースノートになります。
• 実行に失敗した場合は、失敗したジョブを再実行します。npm またはレジストリですでに公開済みのバージョンは、各公開ステップでスキップされます。
• 「Dry run」を選択せずに main から実行すると、タグのプッシュなしでリリースされます。リリース処理が、そのコミットにタグを作成します。
• パッケージのリリースが Latest release になることはありません（--latest=false）。そのため、リポジトリの Latest release は GitHub Action のリリース（v1.1.0）のままとなり、Marketplace ページにもそのように表示されます。Action には独自のリリース v1.x.y があり、GitHub のリリースフォームから Marketplace に公開されます。また、そのタグ v1 は最新のリリースに移動します。ワークフローはこれらに触れません。v0.Y.Z タグのみがワークフローを開始するため、パッケージは独自のタグ方式ができるまで 1.0.0 未満にとどまります。

ライセンス

MIT