Rebase

@rebasepro/mcp

Rebase のスキーマ、データベース、ドキュメントの CRUD、ユーザー管理、開発サーバーのツールを AI アシスタントに提供する Model Context Protocol（MCP）サーバーです。

インストール

pnpm add -D @rebasepro/mcp

rebase init で作成されたプロジェクトには、CLI と同じバージョンに固定された状態で、すでに含まれています。このサーバーはプロジェクト独自の CLI を実行し、プロジェクト独自のバックエンドを呼び出すため、両方と同じリリースである必要があります。

ESM 専用です。"type": "module" を指定し、CommonJS ビルドはないため、import で読み込まれます。Node >=22.22.0（engines の下限）が必要です。このバージョンでは require() で読み込むこともできます。Node は 22.12 以降、require(esm) をサポートしています。

プロジェクト内のコピーを実行します。

pnpm exec rebase-mcp

このパッケージの機能

@rebasepro/mcp は、stdio を介して Model Context Protocol を実装し、AI アシスタント（Gemini、Claude、Cursor など）が Rebase プロジェクトを操作できるようにします。ツールを提供するほか、コレクション定義と生成されたスキーマを MCP リソースとして公開します。複数のローカルプロジェクトとリモートプロジェクトを管理するネイティブサポートも備えています。

複数プロジェクトのサポート

この MCP サーバーは、複数の Rebase プロジェクトを同時に管理できます。複数のワークスペースを開いた IDE で作業する場合や、ローカルの開発サーバーとリモートのステージング／本番環境の両方を操作する場合に最適です。

• レジストリ：プロジェクト設定は ~/.rebase/projects.json に保存されます。
• 自動検出：ローカルで rebase dev が実行中の場合、MCP サーバーはプロジェクトディレクトリ内の .rebase/state.json からアクティブな開発ポートとサービスキーを自動検出し、ローカル開発の設定を不要にします。

実行時に使用されるプロジェクトの決定方法

次の順序で優先されます。

1. 環境ブロック — REBASE_PROJECT_DIR、REBASE_BASE_URL、REBASE_API_TOKEN。いずれかが設定されている場合、起動のたびにそれらの値から default プロジェクトが再構築されます。再構築はエントリー全体に適用されます。以前の projectDir に対して登録されたトークンは、発行先ではなかったディレクトリに引き継がれず、破棄されます。
2. サーバーの作業ディレクトリ — rebase.json が存在する場合。~/.rebase/projects.json はマシン全体で使われますが、現在作業中のプロジェクトはホームディレクトリのキャッシュより優先されます。
3. 保存済みの default — 最初の 2 つで指定されない場合。

1 または 2 から導出された default がレジストリに書き戻されることはありません。起動のたびに再計算されます。これを書き戻すと、あるプロジェクトのディレクトリ、バックエンド URL、開発サービスキーが、そのマシン上のほかのすべてのプロジェクトが読み取るファイルに保存されてしまうためです。

自動検出は、3 つすべての場合で不足している値を補いますが、いずれかで指定された値（トークンも baseUrl も）を上書きすることはありません。検出では、開発サーバーのサービスキーを読み取ります。これはスコープの制限がない管理者シークレットです。そのため、登録済みの rk_live_* の限定的なキーは、rebase dev の実行中も引き続き使用されます。同様に、https://staging.example.com に登録されたプロジェクトが、通知なくローカルの開発ポートにリダイレクトされることもありません。両者の baseUrl が一致しない場合は、stderr に報告されます。不足値の補完は報告されません。トークンが登録されていない場合、SDK ツールは検出されたサービスキー（完全な管理者権限）で実行されますが、そのことは通知されません。

rebase init は、生成される .mcp.json に "env": { "REBASE_PROJECT_DIR": "." } を書き込みます。これはクライアントの作業ディレクトリを基準とし、プロジェクトレベルの設定ファイルではそのディレクトリがプロジェクトになります。

設定

サーバーは、環境変数と .env ファイルから設定を読み込みます。

