mcpField
R
render-automation

render-automation

github.com/sickn33クラウド・DevOps48.7k69 回インストール1 日前に更新
リポジトリ

render-automation について

render-automation は、Rube MCP 経由で Composio の Render ツールキットを操作するスキルです。サービスやプロジェクトの確認、デプロイの開始、状態の取得に対応し、対象と最終状態の確認を重視します。

主な機能

  1. 01Render サービスの一覧表示と絞り込み
  2. 02カーソルページネーションによるプロジェクト閲覧
  3. 03キャッシュ消去を指定したデプロイ開始
  4. 04デプロイ状態と詳細の取得
  5. 05サービス名からサービス ID の特定

活用シーン

  1. 01デプロイ対象のサービス確認
  2. 02サービスの手動デプロイや再デプロイ
  3. 03デプロイの成功や失敗の確認
  4. 04プロジェクトと関連サービスの閲覧

MCP 対応

Rube MCP を介して Composio の Render ツールキットにアクセスします。ワークフローには有効な Render 接続と最新のツールスキーマが必要です。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill render-automation

インストール後、Claude Code で/render-automationを入力して読み込まれたか確認します。

詳細

Rube MCP による Render の自動化

Rube MCP 経由で Composio の Render ツールキットを使用し、Render クラウドプラットフォームの操作を自動化します。

前提条件

  • Rube MCP が接続されていること(RUBE_SEARCH_TOOLS が利用可能)
  • ツールキット render を指定して RUBE_MANAGE_CONNECTIONS で Render への接続が有効になっていること
  • 現在のツールスキーマを取得するため、必ず最初に RUBE_SEARCH_TOOLS を呼び出すこと

セットアップ

Rube MCP の取得:クライアント設定で https://rube.app/mcp を MCP サーバーとして追加します。現在の MCP とサービスの認証を確認してください。エンドポイントを追加するだけでは、認証済み接続は確立されません。

  1. RUBE_SEARCH_TOOLS が応答することを確認し、Rube MCP が利用可能であることを確認します
  2. ツールキット render を指定して RUBE_MANAGE_CONNECTIONS を呼び出します
  3. 接続が ACTIVE でない場合は、返された認証リンクを開いて Render の認証を完了します
  4. ワークフローを実行する前に、接続ステータスが ACTIVE であることを確認します

作用範囲

操作を実行する前に、対象アカウント、環境、IDを正確に特定します。読み取り専用の一覧表示は、有料デプロイの実行を許可するものではありません。具体的な操作の影響を事前に確認し、ユーザーが許可した操作のみを実行します。返された識別情報とステータスを記録し、書き込み結果が不明確な場合は再試行の前に状態を照合します。また、リクエストが受け付けられたことを完了と見なさず、最終状態を確認します。

主なワークフロー

1. サービスの一覧表示と閲覧

使用するタイミング:ユーザーが Render のサービス(Web サービス、静的サイト、ワーカー、cron ジョブ)を探したり、詳細を確認したりしたい場合

ツールの呼び出し順序:

  1. RENDER_LIST_SERVICES — オプションのフィルターを指定してすべてのサービスを一覧表示します[必須]

主なパラメーター:

  • name:サービス名に含まれる文字列でフィルターします
  • type:サービスの種類でフィルターします('web_service'、'static_site'、'private_service'、'background_worker'、'cron_job')
  • limit:ページごとの最大結果数(デフォルトは20、最大100)
  • cursor:前回の応答から取得したページネーション用カーソル

注意点:

  • サービスの種類には、正確な列挙値を指定する必要があります:'web_service'、'static_site'、'private_service'、'background_worker'、'cron_job'
  • ページネーションにはカーソル方式を使用します。cursor がなくなるまで続けてください
  • 名前のフィルターは部分一致であり、完全一致ではありません
  • サービス ID は 'srv-xxxxxxxxxxxx' 形式です
  • デフォルトの上限は20です。すべてのサービスを確認するには、より大きな値を設定してください
2. デプロイの実行

使用するタイミング:ユーザーがサービスを手動でデプロイ、または再デプロイしたい場合

ツールの呼び出し順序:

  1. RENDER_LIST_SERVICES — デプロイするサービスを探します[前提条件]
  2. RENDER_TRIGGER_DEPLOY — 新しいデプロイを開始します[必須]
  3. RENDER_RETRIEVE_DEPLOY — デプロイの進行状況を確認します[任意]

主なパラメーター:

  • TRIGGER_DEPLOY の場合:
    • serviceId:デプロイするサービス ID(必須、形式:'srv-xxxxxxxxxxxx')
    • clearCache:デプロイ前にビルドキャッシュをクリアするには true を設定します
  • RETRIEVE_DEPLOY の場合:
    • serviceId:サービス ID
    • deployId:トリガー応答から取得したデプロイ ID(形式:'dep-xxxxxxxxxxxx')

注意点:

  • serviceId は必須です。まず LIST_SERVICES で特定してください
  • サービス ID は 'srv-' で始まります
  • デプロイ ID は 'dep-' で始まります
  • clearCache: true はクリーンビルドを強制します。時間はかかりますが、キャッシュ関連の問題を解決できます
  • デプロイは非同期です。RETRIEVE_DEPLOY を使用してステータスを確認してください
  • 別のデプロイが進行中にデプロイを開始すると、新しいデプロイがキューに追加される場合があります
