Render Useful MCP

render-useful-mcp

Render 向けの Model Context Protocol サーバーです。公式 Render Public API のすべてのエンドポイントに加え、生の API では手間のかかるワークフロー向けの高レベルなツールをいくつか提供します。

TypeScript で記述されています。すべての API ツールは Render 独自の OpenAPI ドキュメントから生成されるため、網羅性が保証され、今後も維持されます。

213 個のツール：Render Public API の全 208 操作（仕様バージョン 1.0.0）に、生の API では手間のかかる一連の操作向けのワークフローツール 5 個を加えています。

📖 ドキュメントサイト · ツールカタログ · llms.txt

---

このサーバーを選ぶ理由

多くの API ラッパーは厳選した一部のエンドポイントにとどまるため、内容が古くなり、作者が省いた機能が必要になった途端に行き詰まります。

• 設計上、完全です。 Render 独自の OpenAPI ドキュメントに含まれるすべての操作がツールになります。API があなたのキーに許可しているすべての操作を、追加設定なしですぐに利用できます。
• モデルが使いやすい設計です。 名前から ID をあいまい検索で解決し、ワークスペース ID は自動入力され、デプロイは 1 回の呼び出しで完了まで待機できます。また、エラー時には単なるステータスコードではなくヒントが返されます。
• 必要に応じて対象を絞れます。 すべてのツールセットはデフォルトで有効です。RENDER_MCP_TOOLSETS と RENDER_MCP_READ_ONLY は、利用範囲を意図的に制限するためのものであり、利用を制限するための必須設定ではありません。
• リスクを正直に扱います。 MCP の破壊的操作／読み取り専用／冪等性に関するアノテーションは、実際の HTTP セマンティクスに基づいているため、クライアントは妥当な自動承認の判断を行えます。コレクション全体を置き換える PUT も含まれ、呼び出し元が指定しなかった項目はすべて削除されます。ログ内のシークレットはマスキングされます。

インストール

どちらのボタンも、API キーのプレースホルダーを含む設定を入力します。インストール後に置き換えてください。

Claude Code — すべてのプロジェクトで使えるよう、グローバルにインストールします。

claude mcp add render --scope user -e RENDER_API_KEY=rnd_your_key -- npx -y render-useful-mcp

重要なのは --scope user の部分です。Claude Code はデフォルトで local スコープを使用するため、サーバーは現在のディレクトリにのみ登録されます。そのため、インストールした場所では動作しますが、ほかの場所では利用できません。新しく追加したサーバーが見つからなくなる原因としてよくあるのは、この設定です。3 つのスコープは次のとおりです。

スコープ	フラグ	保存場所	利用可能な範囲
ユーザー（グローバル）	--scope user	ユーザー設定	すべてのプロジェクト、すべてのディレクトリ
プロジェクト	--scope project	.mcp.json、コミット済み	リポジトリをチェックアウトしたすべてのユーザー
ローカル	なし（デフォルト）	ディレクトリごとのユーザー状態	追加したディレクトリ

claude mcp list で確認してください。別のディレクトリから実行したときに render が一覧にない場合は、--scope user を付けてコマンドを再実行してください。

Claude Code のプラグインとしてインストールする場合 — サーバーとドキュメントを一度に設定できます。プラグインは仕様上、グローバルにインストールされます。

/plugin marketplace add LuSrodri/render-useful-mcp
/plugin install render-useful-mcp@lusrodri-render

Claude Code を起動するシェルで RENDER_API_KEY をエクスポートしてください。プラグインはキーを保存せず、環境変数から読み取ります。詳細は plugin/README.md を参照してください。

Claude for macOS and Windows のデスクトップ拡張機能として使う場合は、最新リリースから .mcpb バンドルをダウンロードして開いてください。Claude がインストールし、フォームで API キーを求めるため、手動で設定する必要はありません。バンドルには依存関係が含まれているため、npm やグローバルな Node のインストールは不要です。

デスクトップへのインストールでは、すべてのツール定義が会話ごとにコンテキストを消費するため、全カタログではなく、デフォルトで services、logs、env-groups のツールセットが有効になります。変更するには、Toolsets フィールドに all または任意のカンマ区切りリストを設定してください。

デスクトップ拡張機能を除き、どのインストール方法でも Node.js ≥ 20.11 が必要です。

npm install -g render-useful-mcp

