angular-signal-forms-migration-mcp

AIコーディングエージェントが、Angular Reactive Forms から Angular Signal Forms への移行を支援するMCPサーバーです。

コードベース内の Reactive Forms 構文を検出し、安全な機械的リネームと、人間の判断が必要なものとを仕分けし、記憶頼みではなく実際のAngularリリースに対して検証済みの before→after レシピを返します。

インストール

Node.js 20+ が必要です。クローンするものはありません — npx が必要に応じて取得します。

claude mcp add signal-forms-migration -- npx -y angular-signal-forms-migration-mcp@latest

または、任意のMCPクライアント設定に追加します:

{
  "mcpServers": {
    "signal-forms-migration": {
      "command": "npx",
      "args": ["-y", "angular-signal-forms-migration-mcp@latest"]
    }
  }
}

@latest を指定すると npx が起動のたびに再解決するため、エディタを再起動するだけで新しいリリースが取り込まれます。指定しない場合、npx は最初にキャッシュしたバージョンを配信し続けます — 設定を @latest に変更するか、npm cache clean --force でキャッシュをクリアしてください。

サーバーは1日1回新しいバージョンを確認し、stderr に1行の通知を書き込みます。これはスロットルされ、2秒でタイムアウトし、stdout には一切触れず、失敗時は何も出力しません。無効にするには、上記の設定ブロックに "env": { "SIGNAL_FORMS_MCP_NO_UPDATE_CHECK": "1" } を追加してください。実際に何が起動しているかを確認するには:

npx angular-signal-forms-migration-mcp@latest --version

[!IMPORTANT] これを Angular アプリに npm install しないでください。 これはエディタが起動する独立したプロセスであり、プロジェクトが依存するライブラリではありません。npx はプロジェクト外のキャッシュに保持します。

[!NOTE] 検出と助言を行いますが、コードを編集するツールは一切ありません。 ソースファイルに書き込むツールは今もなく、今後も作る予定はない。サーバーは検出結果とレシピを返します。変更を決めて編集するのはあなた側のエージェントです。したがって、すべての変更は通常のレビューとバージョン管理を経ることになります。

Related MCP server: VA Form Generation MCP Server

見た目

> Migrate the forms in src/app/checkout to Signal Forms.

  1. find_form_candidates { path: ".../src/app/checkout" }
     → 9 findings across 2 files: 6 mechanical, 3 judgment
       (the FormArray of line items is judgment — its shape changes)
  2. get_signalforms_recipe { construct: "FormBuilder.group" }
     → before/after + caveats
  3. the agent applies the edits, you review the diff
  4. verify_migration { path: ".../checkout.component.ts" }
     → traps that compile and are still wrong

助言の前にチェックする前提条件

移行レポートは、移行を不可能にする条件を最初に示します。実行してない計画よりは無いほうがましというわけだ。

1. Angular 21+。 @angular/forms/signals は v21 より前には存在しません。v21 未満の場合、サーバーは移行プランではなくアップグレードプランを返します。

2. 宣言バージョンとインストール済みバージョンが一致している。 古いブランチを新しい node_modules の上にチェックアウトすると、v21 の境目をまたいでしまいます。インストールされている実物に対して移行すると、次の npm ci で目標 API のないバージョンに戻されます。だからサーバーへ は其方に偏らないことを明言します。

3. moduleResolution がエクスポート対応の bundler、 node16、または nodenext である。 @angular/forms/signals は package import のサブパスです。従来の node 解決方式ではそれを見つけることができず、インポートは依存性がないというようなエラーになります。

ツール

詳細なパラメータ、レスポンス の形式、スコープの制限は、docs/TOOLS.md にあります。

レシピの検証方法

Signal Forms は新しく、モデルのトレーニングデータに確実には含まれていません — 記憶から書くレシピは「正しく見える形で間違う」ので、それらはどれもこうは。

レシピは公式の Angular CLI MCP サーバーを使って Angular v22 で検証し、再検証は angular.dev と照合し、構造化された由来情報(verifiedAgainstVersion、 retrievedISO、 sources) を管理し、それをツールのレスポンスに同梱しているので、あなたのエージェントがアドバイスの最新度を判断できます。sources リストが空のレシピは CI が失敗します。