変数	デフォルト値	説明
REBASE_PROJECT_DIR	process.cwd()	プロジェクトのルートディレクトリ（rebase.json があるディレクトリ）
REBASE_BASE_URL	http://localhost:3001	検出時に開発サーバーが見つからない場合の Rebase バックエンド URL
REBASE_API_TOKEN	（空）	アプリへの API 呼び出しに使用する認証トークン。REBASE_TOKEN（CLI のコントロールプレーン用トークン）がアプリに送信されることはありません。クラウドツールは、このトークンを CLI にのみ渡します
REBASE_MCP_ALLOW_REMOTE_WRITES	false	破壊的なツールをローカル以外のターゲットに対して実行できるようにします（下記参照）

サーバーは、$REBASE_PROJECT_DIR/.env または $REBASE_PROJECT_DIR/app/.env から .env の読み込みを試みます。これらの値はサーバー自体の設定に使用されます。CLI やサーバーが起動する開発サーバーには渡されません。これらはアクティブなプロジェクト独自の .env を読み込み、引き継がれた変数はその値より優先されるためです。また、チェックアウトが切り替えられたブランチも同様に、シェルでエクスポートしたかのように適用されます。

破壊的ツールの安全ゲート

rebase_project_add は任意の baseUrl を受け入れ、CLI ツールはプロジェクトの .env に記述された任意の DATABASE_URL に接続します。つまり、ノート PC の使い捨てデータベースを編集するツール群が、本番環境の行を削除する可能性があります。間にあるのは、どのプロジェクトが現在アクティブかを判断するアシスタントの判断だけです。

対象環境を変更するすべてのツールは、対象がループバックインターフェース上にない限り拒否されます。 ゲートの対象外となるものを列挙しているため、新たに追加されたツールはデフォルトで保護されます。

• ゲート対象外 — 読み取り： rebase_schema_plan、rebase_doctor、rebase_db_branch_list、rebase_db_branch_info、rebase_db_branch_diff、list_documents、get_document、list_users、list_roles、storage_list_objects、storage_get_download_url、cron_list_jobs、cron_get_job、cron_get_job_logs、rebase_dev_logs、および Rebase Cloud の読み取りツール rebase_cloud_status、rebase_cloud_logs、rebase_cloud_env_list、rebase_cloud_deployments_list。
• ゲート対象外 — Rebase Cloud への書き込み： rebase_cloud_provision、rebase_cloud_deploy、rebase_cloud_env_set、rebase_cloud_rollback。プロビジョニングではプロジェクトを作成してこのディレクトリをリンクします。ほかのツールはリンクされたクラウドプロジェクトを変更しますが、これらは rebase cloud を起動します。このコマンドは、CLI 独自の認証情報とコントロールプレーン独自の権限チェックを使って、プロジェクトの .rebase/cloud.json にリンクされたプロジェクトを操作します。ゲートがチェックできる baseUrl や DATABASE_URL は一切使用しません。
• ゲート対象外 — ローカルのみ： rebase_schema_introspect、rebase_db_branch_switch、rebase_schema_generate、rebase_db_generate、rebase_generate_sdk、開発サーバーのツール、およびプロジェクトレジストリーのツール。これらはローカルファイルまたはローカル状態を書き換えるだけで、チェック対象となるリモートのターゲットはありません。
• DATABASE_URL に対するゲート対象： ほかのすべての CLI ツール — rebase_db_push、rebase_db_migrate、rebase_db_branch_create、rebase_db_branch_delete。
• プロジェクトの baseUrl に対するゲート対象： ほかのすべての SDK ツール — create_document、update_document、delete_document、create_user、update_user、delete_user、rebase_auth_reset_password、storage_delete_object、cron_trigger_job、cron_toggle_job、invoke_function。

この 2 つのターゲットは置き換え可能ではありません。CLI ツールは baseUrl を参照しないため、本番環境の DATABASE_URL と並んで localhost のバックエンドがあっても、バックエンドではなくデータベースを基準にチェックされます。create_user と update_user は roles を設定するため、管理者を作成できます。invoke_function は任意の HTTP メソッドで任意の関数を呼び出します。cron_toggle_job は、スケジュールされたバックアップを通知なく無効化します。「追加的」という言葉が示す意味で、これらを取り消すことはできません。そのため、リストの方式を逆にしました。

