MCP サーバー層をバックエンドと別リポジトリ・別サービスにするかは、層構造の美しさや過去プロジェクトの前例ではなく、次の2軸で決める。

判断基準

1. 独立したバージョン・配布サイクルを持つ成果物か。MCP 層が npm パッケージ・CLI・プラグインとして単体配布され、プロダクト本体と別のリリースサイクルを持つなら分離が正しい。既存プロダクトへの後付け統合で、MCP が副次インターフェースの場合もこちらに寄る。
2. ツール契約の変更が他層と同時多発するか。MCP がプロダクトの主要（または唯一の）フロントエンドで、機能追加のたびにツールスキーマと BE API が同時に変わる段階（MVP 期など）は同居が正しい。分離すると契約変更のたびに複数リポジトリの PR 往復になり、アトミックな変更ができない。デプロイが常に同時なら分離の運用メリットも消える。

同一開発者の2プロダクトで、同じ基準から逆の結論（配布物を持つ側は分離、MCP が唯一のフロントである側はモノレポ）が出た。基準が文脈依存の結論を出すのは正常で、「前例の構成が正しかったか」ではなく「前例の条件が今回も成立するか」を確認する。

落とし穴

• プラグイン配布の予定は分離の理由にならない。ホスト型 MCP サーバーのプラグインは接続定義とスキル文書だけの薄いポインタで、サーバーコードを含まない。配布時にモノレポ内へ plugin ディレクトリを足し、必要なら薄い公開ミラーへ同期すれば足りる。分離を先回りすると、将来の半日作業を節約するために毎週の契約変更コストを払うことになる（統合方向の再編は分離方向より高くつく点も非対称）。
• リポジトリ統合とロジック配置は別の決定。同居させてもビジネスロジックの正本は BE に一元化し、MCP 層は「スキーマ定義 → BE 呼び出し → 応答整形」だけの薄いプロトコルアダプタに保つ。この規約をリポジトリの AI 向け規約ファイルに明記しないと、同居をきっかけにロジックが MCP 層へ漏れる。

検証

分離を選ぶ前に「直近3か月で、MCP 層だけが単独で変更・リリースされる見込みの変更を3つ挙げられるか」を自問する。挙がらなければ同時変更が支配的であり、同居が正しい。