ScoutWyze Compute

ScoutWyze Compute MCP サーバー

MCP ネイティブのエージェントホスト（Claude Desktop、Cursor、カスタムエージェントフレームワーク）向けの、ScoutWyze Compute の GPU オファーランキング API をラップするステートレスな MCP（Model Context Protocol）サーバーです。現在の RunPod の GPU オファーを価格と鮮度でランク付けする以外の機能はありません。メインの scoutwyze-compute アプリの一部ではなく、独立してインストール可能な別パッケージとして、意図的に src/ の外に置かれています。

厳守すべき境界 — このサーバーを拡張する前にお読みください

このサーバーは秘密鍵を保持せず、x402 の支払いを自ら署名したり決済したりすることはありません。 scoutwyze_rank の呼び出しが認証されていない場合（SCOUTWYZE_API_KEY が設定されていない、またはキーが無効）、API からの実際の x402 支払いチャレンジは、ツールの結果コンテンツとして返され、破棄されたり自動的に支払われたりすることはありません。たとえば、次のようになります。

{
  "x402Version": 1,
  "error": "payment_required",
  "accepts": [{
    "scheme": "exact", "network": "base", "maxAmountRequired": "150000",
    "resource": "/v1/compute/rank",
    "payTo": "0xc132a315a05541a4b72c272de539eb86de977fb9",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "maxTimeoutSeconds": 120,
    "extra": { "name": "USD Coin", "version": "2" }
  }]
}

ウォレット機能を持つ呼び出し元のエージェントが、このサーバーではなく、EIP-3009 の TransferWithAuthorization（上記の正確な extra.name／extra.version ドメインを使用する EIP-712 型付きデータ。オンチェーンブロードキャストが不要な、実際の x402「exact」EVM スキームであり、その処理はこのサーバー自身のファシリテーターが行います）に署名し、生成された X-PAYMENT 証明を付けて同じツール呼び出しを再試行する責任を負います。署名フローの完全でテスト済みのリファレンス実装については、メインリポジトリの examples/node-client.mjs または examples/python_client.py を参照してください。このサーバーが扱う認証情報は、任意のプリペイド Bearer キーだけです。

これは単なるスタイル上の選択ではありません。「誰でもローカルで簡単に起動できる軽量パッケージ」が実際に資金の入った秘密鍵を保持することは、このコードベースのほかの機能とは根本的に異なるリスク区分に属し、コードベース全体で守られている方針（オンチェーン検証コードはチェーンを読み取るだけで、トランザクションを送信せず、鍵も保持しません）にも反します。このサーバーにウォレット機能や署名機能を追加しないでください。

ツール

• scoutwyze_sample — 無料、匿名、レート制限付きのプレビュー （GET /v1/compute/sample）。引数はなく、課金されることもありません。
• scoutwyze_rank — ワークロードに合わせて GPU オファーをランク付けします （POST /v1/compute/rank）。gpuClass、minVramGb、region、 maxPricePerHour、preference はすべて任意です。一致が成功するごとに課金されます。実際の価格は、レスポンスの billing.price_usd から常にその場で取得し、ここにハードコードすることはありません（サーバー側の価格は変わる可能性があり、ツールの説明に固定価格を書くと、このリポジトリのほかのいくつかのドキュメントと同じように古くなってしまうためです）。

POST /v1/route/quote は意図的にラップしていません。古い別個のレスポンススキーマを使用しており、compute/rank が主要かつ現在積極的にドキュメント化されているパスだからです（SOT.md を参照）。

設定

npm では @scoutwyze/compute-mcp として公開され、公式 MCP Registry には io.github.scoutwyze-max/compute-mcp として登録されています。MCP ホストの設定（例：Claude Desktop の mcp.json）に追加します。

{
  "mcpServers": {
    "scoutwyze-compute": {
      "command": "npx",
      "args": ["-y", "@scoutwyze/compute-mcp"],
      "env": {
        "SCOUTWYZE_API_KEY": "sw_live_..."
      }
    }
  }
}

ローカルで開発する場合は、代わりにビルド済みファイルを直接指定します。

{
  "mcpServers": {
    "scoutwyze-compute": {
      "command": "node",
      "args": ["/absolute/path/to/scoutwyze-compute/mcp-server/dist/index.js"],
      "env": {
        "SCOUTWYZE_API_KEY": "sw_live_..."
      }
    }
  }
}

• SCOUTWYZE_API_KEY — 任意です。POST /v1/signup と POST /v1/checkout-sessions で取得するプリペイド Bearer キーです。認証なしで実行するには、これを完全に省略してください。その場合、scoutwyze_rank はランク付け結果ではなく実際の x402 チャレンジを返します（上記の境界を参照）。
• SCOUTWYZE_BASE_URL — 任意です。デフォルトは https://scoutwyze-compute.fly.dev です。メインアプリの npm run dev サーバーを使ったローカル開発用に上書きできます。