ゲートがチェックする DATABASE_URL は、起動された CLI と同じ方法で解決されます。サーバーの起動元シェルで DATABASE_URL がエクスポートされている場合は、それが常に優先されます。それ以外の場合、ゲートは <root>/.env、<root>/backend/.env、DOTENV_CONFIG_PATH、および親ディレクトリの .env にあるすべての DATABASE_URL と ADMIN_CONNECTION_STRING（ブランチコマンドが受け付ける代替値）を、CLI と同じ方法で dotenv を使って解析します。そのうち 1 つでもリモート接続先であれば 拒否されます。接続文字列をまったく解決できない場合、DB ツールは拒否されます。検証できないターゲットは安全なターゲットではなく、子プロセスがこのプロセスからは見えないファイルを使って独自に解決するためです。

ローカルとして認められるのはループバック（localhost と *.localhost、127.0.0.0/8、::1、0.0.0.0）のみです。10.x や 192.168.x などのプライベート範囲は、ノート PC と同じくらい共有ステージングクラスターの可能性もあるため、ローカルとは見なされません。

REBASE_MCP_ALLOW_REMOTE_WRITES=true を設定すると、この制限を解除できます。

ブランチツール（rebase_db_branch_*）では管理者権限も必要で、GET /auth/me を通じて確認されます。このエンドポイントが応答するのは、サインイン済みユーザーのアクセストークンのみです。そのため、サービスキー（ディスカバリーで提供されるものを含む）または rk_live_* API キーを使う場合、すべてのブランチツールは「Admin authorization failed」で失敗します。

信頼できないデータのマーキング

行、ユーザーレコード、ストレージの一覧、cron ジョブ、関数の応答、CLI の出力は、明示的な <<<UNTRUSTED_DATA …>>> エンベロープ内で返されます。データベースに保存されたものはすべて誰かが書き込んだものであり、アシスタントが従っているツールの契約と同じチャネルで届きます。このエンベロープは、モデルに対して、それらを指示ではなく不活性なコンテンツとして扱うよう伝えます。これはマーカーであり、サンドボックスではありません。これらのツールを使うアシスタントの安全性は、読み取りを許可するコンテンツによってのみ決まります。

---

ツール

10 グループに分かれた 51 個のツールです。⚠ マークの付いたツールは、REBASE_MCP_ALLOW_REMOTE_WRITES=true が設定されていない場合、ローカル以外のターゲットに対する操作を拒否します。上記のゲートを参照してください。

スキーマとデータベース（13）

アクティブなプロジェクトディレクトリで Rebase CLI を起動します。

ツール	必須	説明
rebase_schema_generate	—	Rebase の TypeScript コレクション定義から Drizzle スキーマを生成します
rebase_db_push ⚠	—	現在の Drizzle スキーマをデータベースに直接適用します（開発用の簡易手段で、マイグレーションファイルをスキップします）
rebase_schema_introspect	—	稼働中のデータベースをイントロスペクションし、既存のテーブルから Rebase コレクション定義を生成します
rebase_db_generate	—	スキーマの変更から SQL マイグレーションファイルを生成します（現在の Drizzle スキーマと最後のエンティティを比較します）
rebase_db_migrate ⚠	—	保留中のすべての SQL マイグレーションをデータベースに対して実行します
rebase_generate_sdk	—	コレクション定義から、完全に型付けされた JavaScript/TypeScript SDK を生成します
rebase_doctor	—	コレクション定義、生成された Drizzle スキーマ、稼働中の PostgreSQL データベース間のスキーマの不整合を検出します
rebase_db_branch_create ⚠	name	新しいデータベースブランチを作成します（管理者のみ）
rebase_db_branch_list	—	すべてのデータベースブランチを一覧表示します（管理者のみ）
rebase_db_branch_delete ⚠	name	既存のデータベースブランチを削除します（管理者のみ）
rebase_db_branch_info	name	データベースブランチの情報とステータスを表示します（管理者のみ）
rebase_db_branch_diff	name	データベースブランチが、作成元のデータベースに対してどのような変更を加えたかを表示します（管理者のみ）。追加、削除、変更されたテーブル、列、制約、インデックス、トリガー、RLS ポリシー、列挙型、ビュー、関数を SQL として表示します。また、各テーブルについて、ブランチで挿入、更新、削除された行を主キーで照合し、サンプル行とともに表示します
rebase_db_branch_switch	—	このチェックアウトの接続先をデータベースブランチ、またはメインデータベースに切り替えます（管理者のみ）