または、インストールせずに実行することもできます。ほとんどの MCP クライアント設定では、この方法を使います。

npx -y render-useful-mcp

MCP Registry に io.github.LuSrodri/render-useful-mcp として掲載されています。そのため、レジストリを参照できるクライアントは、npm パッケージを手動で指定しなくても見つけて設定できます。

MCP クライアントを設定する

Render Dashboard → Account Settings → API Keys から API キーを取得してください。

Claude Code — 上記のようにグローバルに設定します。

claude mcp add render --scope user -e RENDER_API_KEY=rnd_your_key -- npx -y render-useful-mcp

RENDER_WORKSPACE_ID がわかる場合は、同じ方法で追加してください。

claude mcp add render --scope user \
  -e RENDER_API_KEY=rnd_your_key \
  -e RENDER_WORKSPACE_ID=tea_your_workspace_id \
  -- npx -y render-useful-mcp

Claude Desktop／mcpServers を使用するクライアント — 設定ファイルに追加します。

{
  "mcpServers": {
    "render": {
      "command": "npx",
      "args": ["-y", "render-useful-mcp"],
      "env": {
        "RENDER_API_KEY": "rnd_your_key_here",
        "RENDER_WORKSPACE_ID": "tea_your_workspace_id"
      }
    }
  }
}

RENDER_WORKSPACE_ID は省略可能ですが、設定することをおすすめします。多くの Render エンドポイントでは、モデルが推測できない ownerId が必要です。設定すると、ほぼすべてのセッションでの検索を省けます。render_list_owners ツールで確認するか、ダッシュボードの URL から取得してください。

設定

変数	デフォルト	説明
RENDER_API_KEY	—	必須です。 Render API キーです。
RENDER_WORKSPACE_ID	—	ownerId が必要で指定されていない場合に適用されるワークスペース ID です。
RENDER_MCP_TOOLSETS	all	ツールセットをカンマ区切りで指定して、対象を絞り込みます。
RENDER_MCP_READ_ONLY	false	true の場合、変更を行わない（GET）ツールのみが公開されます。
RENDER_MCP_DYNAMIC_TOOLSETS	true	ツールセットとその状態を報告する render_toolsets を登録します。
RENDER_MCP_TIMEOUT_MS	60000	リクエストごとのタイムアウトです。
RENDER_MCP_MAX_RETRIES	3	レート制限および一時的なサーバーエラーが発生した場合の再試行回数です。
RENDER_MCP_MAX_RESPONSE_BYTES	400000	このサイズを超えるツールの結果は、注記を付けて切り詰められます。
RENDER_MCP_LOG_LEVEL	info	debug、info、warn、error、silent を指定します。ログは stderr に出力されます。
RENDER_API_BASE_URL	https://api.render.com/v1	プロキシまたはテスト用の上書き値です。

ツールセット

17 個すべてのツールセットがデフォルトで有効です — サーバーは、API キーでアクセスできるすべてのものを公開します。ツールセットは、意図的に対象範囲を 狭める ためのものであり、解除しなければならないゲートではありません。

ツールセット	ツール	対象範囲
services	43	サービス、デプロイ、カスタムドメイン、単発ジョブ、cron ジョブの実行とイベント
metrics	23	CPU、メモリ、帯域幅、HTTP、ディスク、接続のメトリクス、およびメトリクスストリーム
postgres	21	Postgres インスタンス、ユーザー、エクスポート、リカバリー、クエリの分析情報
workflows	15	Render ワークフローとワークフロータスク
env-groups	13	環境グループ、その変数、シークレットファイル
projects	12	プロジェクトと環境
webhooks	11	Webhook と通知設定／オーバーライド
logs	10	ログクエリ、ラベルの検出、ログストリームの設定
static-sites	9	静的サイトのヘッダールールとリダイレクト／リライトのルート
deprecated	8	Render が Key Value API に置き換えたレガシー Redis エンドポイント
key-value	8	Key Value（Redis 互換）インスタンスと接続情報
workspaces	8	ワークスペース、メンバー、認証済みユーザー、監査ログ
disks	7	永続ディスクとそのスナップショット
blueprints	6	Blueprint と Blueprint の同期
network	5	専用アウトバウンド IP セット
registry	5	コンテナレジストリの認証情報
maintenance	4	スケジュールされたメンテナンスの実行

それでも対象範囲を狭める理由としては、次のようなものがあります。