ドキュメントが答えを出していない場合、レシピは答えを捏造せずに caveats(注意書き) にそう書きます — UNVERIFIED — confirm on <url>、または UNVERIFIED、 tool-auth или guidance の形式で。Angularがあまりにも移行パスを文書化していない場合です(RxJS ストリーム層が主な例です。プリミティブはドキュメントされ コンパイルもできますが、その両方を選ぶのはAngularの判断ではなく、このツールの判断です)。現在 37本のうち14本 のレシピにそのマーカーがあります。それは意図した正直な部分であり、見落としではありません。そしてテストがこの数値を正しいまま保っています。

レシピは実際にコンパイルされています CI は実物の @angular/forms@22 をインストールして、レシピが使うすべてのAPIを実行するフィクスチャの型チェックをします。存在しない関数を名前や引数の形（酸形）としてレシピを書くとビルドが落ちます。そこで disabled(path, { when }) が v22 シグニチャであると確立しました。ドキュメントはこのシグニチャも、ネストした schema() + apply() の合成も説明していません。

この過程で記憶が誤っているのを2つ見つけました:

• バイビニングディレクティブは [formField] / FormField であり — [control] / Control ではない。あるいは v21 プレリリース資料に登場して、モデルはこちらの方を再現します。

• disabled() / hidden() は v22 でオプションオブジェクト形式を持て、裸のコールバックを削除するのではなく @deprecated とマークしました。したがって v21 流のほールは警告付きでコンパイルできる。これはドキュメントではなく配布されたオーバーロードの diff から確認した事実です。

バージョンによって振る舞いが変わるレシピには VERSION-SENSITIVE の注意書きがあり、バージョンごとの形を列挙したうえで、サーバーはプロジェクトの検出バージョンに対応して解決します。caveatsと配列を読みましょう — 危ない箇所はそこにあります。

新しいAngularリリースに対する再検証手順は、REVERIFICATION.md にあります。

クリーンな答えがないときはそれを伝えます

すべての Reactive Forms パターンが Signal Forms に相当するとは限りません。逆にそう言う移行ツールはないまま以上に有害である。フォームストリームは .pipe() チェーンに渡る RxJS オペレーターに応じて以下のよう:

hard 層のレシピは、その場そのまま伝えますが、実用的な3つの戦略 — バリバリ非同期バリデーション、rxResource、または RxJS を not Observable プレースするのではなく toObservable / toSignal の後ろに保つ — を提示し、存在しない自動一行変換ね発明しません。

同様に、addControl() / removeControl() には相当するものは一切ありません。フィールドツリーはモデルシグナルの型から派生するためです。実在するこんな API を暗黙にいうことをせず、実際の3つの答えをレシピは説明しています。

しないこと

• ファイルを編集しません。 設計として恒久的に。

• 移行が正しいことを証明しません。 verify_migration の意味は「既知の欠陥がない」の証明です。tsc の後、ではなく必ず tsc の後に動かしてください。

• テンプレート駆動フォームは移行しません。 ngModel の移行は上流でドキュメント化されていません。それを推測するのは、このプロジェクトが回避するために存在する 失敗の形そのものです。

• ${...} を含むテンプレートリテラルを読みません。 は、テキストがそれ Angular コンパイラはスキャン対象ではありません。補間を含まないインラインの template: 文字列はスキャンします。

• CSS/SCSS をスキャンしません。 ファイルをまたいだ型判定もしません — 検出はシングルファイルの構文パスであり、ts.Program ではありません。

以上のは ROADMAP.md で追跡しています。移行レポートでは、count の数字だけが完全性をほのめかさないよう、独自の「Scope」の章でもこれを繰り返します。

なぜ公式 Angular MCP server だけではないのか?

両方使いましょう。公式の @angular/cli MCP サーバーはAngularを知っています。こえは移行を知っています — コード内にどのような構造があるか、どれが機械的で、どれに決定が必要か、検証済みの置換はどのようなものか。あなたのエージェントはここで検出結果とレシピを持ち帰り、編集前に該当の情報またはプロジェクト固有のものをそこで確認することができます。

ステータス

M16 まで機能完全。6つのツールが提供されています。ドキュメントに検証されたレシピは、基本コンストラクション、配列、実行時の形状変化、非同期カスタム、カスタムコントロール、RxJS ストリームの3階層、フォーム状態の読み書き、送信、モデル形状の制約、CSSclass、テストファイル移行、.html テンプレート層（＝バインド、状態読み取り、<select multiple> というブロッカー、警告のないエラキー リネーム）までをカバー。

トランスポートは stdio なので、stdout はプロトコル用に予約、ログはすべて stderr に出ます。

コントリビュートや環境開発: CONTRIBUTING.md。

ライセンス

MIT