スキーマ計画（1）

バックエンドに、変更によって何が起こるかを問い合わせます。CLI は使用せず、ファイルも書き込みません。

ツール	必須	説明
rebase_schema_plan	collectionId、collection	コレクションの変更によって実行される SQL を、実行せずに表示します

ドキュメント（5）

@rebasepro/client を介してコレクションに対する CRUD 操作を行います。

ツール	必須	説明
list_documents	collection	オプションのフィルタリング、並べ替え、ページネーションを指定して、Rebase コレクションのドキュメントを一覧表示します
get_document	collection、id	Rebase コレクションから ID を指定して単一のドキュメントを取得します
create_document ⚠	collection、data	Rebase コレクションに新しいドキュメントを作成します
update_document ⚠	collection、id、data	Rebase コレクション内の既存のドキュメントを更新します
delete_document ⚠	collection、id	Rebase コレクションからドキュメントを削除します

ユーザーとロール（6）

ツール	必須	説明
list_users	—	Rebase バックエンドに登録されているすべてのユーザーと、そのロールを一覧表示します
create_user ⚠	email	Rebase バックエンドに新しいユーザーを作成します
update_user ⚠	uid	既存のユーザーを更新します（メールアドレス、表示名、ロール）
delete_user ⚠	uid	Rebase バックエンドからユーザーを削除します
list_roles	—	Rebase バックエンドで定義されているすべてのロールを一覧表示します
rebase_auth_reset_password ⚠	email	管理 API を介してユーザーのパスワードをリセットします

開発サーバー（3）

ツール	必須	説明
rebase_dev_start	—	Rebase 開発サーバー（フロントエンド＋バックエンド）を起動します
rebase_dev_logs	—	実行中の Rebase 開発サーバーの最近の出力を読み取ります
rebase_dev_stop	—	実行中の Rebase 開発サーバーを停止します

ストレージ（3）

ツール	必須	説明
storage_list_objects	—	Rebase ストレージに保存されているファイル／オブジェクトを一覧表示します
storage_delete_object ⚠	key	Rebase ストレージからオブジェクト／ファイルを削除します
storage_get_download_url	key	Rebase ストレージ内のファイル用に、一時的な署名付きダウンロード URL を発行します

Cron（5）

ツール	必須	説明
cron_list_jobs	—	スケジュールされたすべての cron ジョブと、その設定状況を一覧表示します
cron_get_job	jobId	指定したスケジュール済み cron ジョブのステータスと詳細を取得します
cron_trigger_job ⚠	jobId	cron ジョブを直ちに手動で実行します
cron_get_job_logs	jobId	指定した cron ジョブの実行ログを読み取ります
cron_toggle_job ⚠	jobId, enabled	スケジュール済み cron ジョブを有効または無効にします

関数（1）

ツール	必須	説明
invoke_function ⚠	name	カスタムバックエンド Hono 関数（api/functions/:name に配置）を呼び出します

プロジェクトレジストリ（6）

ツール	必須	説明
rebase_project_list	—	登録済みの Rebase プロジェクトをすべて一覧表示し、アクティブなプロジェクトを示します
rebase_project_switch	name	名前を指定して、アクティブな Rebase プロジェクトを切り替えます
rebase_project_add	name	新しい Rebase プロジェクトを登録します
rebase_project_remove	name	プロジェクトレジストリから登録済みのプロジェクトを削除します
rebase_project_current	—	解決済み URL や認証ステータスなど、現在アクティブな Rebase プロジェクトの詳細を表示します
rebase_project_status	—	GET /health を呼び出して、アクティブなプロジェクトのバックエンドのヘルスチェックを行います

Rebase Cloud（8）