// A client that struggles with the full catalogue, or a session scoped to one job.
"env": { "RENDER_MCP_TOOLSETS": "services,logs,metrics" }

// An agent that should be able to look but not touch.
"env": { "RENDER_MCP_READ_ONLY": "true" }

対象範囲を狭めた場合でも、モデルは render_toolsets を呼び出して、存在するすべてのツールセットと無効になっているグループを確認できるため、何を変更すればよいかを正確に判断できます。対象範囲を広げるには、RENDER_MCP_TOOLSETS を編集してサーバーを再起動します。プロトコルリビジョン 2026-07-28 では、tools/list の結果が接続ごと、または別の呼び出しの副作用によって変わらないことが求められるため、有効なセットは起動時に固定されます。

ツール

ワークフローツール

これらは、どのツールセット構成でも常に利用できます。同等の生の手順では、通常モデルが最初の試行で間違える複数の呼び出しが必要になるため、用意されています。

ツール	機能
render_find_service	部分的な名前やおおよその名前も含め、サービス名から単一の Render サービスを特定し、その ID と類似する候補を返します。
render_recent_logs	サービス名とワークスペース ID を解決し、サービスの最近のログ行を取得します。
render_service_status	サービスの設定、最新のデプロイ、実行中のインスタンス、直近のエラーレベルのログを一度の呼び出しでトリアージします。
render_toolsets	すべての Render ツールセットと、それぞれのツール数および現在有効かどうかを一覧表示します。
render_wait_for_deploy	デプロイが終了状態（live、build_failed、update_failed、canceled、deactivated）に達するまで、またはタイムアウトになるまでポーリングします。

API ツール

Render の各エンドポイントに 1 つずつ用意され、render_<operation_id> という名前が付いています。たとえば render_list_services、render_create_deploy、render_update_postgres などです。それぞれに、Render の仕様から取得した概要、説明、パラメーターのドキュメント、列挙値、制約がそのまま含まれています。全一覧はツールカタログページをご覧ください。

モデルがツールを使いやすくするために

生成されたツールの良し悪しは、その仕様にどれだけ適切に記述されているかで決まります。Render の仕様は使用方法ではなく、構造を記述しています。この隔たりを埋めるのが、次の 3 つです。

oneOf の各分岐は名前を保持し、どれを適用するかを示します。 $ref をデリファレンスすると通常はスキーマ名が失われるため、render_create_service の serviceDetails は、どの type に対応するのかを示すものがない、構造のよく似た無名オブジェクトが 5 つ並んだ状態になっていました。各分岐には Render の仕様にある名前が title として付くようになったため、cron_job → cronJobDetailsPOST や runtime: docker → dockerDetails といった選択を、モデルが実際に行えるようになりました。

分岐に名前を付けると選択内容は読み取れるようになりますが、検証はできません。また、Render の仕様には discriminator がありません。oneOf の「ちょうど 1 つ」というルールでは、何も必須としない分岐である staticSiteDetailsPOST がすべてのペイロードを受け入れるため、残りの 4 つは到達不能になります。src/tools/schema-unions.ts は、分岐を選択するプロパティをキーにした if／then ルールへこれらのユニオンを書き換えます。そのため、対応関係は説明文での助言ではなくスキーマの一部となり、誤った分岐のフィールドは「oneOf のスキーマにちょうど 1 つ一致する必要があります」ではなく、フィールド名を指定して拒否されます。ビルド時の不変条件により、oneOf の分岐が到達不能のまま残っているとジェネレーターは失敗します。また、test/payloads.test.ts は全 208 ツールについて、実際のペイロードを使ってプロパティを検証します。

呼び出し元が値を入力できないフィールドは削除します。 Render の仕様は一部のリクエストボディでレスポンススキーマを再利用しているため、サーバーが生成する値まで含まれます。たとえば、cron ジョブの Docker 分岐では、認証情報の id と最終変更時刻を必須とする registryCredential オブジェクト全体が求められますが、ウェブサービスでは単純な registryCredentialId が使われます。捏造した値でしか埋められないフィールドは、フィールドがないよりも悪いため、src/tools/schema-repairs.ts で削除し、使用上の注意では Render が実際に参照先として使う image.registryCredentialId を案内します。該当箇所に一致しなくなるとジェネレーターは失敗するため、上流での修正はビルドエラーとして検出されます。

