@mgcrea/mcp-ovh-api

OVHcloud API 向けの Model Context Protocol サーバーで、Object Storage に焦点を当てています。バケット、オブジェクト、プロジェクトユーザー、S3 認証情報、そしてそれらを結びつけるストレージポリシーを扱います。

このサーバーはデフォルトで読み取り専用です。書き込みを無効にしている場合、変更系ツールは単に拒否されるだけでなく、そもそも登録されないため、エージェントはそれらを呼び出すことができません。

特徴

• OVHcloud の /1.0 API に対する精選されたツール群。説明には API の落とし穴が明記されています（知っておくべき落とし穴 を参照）。

• デフォルトで読み取り専用。 OVH_ALLOW_WRITES=1 で書き込みツールが追加されます。破壊的なツールはさらに、呼び出しのたびに明示的な confirm: true が必要です。

• OVH の認証方式をすべてサポートし、環境変数の有無に応じて自動的に選択されます。OAuth2 サービスアカウント（推奨）、アプリケーションキー + コンシューマーキー（SHA1 署名、自動クロックドリフト補正付き）、または静的アクセストークン。

• ポリシープリセット — OVH のロールショートカットにはない write-only を含みます。

• リスト結果は要約され、OVH の非推奨であるバケットごとの objects[] 配列（バケット内のすべてのオブジェクトを埋め込む）は両端で抑制されます。

• X-Ovh-QueryID はすべてのエラーで表示されます。OVH サポートが最初に尋ねるものだからです。

• 残りの API のための ovh_request エスケープハッチ（書き込みが有効でない限り GET のみ）。

• ネイティブ fetch を使用し、MCP SDK と Zod 以外のランタイム依存関係はありません。

インストール

pnpm install
pnpm build

設定

認証方式を 1 つ選択します。

(A) OAuth2 サービスアカウント — 推奨

1. https://www.ovh.com/manager/#/iam/service-account で IAM サービスアカウントを作成します。

2. パブリッククラウドプロジェクトに権限を付与する IAM ポリシーをアタッチします（オブジェクトストレージの場合: プロジェクトリソースに対して publicCloudProject:apiovh:*）。

3. クライアント ID とシークレットを .env にコピーします。

トークンの有効期限は 1 時間で、期限前にキャッシュされ更新されます。

(B) アプリケーションキー + コンシューマーキー

https://eu.api.ovh.com/createToken/ で 3 つ組を一度に作成します。ここで指定したアクセスルールは永久に固定されます — コンシューマーキーは後から拡張できないため、必要なものを最初に付与してください:

GET    /cloud/project/*
POST   /cloud/project/*
PUT    /cloud/project/*
DELETE /cloud/project/*
GET    /me

リクエストは secret+consumerKey+METHOD+URL+BODY+TIMESTAMP に対して SHA1 署名されます。OVH の時刻から ~30 秒以上ずれていると、すべての呼び出しが誤解を招く Invalid signature で失敗します。そのため、サーバーは起動時に /auth/time を一度プローブし、その差を補正します。

(C) 静的アクセストークン

OVH_ACCESS_TOKEN を設定すると、Authorization: Bearer として送信されます。

cp .env.example .env

実行

pnpm start   # speaks JSON-RPC over stdio

Claude Code に組み込む

.mcp.json（プロジェクト）または ~/.claude.json（グローバル）に追加します:

{
  "mcpServers": {
    "ovh": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-ovh-api/dist/cli.js"],
      "env": {
        "OVH_CLIENT_ID": "...",
        "OVH_CLIENT_SECRET": "...",
        "OVH_CLOUD_PROJECT": "abcdef0123456789abcdef0123456789",
        "OVH_REGION": "UK"
      }
    }
  }
}

ツールを調べる

npx @modelcontextprotocol/inspector node dist/cli.js

知っておくべき落とし穴

すべてツールの説明に組み込まれていますが、このサーバーの形状を説明しています:

1. *OVH にはバケットポリシーはなく、ユーザーポリシーのみがあります。* プロジェクトユーザーごとに 1 つの生の JSON ドキュメントがあり、そのドキュメントがアクセス制御の全表面です。ポリシーを設定すると、そのユーザーが以前にできたすべてのことを、すべてのバケットにわたって置き換えます。

2. ポリシーはバケットの所有者を制限できません。 OVH は ACL にフォールバックし、所有者は FULL_CONTROL を保持します: 「ユーザーがバケット所有者であり、ポリシーファイルに明示的な許可がない場合でも、ユーザーは許可されます。」 したがって、制限されたキーは、バケットを作成していない新しいプロジェクトユーザーに属している必要があります。ovh_provision_s3_user はバケットの ownerId をチェックし、所有者を指定すると拒否します。

3. 同じフォールバックがオブジェクトごとに適用されます。 オブジェクトをアップロードした人は誰でもそのオブジェクトを所有し、オブジェクト ACL を通じて FULL_CONTROL を取得します。したがって、s3:GetObject を単に省略しても、アップロード専用キーが自分が書き込んだすべてを読み戻すことを防げません — ライブ API で検証済みで、許可リストのみのポリシーは、他の誰かがアップロードしたすべてのオブジェクトを正しく拒否しながら、自分のアップロードをキーに提供しました。明示的な Deny は必要であり、ACL に勝ります。そのため、write-only プリセットには、単純な許可リストではなく Deny ステートメントが含まれています。

もう 2 つ小さなものがあります。s3:PutObject だけでは、許可されたプレフィックス内の既存キーの盲目的な上書きが可能です — 「書き込み専用」キーは追記専用キーではありません。これはバケットでバージョニングを有効にする良い理由です。また、ポリシーの変更が反映されるまでに最大 ~30 秒かかります: ovh_set_storage_policy の 5 秒後にプローブを実行しても、まだ古い動作が表示され、ポリシーが静かに失敗したように見えます。

ツール

プロジェクトスコープのすべてのツールはオプションの project を受け取り、すべてのストレージツールはオプションの region を受け取り、呼び出しごとに OVH_CLOUD_PROJECT / OVH_REGION を上書きします。W とマークされたツールは OVH_ALLOW_WRITES=1 の場合のみ存在します。⚠️ とマークされたツールは破壊的であり、さらに confirm: true が必要です。

ovh_whoami から始めてください。 どの認証方法が有効か、どのアカウントか、OVH とのクロック差を報告します — 署名方式での 401 はほぼ常にこれが原因です。

ovh_presign_object がバイトが移動する唯一の方法です。サーバーはオブジェクトコンテンツをプロキシせず、期限付きの署名付き S3 URL を発行します。書き込みがオフの場合、GET のみに署名します。

ポリシープリセット

ovh_preview_policy、ovh_set_storage_policy、ovh_provision_s3_user は 3 つのプリセットを共有し、すべてキープレフィックスにスコープできます:

OVH の組み込みロール（admin、deny、readOnly、readWrite、ovh_grant_bucket_access 経由）には書き込み専用の同等物がありません — そのため生のポリシーパスが存在します。マルチパートのペアは意図的に含まれています。すべての S3 SDK は ~8-16MB を超えると自動的にマルチパートに切り替わり、abort/list がないと、失敗したアップロードはキー所有者がクリーンアップできない孤立したパーツを残し、支払いが続きます。

OVH はポリシーアクションを固定の列挙型に対して検証し、未知のものがあるとドキュメント全体を 400 で拒否します — s3:GetObjectVersion と s3:DeleteObjectVersion は AWS には存在しますが、ここにはありません。プリセットは受け入れられたアクションのみを使用し、テストで固定されています。

書き込み専用アップロードキーの発行

動機となるケース: アプリが S3 キーを出荷バイナリに埋め込むため、キーはアップロードのみ可能で、読み書きキーは開発者が保持する必要があります。

ovh_get_bucket           bucket=dev-rgis-ar          → note ownerId
ovh_preview_policy       bucket=dev-rgis-ar preset=write-only prefix=uploads/
ovh_provision_s3_user    bucket=dev-rgis-ar preset=write-only prefix=uploads/ \
                         description=ar-app-uploader confirm=true

これにより新しいプロジェクトユーザー（バケット所有者ではない）が作成され、ポリシーが適用され、その後でのみ認証情報が発行されます — ポリシーより前に存在するキーは、デフォルトが許可するものを一時的に持っていたキーです。シークレットは一度だけ返されます。

引き渡す前に実際の S3 API に対して検証してください — 正しく読めるポリシーでも所有権によって影が薄くなることがあり、設定後 ~30 秒待ってからプローブしないと、以前のポリシーを調べることになります:

export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=...
# An array, not a string: zsh does not word-split an unquoted $var, so the
# `S3='aws ...'` form you would write in bash silently becomes "command not found".
S3=(aws --endpoint-url https://s3.uk.io.cloud.ovh.net --region uk s3api)
"${S3[@]}" put-object      --bucket dev-rgis-ar --key uploads/probe.txt --body /dev/null   # 200
"${S3[@]}" get-object      --bucket dev-rgis-ar --key uploads/probe.txt /dev/null          # 403
"${S3[@]}" list-objects-v2 --bucket dev-rgis-ar                                            # 403
"${S3[@]}" delete-object   --bucket dev-rgis-ar --key uploads/probe.txt                    # 403
"${S3[@]}" put-object      --bucket dev-rgis-ar --key elsewhere/probe.txt --body /dev/null # 403

get-object 行が重要です。これは落とし穴 3 を検出するチェックであり、プリセットの Deny があるためだけに成功します。

開発

pnpm dev            # tsdown --watch
pnpm test           # vitest
pnpm typecheck
pnpm lint
pnpm format

ライセンス

MIT