メインコンテンツへスキップ

​
既存の API を MCP サーバーに変換する

多くのチームは OpenAPI 3.0+ で定義された REST API をすでに運用しています。サーバーフレームワークで一から書き直す代わりに、上流 API へリクエストをプロキシしつつ AI アシスタントとは Model Context Protocol (MCP) で通信できる、薄い MCP ラッパーを自動生成できます。 これらのジェネレーターは 既存サービス を対象としており、フレームワーク比較 は 新規にサーバーを構築 するケースにフォーカスしています。
すでに OpenAPI 仕様を持っていて、最小限の工数で MCP 対応したい場合にこれらのツールを使いましょう。

​
利用可能なジェネレーター

​
クイックスタート（stdio の例）

CLI は次の処理を行います:
  1. OpenAPI ドキュメントを解析
  2. @modelcontextprotocol/sdk を用いた型安全な TypeScript プロジェクトを生成
  3. 検証用に Zod スキーマを生成
  4. stdio エントリポイント（オプションで web / streamable-http）を作成
  5. 簡易 HTML クライアントを同梱

​
自動生成サーバーを選ぶべきケース

  • 既存の レガシー REST API をすばやく AI と連携させたい
  • バックエンドチーム が MCP の詳細を学習する時間を取りたくない
  • プロトタイピング で複数マイクロサービスを短時間で公開したい
  • 一貫性 — OpenAPI と MCP の定義を常に同期させたい
生成されたコードはあくまで出発点です。実運用前に認証、ログ、エラーハンドリングなどを強化してください。

​
主な機能

​
制限と注意点

MCP は単なる REST プロキシではありません。 OpenAPI のすべてのエンドポイントを機械的にツール化すると、LLM の性能をむしろ悪化させることがあります。
LLM の専門家（例: David Cramer）は、OpenAPI-as-MCP 的な安易な変換には次の問題があると指摘しています:
  • ツール過多: エンドポイントが数十〜数百あると、類似した名前のツールを LLM が誤選択しがちです。
  • パラメータ過多: REST エンドポイントは任意パラメータが多く、UI コンテキスト無しでモデルが入力値を決定しなければなりません。
  • コンテキスト容量: 一部モデルはツール説明を ~1kB に制限しており、詳細なドキュメントは切り捨てられます。
  • レスポンスの冗長さ: UUID やネストが深い JSON はモデルには解釈しづらい。
  • 抽象度のミスマッチ: 優れた MCP ツールは「#sales へメッセージを送る」など 意図に近い 操作単位で設計されるべきです。
生成コードを 雛形 として活用し、不要なエンドポイントを削除したり、複雑な操作を LLM 向けに高レベルなツールへラップし直すことを推奨します。

​
参考リンク