一部のツールには、手書きの使用上の注意を付けています。 src/tools/operation-hints.ts は、モデルが明らかに誤用しやすい操作に Usage: 段落を追加します。create-service には一通りの実行例を、update-env-vars-for-service には環境変数セット全体を置き換えることを、post-job には cron ジョブの作成方法ではないことを記載しています。例は説明文ではなくデータです。テストスイートでそれぞれのツールスキーマに照らして検証し、同じオブジェクトから説明文へ出力するため、公開される例はサーバーが受け入れることを実証済みのものです。Render が取り下げた操作をヒントが参照していると、ジェネレーターは失敗するため、このファイルが気付かれないまま古くなることはありません。

サーバーは instructions を送信します。 src/instructions.ts は initialize 時に一度だけ配信されます。内容は、ID のプレフィックス、先に名前を解決すること、生の一連の操作に代わるワークフローツール、oneOf の規約です。複数のツール説明文に重複して書くのではなく、ツールをまたぐ助言はここに記載します。

Docker イメージを実行する cron ジョブを作成する

この例が、ここで説明した 3 つの変更のきっかけです。cron ジョブはサービスなので、次のようにします。

// render_create_service
{
  "type": "cron_job",
  "name": "nightly-report",
  "ownerId": "tea-…",
  "repo": "https://github.com/acme/reports",
  "branch": "main",
  "serviceDetails": {
    // the cronJobDetailsPOST branch
    "runtime": "docker",
    "schedule": "0 3 * * *", // five-field cron, UTC, required for cron jobs
    "plan": "starter",
    "region": "oregon",
    "envSpecificDetails": {
      // the dockerDetails branch, because runtime is docker
      "dockerfilePath": "./Dockerfile",
      "dockerContext": ".",
      "dockerCommand": "python report.py",
    },
  },
}

ビルドの代わりにビルド済みイメージを使う場合は、repo／branch を削除し、image に {"ownerId": "tea-…", "imagePath": "docker.io/acme/reports:latest"} を設定し、"runtime": "image" を使って、envSpecificDetails には dockerCommand だけを指定します。スケジュールは後から render_update_service で変更し、予定外の実行は render_run_cron_job で起動します。render_create_job は別の機能で、既存のサービス上で一度だけコマンドを実行します。

設計メモ

手書きではなく生成されます。 scripts/generate-operations.ts は spec/render-openapi.json を読み込み、ツールカタログを出力します。厳格な処理を行うため、対応付けられていないタグ、名前の衝突、循環する $ref、テンプレートにないパスパラメーター、クエリパラメーターと名前が衝突するリクエストボディのプロパティがあると、微妙に誤ったツールを生成するのではなく、ビルドが失敗します。新しい Render API バージョンへの更新手順は、新しい仕様を配置して npm run generate を実行し、差分を確認するだけです。

スキーマはそのままクライアントに渡されます。 Render の仕様では、JSON Schema の幅広い機能が使われています。ツールスキーマは完全に参照を解決してから渡され、Ajv がそれに対して引数を検証するため、列挙型、パターン、フォーマット、oneOf がすべて実際に適用されます。そのため、このサーバーでは Zod スキーマのみを受け付ける McpServer ではなく、SDK の低レベルな Server を使用しています。意図的に書き換えているのは、前述した識別子のないユニオンだけです。仕様の記述どおりのままでは、これらを満たすことはできません。

リクエストボディはフラット化されます。 リクエストボディのプロパティをトップレベルのツール引数にすることで、呼び出し箇所を簡潔にし、ツール呼び出しの精度を高めています。ジェネレーターは、リクエストボディのプロパティがパスパラメーターやクエリパラメーターと衝突しないことをビルド時に検証します。配列または oneOf の値を持つ6つのリクエストボディは、単一の body 引数の中で構造を維持します。

エラーは次の行動につながる情報を返します。 失敗時には、HTTP ステータス、Render 独自のメッセージ、実際の原因に応じたヒントを返します。たとえば、404 では一覧取得の呼び出しで ID を確認するよう促し、401 では API キーのページを案内します。登録済みでも非表示のツールについては、「不明なツール」ではなく、有効にするツールセットを示します。

リトライは慎重に行います。 レート制限と一時的な 5xx エラーは、Retry-After に従い、相関ジッターを用いたバックオフで再試行します。サーバーエラー時に冪等でないメソッドが再実行されることはありません。POST /deploys を再試行すると、デプロイが二重に実行されるためです。

