Show HN: 4,356の到達可能なMCPサーバーのうち、2026-07-28の仕様に対応できているのは1つだけ

mcp-spec-check 2026-07-28のMCP仕様リリースに、あなたのリモートMCPサーバーは対応準備ができていますか？30秒で確認できます。 npx mcp-spec-check https://your-server.com/mcp 7月28日に何も壊れることはありません。その日は仕様テキストが公開される日であり、スイッチが切り替わる日ではありません。バージョンネゴシエーションは引き続き機能し、非推奨の機能は少なくとも12ヶ月間稼働します。このツールは、アウトにつながるまでのカウントダウンではなく、新しいステートレスコアの採用状況を測定します。 MCP 2026-07-28リリースは、ローンチ以来最大のプロトコル改訂です。initialize handshakeとMcp-Session-Idはステートレスコアに置き換えられ、Mcp-Method / Mcp-Nameルーティングヘッダーが必須となり、SSE elicitationはMulti Round-Trip Requestsに置き換えられ、いくつかのエラーコードが変更されます。SDKとクライアントはすでにステートレスコアへの移行を進めているため、移行しないサーバーはサポート期間が終了すると取り残されます。 mcp-spec-checkは、あなたのライブエンドポイントをブラックボックスでプローブし（コードアクセス不要）、移行ドキュメントへのリンクとともに、あなたの現在の状況を知らせます。 エコシステムスキャン 2026-07-12に、公式MCPレジストリにある7,850のすべてリモートサーバーをプローブしました。オープンに到達できた4,356のうち、正確に1つだけが3つの必須チェックすべてに合格し、90.8%はまだ準備ができていませんでした。ステートレスコアへの移行はほとんど始まっておらず、仕様がまだGA（一般提供）される前としては予想される状況です。完全なレポートは、各パーセンテージとその分母、およびホストを折りたたんだ感度ビューとともに、docs/scan-2026-07.md（コミットされた集計：scan-2026-07.aggregates.json）にあります。 チェック内容 レポートは、2026-07-28に対応可能かどうかの1行の判定結果（YES / NO / UNKNOWN）で始まります。これは、以下の3つの必須チェック（discover, routing-headers, session-independence）のみに基づいて決定されます。すべて合格でYES、いずれかが失敗でNO、それ以外はUNKNOWNです。各チェックには、セカンダリシグナルとしてレターグレードが続きます。最初の3つだけがサーバーを失敗させることができます。残りは警告（warn）です。オプションまたは将来的なもので、それ自体では「準備ができていない」とはカウントされません。サーバーが曖昧すぎる回答をした場合、チェックはinconclusive（判定不能）とマークされ、スキップされたチェックと同様に、グレードにはカウントされません。それらが多すぎる場合、ツールは推測する代わりにグレード?（評価不能、終了コード2）を報告します。 チェック | 説明 -------|------- discover | サーバーはinitialize handshakeを置き換えるdiscoverを実装する必要があります routing-headers | ゲートウェイがルーティングできるように、すべてのリクエストでMcp-Method / Mcp-Nameが必須です session-independence | プロトコルレベルのセッションは削除されます。セッションピン留めされたサーバーは、ロードバランサーの後ろでステートレスコアを提供できません error-codes (warn) | resource-not-foundが-32002から-32602に番号変更されます cache-metadata (warn) | リスト/読み取り結果に新しいttlMs / cacheScopeキャッシングメタデータがあります mrtr (warn) | 結果にresultTypeフィールドが含まれます（Multi Round-Trip RequestsがSSE elicitationを置き換えます） deprecated-features (warn) | 非推奨のLoggingまたは削除されたリソース/サブスクライブ機能への依存 auth-metadata (warn) | OAuth保護リソースメタデータ（RFC 9728）は/.well-known/oauth-protected-resourceで検出可能です 判定の検証方法 プローブの正確さがすべてです。そのため、各チェックは単に主張するのではなく、既知の真実のサーバーに対してピン留めされています。 CIでは2つのリファレンスサーバーが実行されます。実際の旧仕様サーバー（公式SDK v1）とRCサーバー（2026-07-28 SDKベータ版）がビルドごとに起動され、mcp-spec-checkは両方に対して8つのチェックすべてで正確な期待される判定を生成する必要があります（npm run verify:refs）。どちらかの方向へのリグレッションはビルドを失敗させます。既知の真実パネルは、GitHubのMCPサーバー（認証ウォールあり、RFC 9728合格）や、準備ができていない、または判定不能と判断されるべきサーバーなど、動作が確立されている公開サーバーをクロスチェックします。公式の適合性スイートは、独立した共同オラクルとしてRCリファレンスサーバーに対して実行されます。ツールがあなたのサーバーに間違った判定を与えた場合、それは最優先のバグです。--json出力を添えてイシューを開いてください。 使い方 npx mcp-spec-check <url> # 人間が読めるレポート + レターグレード npx mcp-spec-check <url> --json # 機械が読める形式、スクリプティング用 npx mcp-spec-check <url> --verbose # 各チェックの理由を含める npx mcp-spec-check <url> --timeout 30000 # プローブごとのタイムアウト（ミリ秒、デフォルト15000） 認証済みサーバー npx mcp-spec-check <url> --bearer <token> # Authorization: Bearer <token>を送信 npx mcp-spec-check <url> --header "X-Api-Key: k" # 任意のヘッダー、繰り返し可能 資格情報なしでは、mcp-spec-checkは認証ウォールのあるサーバーを分類できますが、評価することはできません。チェックはスキップと報告され、終了コードは2（テスト不能）になります。auth-metadataチェックは、RFC 9728プローブがオリジンレベルでトークンを必要としないため、依然として実行されます。そのため、壁の後ろでも準備状況のシグナルを得ることができます。 CI 終了コードはCIフレンドリーです。0: 準備完了、1: 少なくとも1つのチェックが失敗、2: テスト不能（プローブエラー、エンドポイント認証ウォールあり/到達不能/MCPでない、またはサーバーが曖昧すぎる回答をしたため評価不能）。 - run: npx mcp-spec-check ${{ env.MCP_SERVER_URL }} 仕組み ライブエンドポイントに対する純粋なブラックボックスHTTPプローブです。コードアクセス不要、何もインストール不要、何も保存しません。ランタイム依存関係ゼロ。 プローブ倫理 レジストリスキャンは、公式の公開MCPレジストリに接続URLとして自発的に公開されたエンドポイントのみにアクセスします。プローブはホストシリアル（一度に1つのホストへのリクエスト、サーバーが並列負荷を見ることはありません）、副作用のない読み取り専用プロトコル呼び出しで、このリポジトリにリンクする名前付きmcp-spec-check-scan User-Agentとともに送信されます。サーバーごとの結果はスキャンを実行したマシン上に留まり、集計されたカウントとパーセンテージのみが公開されます。 比較方法 公式の適合性スイートは、ドラフト仕様シナリオを含む実装者向けの仕様テストフレームワークであり、独自のコードに対して設定します。YawLabs/mcp-complianceは、現在の2025-11-25仕様に対してAからFのコンプライアンスを評価します。公式のInspectorはインタラクティブなデバッグ用です。mcp-spec-checkはそれらのいずれでもありません。ホストされたURLに対する30秒のブラックボックス判定であり、特に次期リリース（2026-07-28）に焦点を当てています。 貢献 IssueとPRを歓迎します。CONTRIBUTING.mdを参照してください。プローブの正確さが最優先事項です。判定が間違っているように見える場合は、--json出力を含めてください。ライセンス MIT