開発

npm install
npm run build   # -> dist/index.js
npm run dev     # runs directly from src/ via tsx, no build step

新しいバージョンの公開

このディレクトリ内で npm version <patch|minor|major> を実行し、その後 npm publish を実行します（prepublishOnly がビルドを自動実行するため、dist/ は常に最新の状態です。古いビルドを手動で npm run build して、まだ最新だと判断して公開することは絶対に避けてください）。npm への公開後、server.json（公式 MCP Registry）と manifest.json（以下の MCPB バンドル）の両方で version も更新して一致させ、mcp-publisher publish server.json を再実行してください。これらは相互に照合されない3つの個別のバージョン文字列であり、そうしないといずれかが気づかれないまま不一致になる可能性があります。

tsc は出力ファイルの実行権限を保持も設定もしないため、通常の npm run build では dist/index.js は 644 で生成され、bin 経由では実行できません。postbuild スクリプト（chmod +x dist/index.js）がビルドのたびにこれを修正するため、削除しないでください。

MCPB バンドル（Smithery、Claude Desktop のワンクリックインストール）

manifest.json は実際の MCPB マニフェストです（github.com/modelcontextprotocol/mcpb、manifest_version: "0.3"）。server.json（公式 MCP Registry 独自のマニフェスト形式）とは別のファイルで、名前が似ているものの、両者の仕様に関連はありません。npm run build:mcpb はクリーンなディレクトリ（dist/、manifest.json、本番環境用の node_modules、package.json。リポジトリ内の src/、テスト、Dockerfile、server.json は含みません）を用意し、実際の mcpb CLI（ローカルの devDependency である @anthropic-ai/mcpb）を使って scoutwyze-compute-mcp.mcpb にパッケージ化します。出力される .mcpb ファイルは gitignore の対象で、dist/ と同様、必要に応じて再生成します。

これは Smithery の stdio 公開フローが想定する形式です（smithery.ai/docs/build/publish に記載された smithery mcp publish ./scoutwyze-compute-mcp.mcpb -n <org>/<name>。一部のサンプルリポジトリに今も記載されている古い smithery.yaml 形式ではなく、2026-09-25 に実際のドキュメントで確認済みです）。CLI から公開するには、事前に一度だけ smithery auth login が必要です（GitHub OAuth を使う人間によるブラウザー操作）。そのため、これなしで一連の処理を完全にスクリプト化することはできません。同じ .mcpb ファイルは Claude Desktop のローカルへのワンクリックインストールにも使えます（ファイルをアプリにドラッグします）。

2026-09-25 に scoutwyze/compute-mcp として公開済みです （https://smithery.ai/servers/scoutwyze/compute-mcp）。公開までに実際に確認した重要な知見があります。manifest.json には意図的にトップレベルの tools 配列を含めていません。MCPB の仕様自体では許可されており、mcpb validate でも問題なく検証できますが、tools を含むバンドルを Smithery が stdio バンドルとして取り込むと、宣言されたツールごとに 400（"Invalid input: expected object, received undefined"）が発生します。二分探索によって、tools を含むマニフェストは毎回失敗し、同一のマニフェストからそれを除くと正常に公開できることを確認しました。user_config、env、その他すべてのオプションフィールドを含めても同様です。これは Smithery 側の取り込み処理に実際に存在する不備のようです（Smithery 自身のドキュメントでは、MCPB のよりシンプルな tools[] ではなく、ホスト型 URL サーバーの静的サーバーカードに使う、より豊富で別形式のツールスキーマ（@modelcontextprotocol/sdk/types.js 形式で、必須の inputSchema を含む）について説明しています）。こちらで修正できる問題ではありません。再公開時に、より完全なマニフェストに見えるからと tools を戻すと、また同じ問題が発生します。MCPB 独自のバリデーターで受け入れられるからといって、今も安全だと決めつけず、変更前に Smithery の取り込み処理が修正されているか確認してください。

このサーバーが文書化するだけでなく、実際に守るその他のルール

• フェイルクローズです。 実際の API へのネットワーク接続に失敗した場合、固定の一般的なエラーを返し、キャッシュされた結果や捏造した結果は返しません。
• SCOUTWYZE_API_KEY をツールの応答やエラーメッセージで絶対にエコーしません。 ネットワーク障害時も同様です（エラー経路では固定文字列を使い、基になるエラーオブジェクトを文字列に埋め込みません。そのオブジェクトには、理論上リクエストの詳細が含まれている可能性があります）。
• schema_version はそのまま受け渡します。 このサーバーは上流の応答本文を再構成も再解釈もしないため、呼び出し元のエージェントが将来のエンベロープ変更を自身で検出できます。