シークレットはログに出力されません。 ログは stderr に構造化 JSON 形式で出力されます。stdout はトランスポート用です。接続文字列、API キー、トークンはマスキングされます。

開発

npm install
npm run generate    # rebuild the tool catalogue from the OpenAPI spec
npm run docs        # re-render every doc that quotes the catalogue
npm run build
npm test
npm run check       # generate + docs + lint + typecheck + test

ドキュメントも生成されます

ツールの数、ツールセットの表、ワークフローツールの一覧、ドキュメントサイト、llms.txt、llms-full.txt はすべて、scripts/generate-docs.ts が src/generated/operations.json から生成します。このファイルと plugin/README.md の `` マーカーで囲まれた領域はその場で書き換えられ、サイトのファイルは全体が書き出されます。

npm run docs:check はすべてを再生成し、コミット済みの内容と異なる場合は失敗します。CI はすべてのプルリクエストでこれを実行し、Pages ワークフローはデプロイ前に実行します。また、仕様の同期時には npm run docs を実行するため、API の変更とその説明文が、レビューしやすい1つのプルリクエストにまとまります。これにより、ドキュメント内の数値がカタログと気付かれないまま食い違うことはありません。以前は実際に食い違っていました。

テストスイートでは、カタログの不変条件（208件すべての操作、宙ぶらりんの $ref がないこと、パスパラメーターが必須であること、アノテーションが HTTP の意味論と一致すること）、リクエストのマッピング、リトライとページネーションの動作、複合ツール、メモリー内で MCP クライアントとサーバーを往復させる一連のテストを網羅しています。

デスクトップ拡張機能のビルド

npm run build:mcpb   # -> build/render-useful-mcp-<version>.mcpb

これにより、dist/ と本番用の依存関係ツリーを build/mcpb/ にステージングして、パッケージ化します。このバンドルは設計上、単体で動作します。Claude はインストール手順なしで実行するためです。そのため、依存関係は再インストールせず、このリポジトリの node_modules からコピーします。これにより、成果物にテストスイートが実際に使用したものと同じツリーが含まれることが保証されます。

リポジトリのルートにある manifest.json は拡張機能のマニフェストです。npm version を使うと、パッケージのバージョンと連動して更新されます。ビルド済みのバンドルを確認するには、次を実行します。

npx mcpb info build/render-useful-mcp-<version>.mcpb
npx mcpb unpack build/render-useful-mcp-<version>.mcpb /tmp/check

新しい Render API バージョンへの更新

この処理は自動化されています。.github/workflows/spec-sync.yml は毎日実行され、Render の最新の API 定義を取得して、カタログとドキュメントを再生成します。ツールの構成に実際の変更があった場合は、追加、削除、形状が変更されたツールの概要と、破壊的変更がある場合はその警告を添えて、プルリクエストを作成します。自動でマージされることはありません。

変更が見つからなかった実行も含め、毎回ジョブのサマリーに記録されます。そのため、「今日チェックされたか」はプルリクエストがないことから推測するのではなく、Actions タブで確認できます。

スケジュールには意図的な工夫が 2 つあります。どちらも、実際には正常に動いていたのに、ジョブが停止したように見えたことがきっかけです。

• 47 5 * * * であり、0 6 * * 1 ではありません。 GitHub のスケジュール実行ワークフローはベストエフォートでキューに登録され、負荷が高いとスキップされます。毎時ちょうどは、最も競合が激しい時間帯です。実際に確認されたスケジュール実行の 1 件は、開始が 4 時間近く遅れました。目立たない分の毎日実行にすることで、実行がスキップされた場合の遅れは 2 週間ではなく 1 日で済みます。また、カタログに変更がなければ実行は早期終了するため、毎日実行しても CI のコストは数秒です。
• .github/spec-sync-heartbeat.json。 GitHub は、60 日間アクティビティがないリポジトリのスケジュール実行ワークフローを無効にします。無効になったワークフローは、自身を再度有効にできません。記録されたタイムスタンプが 20 日以上前の場合、ワークフローはそのファイルに新しいタイムスタンプをコミットします。これは年間およそ 18 回のコミットにあたり、制限まで十分な余裕を保つとともに、定期処理が稼働していることを git のログで確認できるようにします。

手動で実行する場合、または今すぐ確認する場合は、次のコマンドを実行してください。