3. デプロイステータスの確認

使用するタイミング:ユーザーがデプロイの進行状況や結果を確認したい場合

ツールの呼び出し順序:

  1. RENDER_RETRIEVE_DEPLOY — デプロイの詳細とステータスを取得します[必須]

主なパラメーター:

  • serviceId:サービス ID(必須)
  • deployId:デプロイ ID(必須)
  • 応答には status、createdAt、updatedAt、finishedAt、commit が含まれます

注意点:

  • serviceId と deployId の両方が必須です
  • デプロイのステータスには、'created'、'build_in_progress'、'update_in_progress'、'live'、'deactivated'、'build_failed'、'update_failed'、'canceled' があります
  • 'live' はデプロイが成功したことを示します
  • 'build_failed' または 'update_failed' はデプロイエラーを示します
  • レート制限を避けるため、適切な間隔(10~30秒)でポーリングしてください
4. プロジェクトの管理

使用するタイミング: ユーザーが Render プロジェクトを一覧表示して整理したい場合

ツールの順序:

  1. RENDER_LIST_PROJECTS - すべてのプロジェクトを一覧表示します [必須]

主なパラメータ:

  • limit: 1 ページあたりの最大結果数 (最大 100)
  • cursor: 前回のレスポンスからのページネーションカーソル

注意点:

  • プロジェクトは関連するサービスをまとめてグループ化します
  • ページネーションはカーソルベースのアプローチを使用します
  • プロジェクト ID は整理目的で使用されます
  • すべてのサービスがプロジェクトに割り当てられているとは限りません

一般的なパターン

ID の解決

サービス名 -> サービス ID:

1. Call RENDER_LIST_SERVICES with name=service_name
2. Find service by name in results
3. Extract id (format: 'srv-xxxxxxxxxxxx')

デプロイの検索:

1. Store deployId from RENDER_TRIGGER_DEPLOY response
2. Call RENDER_RETRIEVE_DEPLOY with serviceId and deployId
3. Check status for completion
デプロイと監視のパターン
1. RENDER_LIST_SERVICES -> find service by name -> get serviceId
2. RENDER_TRIGGER_DEPLOY with serviceId -> get deployId
3. Loop: RENDER_RETRIEVE_DEPLOY with serviceId + deployId
4. Check status: 'live' = success, 'build_failed'/'update_failed' = error
5. Continue polling until terminal state reached
ページネーション
  • 次のページにはレスポンスの cursor を使用します
  • cursor が存在しなくなるか、結果が空になるまで続けます
  • LIST_SERVICES と LIST_PROJECTS はどちらもカーソルベースのページネーションを使用します
  • ページネーションの回数を減らすには、limit を最大 (100) に設定します

既知の注意点

サービス ID:

  • 常に 'srv-' が先頭に付きます (例: 'srv-abcd1234efgh')
  • デプロイ ID には 'dep-' が先頭に付きます (例: 'dep-d2mqkf9r0fns73bham1g')
  • サービス名は常に LIST_SERVICES を介して ID に解決してください

サービスタイプ:

  • フィルタリング時には正確な enum 値を使用する必要があります
  • 使用可能なタイプ: web_service、static_site、private_service、background_worker、cron_job
  • サービスタイプによってデプロイの動作が異なります

デプロイの動作:

  • デプロイは非同期であるため、常に完了をポーリングしてください
  • キャッシュクリアを伴うデプロイは時間がかかりますが、古いキャッシュの問題を解決します
  • 失敗したデプロイは自動的にロールバックされません。以前のバージョンが稼働したままになります
  • 同時にトリガーされたデプロイはキューに入れられる場合があります

レート制限:

  • Render API にはレート制限があります
  • 頻繁なポーリングは避けてください。10〜30 秒の間隔を使用してください
  • 一括操作はスロットリングする必要があります

レスポンスの解析:

  • レスポンスデータは data キーの下にネストされている場合があります
  • タイムスタンプは ISO 8601 形式を使用します
  • オプションのフィールドにはフォールバックを用意して防御的に解析してください

クイックリファレンス

タスクツールスラッグ主なパラメータ
サービスの一覧表示RENDER_LIST_SERVICESname, type, limit, cursor
デプロイのトリガーRENDER_TRIGGER_DEPLOYserviceId, clearCache
デプロイステータスの取得RENDER_RETRIEVE_DEPLOYserviceId, deployId
プロジェクトの一覧表示RENDER_LIST_PROJECTSlimit, cursor

使用するタイミング

このスキルは、概要に記載されているワークフローやアクションを実行する場合に適用できます。

制限事項

  • このスキルは、タスクが上記の範囲に明確に一致する場合にのみ使用してください。
  • 出力を、環境固有の検証、テスト、専門家によるレビューの代替として扱わないでください。
  • 必要な入力、権限、安全上の境界、成功基準が欠けている場合は、停止して確認を求めてください。

コメント