MCP サーバーの開発：エージェント型 AI を API の「カスタマーゼロ」に

Red Hat Trusted Profile Analyzer (TPA) と Trustify のエンジニアリングチームは、モデルコンテキストプロトコル (MCP) の実験を実施することにしました。この記事では、同様のことを試みる方々の役に立つことを願い、Red Hat がその取り組み中に直面した課題について紹介します。

参考までに、Red Hat Trusted Profile Analyzer (TPA) はソフトウェア部品表 (SBOM) 管理のための Red Hat 製品であり、SBOM を保存し、SBOM 内のパッケージと既知の脆弱性を関連付けます。これはアップストリーム・プロジェクトの Trustify をベースとしています。

全体的な視点で言うと、このアーキテクチャはかなり「従来型」のものです。

• フロントエンドは React および PatternFly コンポーネント (trustify-ui) を使用して開発されています。
• バックエンドは Rust で開発されており、データベース・インスタンスに接続して、S3 互換ストレージに SBOM を保存します。

実施したステップは以下のとおりです。

1. MCP サーバーと TPA/Trustify の統合の設計
2. MCP サーバーのツールに関する説明の定義
3. MCP サーバーのツールのパラメーター設計

ここでは、各フェーズでの検討事項について説明します。また、最終的な結果として、MCP サーバーを GitHub 上に公開しています。 

MCP サーバーと TPA/Trustify の統合の設計

MCP サーバーと Trustify の統合をどのように定義したかについて説明する前に、この取り組みではソフトウェアエンジニアに特有のジレンマに直面した点に言及します。それは、このプロジェクトではどのライブラリを導入するべきか、ゼロから始めてすべてを自力で開発するべきか、というものです。

オープンソースの信奉者として、私たちは MCP サーバーの実装に使用する Rust ライブラリの現状を確認しました。Trustify は主に Rust で開発されているため、私たちが優先する選択肢は Rust ライブラリでした。

この調査にはそれほど時間がかかりませんでした。MCP には GitHub Organization でいくつかの公式ライブラリが提供されており、その中に Rust を使用して開発されたライブラリがあることが判明したからです。

このライブラリには、MCP サーバーの開発をサポートするために必要なコードが含まれているだけでなく、開始するのに役立つサンプルのセットも用意されています。

ほどなくして、MCP サーバーの実行と利用可能なツールおよびそのパラメーターの定義に必要なライブラリ固有の詳細に加えて、MCP サーバーが「バックエンド」データにアクセスする方法を決定しなければならないことがわかりました。

そこで、2 つの異なる選択肢を評価しました。MCP サーバーは次のいずれかの方法でデータを取得できます。

• Trustify のバックエンドがデータを保存しているデータベース (DB) に直接接続する
• Trustify バックエンドによって提供される REST エンドポイントを呼び出す

ご想像のとおり、どちらにもメリットとデメリットがあるため、活発な議論が起こりました。その内容をここにまとめます。

DB に直接接続するメリット：

1. データへの高パフォーマンスでのアクセス
2. Text-to-SQL アプローチの採用が可能

デメリット：

1. MCP サーバーはバックエンドと同じアーキテクチャレベルになければならない
2. バックエンドのコードと比べて、データアクセスを管理するためにコードの重複が必要
3. MCP ツールの呼び出しの出力を定義するにはデータ形式の管理が必要

REST エンドポイントの呼び出しのメリット：

1. 呼び出しは、バックエンド API ですでに適用されている認証と認可に準拠する
2. MCP サーバーから取得できるデータは、UI で利用できるものと完全に一貫している (同じデータソースを使用しているため)
3. バックエンド API から返された出力を送信するだけで JSON 出力を無料で利用できる

デメリット：

1. より多くのアーキテクチャ層を経由する必要があるためパフォーマンスが低下する

最終的には、MCP サーバーのツールから REST エンドポイントを呼び出すことにしました。これは、MCP サーバーをバックエンドと同じ場所に配置して DB に「十分に近づける」必要があるという直接接続の欠点が、とくに開発者のホスト上で stdio トランスポートをローカルで実行する MCP サーバーでは潜在的な障害となる可能性があったためです。

この開発初期段階におけるもう 1 つのメリットは、すべてのデータが「無料」で JSON レスポンスにフォーマットされるということでした。

MCP サーバーのツールに関する説明の定義

MCP サーバーのツールでバックエンド API を呼び出すと決めた後、それぞれのツールをどのように記述するかを決める必要がありました。最初のイテレーションでは、各 MCP ツールが単一のバックエンド API エンドポイントを呼び出すようにしたいと考えました。

Trustify では利用できるエンドポイントが OpenAPI の openapi.yaml ファイルを使用して文書化されていることを踏まえ、OpenAPI エンドポイントの説明と定義を MCP ツールの説明として使用することにしました。これにより、エンドポイントのドキュメントがユーザーにとってどの程度優れたものであるかを評価できます。これらの作業によって、エージェント型 AI が実質的に私たち独自の API の「カスタマーゼロ」となりました。

これらはすべて、継続的改善のアプローチによって行われました。Trustify の API の説明が LLM での管理において適切であれば、ユーザーもそのドキュメントを理解できるはずです。

このアプローチを実践することで各エンドポイントの改善に役立ち、次の設計の決定につながりました。

MCP サーバーのツールのパラメーター設計

この時点で、ツール呼び出しのための入力パラメーターに関連する問題に直面し、これを理解するためには一歩戻る必要がありました。エンティティのリストを取得するための Trustify のエンドポイントは、q クエリパラメーターを受け入れます。このパラメーターを使用すると、OpenAPI 仕様で定義されている文法に基づいてクエリを指定できます。 

以下の選択肢を検討しました。

1. エンドポイントの q パスパラメーターを MCP ツールの入力パラメーターとして直接公開する
2. q パラメーターのクエリ値の構築に使用できる内部フィールドを MCP ツールの入力パラメーターとして公開する

今回はこれら両方のアプローチを試しました。

1 つ目のアプローチではクエリパラメーターの強力で詳細な記述が必要ですが、現時点では OpenAPI 仕様では提供されていません。クエリ可能なフィールドの包括的なリストは、任意ではなくドキュメントの必須要素であるべきだと考えています。すべてのユーザーがこの情報にアクセスできると有益です。

2 つ目のアプローチでは、AI エージェントのプロセスが単純化されます。脆弱性の重大度、公開日、説明など、クエリするパラメーターを明示的にリストすることで、LLM が情報をより使用しやすくなります。これにより、最初にクエリの文法を LLM に解釈させる必要がなくなります。これは 1 つ目のアプローチでは複雑なステップとなる可能性があります。

さらに考慮すべき点は、MCP ツール上で利用可能なすべてのパラメーターを明示的にリストするには、実際のバックエンド・エンドポイントの実装との一貫性を維持するために継続的な作業が必要になることです。一方で、利用可能なパラメーターのサブセットのみを公開すると、ツールの汎用性が低下し、メンテナンスのオーバーヘッドが削減される保証もありません。

私たちは MCP ツールには q クエリパラメーターを使用することに決め、今後は、すべてのユーザーがメリットを享受できるように OpenAPI 定義内での説明を改善していきます。

結論

MCP サーバーの設計にあたり、次のアプローチを採用しました。

• MCP サーバーで既存の API を活用する
• MCP サーバーで既存の OpenAPI ドキュメントを活用する
• MCP サーバーツールで、リモート API エンドポイントが想定するものと同じパラメーターを公開する

前述のとおり、最終的な結果は GitHub で確認できます。