npm run sync-spec   # fetch the current spec into spec/render-openapi.json
npm run generate    # rebuild the catalogue from it
git diff src/generated/operations.json
npm test

Render は OpenAPI ドキュメントを安定した URL で公開していません。ドキュメントに記載された .json および .yaml のエンドポイントは 404 を返すため、scripts/fetch-spec.ts はドキュメントの HTML から抽出します。この方法は本質的に不安定なので、抽出した内容（タイトル、サーバー、操作の最小数）を検証し、不完全な仕様で既存の仕様を上書きするのではなく、エラーを明確に出して失敗します。Render がドキュメントのプラットフォームを変更した場合、同期ワークフローは「変更なし」と報告し続けるのではなく、失敗します。

生成ツールは、完全に解釈できないカタログの出力を拒否します。マッピングされていないタグ、名前の衝突、循環する $ref、テンプレートにないパスパラメーター、クエリパラメーターと名前が衝突するボディプロパティがある場合は、いずれもビルドが失敗します。また CI では、コミット済みのカタログが仕様から生成される内容と一致することも検証するため、仕様を更新しても再生成しなければマージできません。

リリース

リリースでは、パッケージを npm に、パッケージに関するメタデータを MCP Registry に公開します。どちらもワークフローの GitHub OIDC トークンで認証します。npm は Trusted Publishing、レジストリは mcp-publisher login github-oidc を使うため、npm トークンやレジストリのシークレットをどこにも保存しません。 npm への公開にはプロベナンス証明が付与されます。

npm version patch    # or minor / major
git push --follow-tags

v* タグをプッシュすると .github/workflows/publish.yml が実行され、タグが package.json と一致していること、生成されたカタログとドキュメントが最新であることを確認します。次に、2 つの公開先のうち、このバージョンの公開がまだ必要な先を判定してから、リント、型チェック、テスト、ビルド、公開を行います。また、.mcpb バンドルをビルドして GitHub Release に添付します。デスクトップ拡張機能はここからのみ配布されます。

ドキュメントのチェックをここで再度行うのは、README.md が npm の tarball に含まれ、どのコミットからでもタグを作成できるためです。npm のバージョンは変更できないため、隣にあるカタログと内容が矛盾する README を含むパッケージは取り消せません。

実行順序は固定されており、最初に npm、次にレジストリです。レジストリは、公開済みの tarball を取得し、その package.json に mcpName があることを確認してパッケージの所有権を証明します。そのため、npm でまだ配信されていないバージョンは受け付けられません。

コード以外の理由でリリースに失敗した場合は、Actions タブから Run workflow を選び、Use workflow from でタグを選択して再実行してください。各公開先は個別にチェックされるため、リリースが途中まで完了した状態で再試行しても、すでに成功した公開先はスキップされ、npm の変更できないバージョンが原因で失敗することはありません。ワークフローはブランチからのディスパッチを拒否するため、公開されるバージョンは常にタグに対応します。

レジストリマニフェスト

server.json は、このサーバーのメタデータをレジストリに登録したものです。そのフィールドのうち、重要な役割を持つ 2 つは test/server-json.test.ts で検証されます。

• name は io.github.LuSrodri/... でなければなりません。レジストリは OIDC トークンの repository_owner クレームから公開可能な名前空間を導き出し、大文字と小文字を区別して照合するため、小文字にした表記は 403 で拒否されます。
• package.json の mcpName は、同じ name と一致しなければなりません。これは上記の所有権の証明に使われる値であり、これがないとレジストリはパッケージを拒否します。

バージョンフィールドは package.json に合わせます。npm version は version ライフサイクルスクリプトを使ってこれらの値を同期するため、クリーンなローカルチェックアウトからでも mcp-publisher publish を実行できます。CI では公開前にタグから再度値を設定するため、何を公開するかはタグによって決まります。

プライバシー

テレメトリーも分析機能もバックエンドもありません。サーバーはお使いのマシン上で動作し、接続するホストは Render の API だけです。キーは環境から読み込まれ、Render にのみ送信され、ディスクには書き込まれず、ログ出力ではマスクされます。各項目をご自身で検証する方法を含む詳細については、PRIVACY.md をご覧ください。

ライセンス

MIT — LICENSE をご覧ください。

Render とは提携していません。spec/render-openapi.json は Render が公開している API の仕様で、ビルドの再現性を確保するためにベンダー管理しています。