アクティブなプロジェクトのディレクトリで、CLI 独自の認証情報を使い、リンク先のプロジェクトに対して rebase cloud … --json を実行します。プロビジョニングはプロジェクトを作成し、デプロイ、環境変数の設定、ロールバックはリンク先のプロジェクトを変更します。これらは baseUrl や DATABASE_URL を使用しないため、ループバックゲートの適用対象外です。

ツール	必須	説明
rebase_cloud_provision	—	アカウントやサインアップなしで、アクティブなプロジェクトに Rebase Cloud 上のライブバックエンドを用意します。プロジェクトをプロビジョニングし、.env に REBASE_BASE_URL を設定して、ディレクトリをリンクし、ローカルのコレクションをデプロイします（rebase cloud init --claim）。続いて .env に REBASE_API_TOKEN を設定します。このキーを使うと、デプロイされたアプリが行レベルセキュリティを通じてデータを読み書きできます。キーはクレーム期間の終了時に期限切れになります
rebase_cloud_status	—	このディレクトリがリンクされている Rebase Cloud プロジェクトを表示します（rebase cloud status）
rebase_cloud_deploy	—	このディレクトリを、リンク先の Rebase Cloud プロジェクトにデプロイします（rebase cloud deploy）
rebase_cloud_logs	—	リンク先の Rebase Cloud プロジェクトのログを1回読み取ります。実行中のアプリまたは最新ビルドのログが対象です（rebase cloud logs）
rebase_cloud_env_list	—	リンク先の Rebase Cloud プロジェクトの環境変数を、値は表示せずに一覧表示します（rebase cloud env list）
rebase_cloud_env_set	key, value	リンク先の Rebase Cloud プロジェクトに環境変数を1つ設定します（rebase cloud env set KEY --stdin）
rebase_cloud_deployments_list	—	リンク先の Rebase Cloud プロジェクトの最近のデプロイを、新しい順に一覧表示します（rebase cloud deployments list）
rebase_cloud_rollback	—	リンク先の Rebase Cloud プロジェクトで、以前に成功したデプロイを再び稼働させます（rebase cloud rollback）

---

リソース

サーバーは、AI コンテキスト用の MCP リソースを公開します。

URI	説明
rebase://collections/{name}	コレクション定義の TypeScript ソース
rebase://schema	生成された Drizzle スキーマ（schema.generated.ts）

コレクションファイルは、アクティブなプロジェクトディレクトリ内の app/config/collections/、config/collections/、または collections/ から検出されます。

クイックスタート

AI アシスタントの MCP 設定（例：.gemini/settings.json）に追加します。

{
  "mcpServers": {
    "rebase": {
      "command": "pnpm",
      "args": ["--dir", "/path/to/your/project", "exec", "rebase-mcp"],
      "env": {
        "REBASE_PROJECT_DIR": "/path/to/your/project"
      }
    }
  }
}

MCP レジストリ

安定版リリースでは、このサーバーを MCP Registry に io.github.rebasepro/rebase として公開します。これは、MCP クライアントがインストールを案内するときに参照する登録情報です。この識別情報を持つファイルは 2 つあり、内容が一致している必要があります。

package.json → mcpName	公開済みの npm tarball から読み取られる所有権の証明
server.json	マニフェスト。同じ名前、バージョン、インストールする npm パッケージを記載します

リリース時に、どちらも手動で編集することはありません。publishable-packages.mjs --set-version は、すべての package.json とあわせて server.json にもバージョンを書き込み、pnpm check:publishable-set は両者が一致しないツリーを拒否します。レジストリは、マニフェストに記載された tarball をダウンロードして公開を検証するため、マニフェストの更新が漏れていると、npm を書き換えられなくなった最後の段階でリリースが失敗します。

安定版の公開ワークフローは、npm、タグ、フリートイメージの公開後に、npm の来歴証明ですでに取得している OIDC トークンを使って、レジストリ登録自体も公開します。手動実行の release.sh では公開できません。ログインにデバイスコードフローを使用するためです。そのため、最後の作業を完了するためのコマンドが表示されます。

mcp-publisher login github && mcp-publisher publish

brew install mcp-publisher で mcp-publisher をインストールし、何も公開せずにマニフェストを確認するには mcp-publisher validate を実行します。

関連パッケージ

• @rebasepro/client — データ API と管理 API の呼び出しに内部で使用されます