mcpField
A
automatised-pipeline

automatised-pipeline

ローカル
ai-architect.tools開発ツール7今日更新

automatised-pipeline について

リポジトリを解析してプロパティグラフに変換し、コード構造に関する質問に答えるローカル MCP サーバーです。エージェントや開発者向けに、シンボル検索、依存関係・影響分析とカバレッジの限界情報を提供します。

主な機能

  1. 01Tree-sitter によるリポジトリ解析
  2. 02ローカルのプロパティグラフ保存
  3. 03シンボルと関係の検索
  4. 04依存関係と変更影響の分析
  5. 05実行フローの追跡
  6. 06カバレッジと分析限界の表示

活用シーン

  1. 01シンボルの呼び出し元や依存先を特定
  2. 02Git 差分の影響を受けるコードを把握
  3. 03宣言されたエントリーポイントから経路を探索
  4. 04グラフの検索漏れがカバレッジ不足か確認

MCP 対応

コードのインデックス作成、検索、グラフ照会、影響分析、検証のツールを MCP クライアントに公開します。ツールプロファイルでは、8 個のコアツールか全ツールを選べます。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

インストール方法は未掲載です

このサーバーのパッケージやリモートエンドポイントはまだ取得できていません。プロジェクトの README の手順に従ってください。

リポジトリ
パッケージ
mcpbautomatised-pipeline.mcpb0.8.4

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

ai-architect-mcp-codebase、コードグラフ MCP サーバー

MIT ライセンス Rust 1.95.0、rust-toolchain.toml で固定 27 個の MCP ツール 3200 件以上のテストに合格 行カバレッジ 93% OpenSSF ベストプラクティス 11 言語

リポジトリをローカルのコードグラフにインデックス化し、構造に関する質問に回答する MCP サーバーです。このコードを呼び出しているのは誰か、何が依存しているか、差分がどこに影響するか、実行がどのように関数に到達するかを調べられます。

概要 · インストール · 最初のセッション · ツール · 制限 · 開発


概要

ai-architect-mcp-codebase は tree-sitter でリポジトリを解析し、シンボルとその関係(定義、呼び出し、インポート、実装、使用)を、マシン上の組み込み LadybugDB グラフデータベースに保存して、そのグラフを MCP ツール経由でエージェントに公開します。エージェントはグラフを検索し、呼び出し元と呼び出し先を含むシンボルを調べ、シンボルの逆依存関係を一覧表示し、エントリーポイントから実行フローをたどり、git の差分を変更対象のシンボルに対応付け、同じコードの 2 つのグラフを比較できます。シンボルに関する回答には、ソース位置と分析上の制限が示されます。

このサーバーは、インデックス化したファイルを編集しません。グラフとサイドカーファイルは、指定した output_dir の下に書き込みます。また、チームで共有するアーティファクトを要求した場合に限り、リポジトリ内にスナップショットを保存します。インデックス作成とクエリはネットワーク接続なしでローカルに実行され、コードを読み取る言語モデルはなく、データがアップロードされることもありません。グラフは、ユーザー自身が所有するディレクトリに保存されます。

グラフはソーステキストの静的解析から作成されるため、対象外となるものもあります。リフレクション、動的ディスパッチ、生成コード、パーサーが展開しないマクロを介した呼び出しは、オプションの言語サーバーパス(lsp: true)または実行時トレース(ingest_traces)で補われない限り、エッジが作成されません。レシーバーを介したメソッド呼び出しが静的に解決されるのは、以下に記載されたレシーバーの形状に限られ、それ以外は言語サーバーパスが必要です。Ruby では、インポートや可視性を含まない浅い抽出が行われます。プロセスフローは、宣言されたエントリーポイントからグラフをたどって到達できる範囲で、深さは 20 に制限されており、実際の実行を観測するものではありません。回答が空でも、「そのような関係がない」場合と「インデックス化されていない」場合があります。カバレッジレポートは、この違いを見分けるためのものです。

インストールと登録

Claude Code プラグイン
claude plugin marketplace add cdeust/ai-architect-mcp-codebase
claude plugin install ai-architect-mcp-codebase@ai-architect-mcp-codebase-marketplace

プラグインはリリースバイナリをダウンロードし、実行前に Sigstore の来歴を検証します。この処理には GitHub CLI 2.68 以降が必要です。AP_PROFILE=core が設定されていない場合、プラグインは full プロファイルを起動します。

その他の MCP ホスト
cargo install ai-architect-mcp-codebase
ai-architect-mcp-codebase install          # writes the MCP entry for each detected host

install は Claude Code、Codex CLI、Gemini CLI、Cursor、VS Code、Zed を検出し、各設定ファイルに自身のエントリーのみを追加します。また、解析できないファイルを上書きすることはありません。--dry-run で変更内容をプレビューでき、uninstall で削除できます。ホストを手動で設定するには、バイナリを stdio サーバーとして登録します。

{
  "mcpServers": {
    "ai-architect": {
      "command": "ai-architect-mcp-codebase",
      "args": ["--profile", "core"]
    }
  }
}

docs/install.md には、ホストごとの設定例(Codex、Gemini、Cursor、Windsurf、VS Code、OpenAI Agents SDK)、オプションの Grep/Glob フック、プラグインのリリース検証、プラグイン内でローカルビルドを実行するための開発者向けエスケープハッチが記載されています。

ソースからビルドする
git clone https://github.com/cdeust/ai-architect-mcp-codebase.git
cd ai-architect-mcp-codebase
cargo build --release     # about five minutes the first time (LadybugDB's C++ core)

Rust 1.95.0 は rust-toolchain.toml で固定されており、CMake が必要です。

ツールプロファイル

サーバーは、起動時に --profile または AP_PROFILE 環境変数(フラグが優先されます)で選択する 2 種類のツールセットのいずれかを登録します。

プロファイルツール用途
core8: health_check、analyze_codebase、search_codebase、get_context、get_symbol、get_impact、query_graph、detect_changesエージェントに推奨されます。まず一度分析し、その後検索、調査、影響の測定を行います。
full全 27 種類手動でのグラフ処理、履歴、ランタイムトレース、検証ツール、アーティファクトビルダー、検出結果記録ツールが追加されます。
ai-architect-mcp-codebase --profile core   # the 8 core tools
AP_PROFILE=core ai-architect-mcp-codebase  # same, through the environment
ai-architect-mcp-codebase                  # default: full (all 27)

デフォルトは次のメジャーバージョンまで full のままです。デフォルトのツール構成を縮小することは、破壊的変更となるためです。新しいエージェント環境では core プロファイル(読み取り専用ツール 8 種類)を使用してください。analyze_codebase は 1 回の呼び出しでインデックス作成、解決、クラスタリングを実行し、非表示の 19 種類のツールを除外することで、ツールのプロンプトを小さく保てます。

最初のセッション

health_check()
  → server name and version, protocol version, registered tool count

analyze_codebase(path: "/path/to/repo", output_dir: "/tmp/repo-graph")
  → index, resolve, cluster and build the search index in one call
  → node and edge counts, communities, processes, and the coverage report

search_codebase(graph_path: "/tmp/repo-graph/graph", query: "tool request dispatch")
  → ranked symbols (BM25 and sparse TF-IDF fused with RRF), paged with next_offset

get_context(graph_path, qualified_name: "src/main.rs::handle_tool_call")
  → the symbol with its callers, callees, imports, implementations,
    community and processes; suggestions when the name does not match exactly

get_impact(graph_path, qualified_name: "src/main.rs::handle_tool_call")
  → callers, importers, users and implementors, the communities and processes
    affected, and an epistemic label (exact or lower-bound) with its reasons

detect_changes(graph_path, codebase_path: "/path/to/repo", base_ref: "main", head_ref: "HEAD")
  → symbols the diff adds, modifies or deletes, with a heuristic risk score each

query_graph(graph_path, graph: "missed")
  → the files the index could not fully cover, to check with grep

編集後は analyze_codebase を再実行してください。デフォルトではインデックスが増分更新されます。

27 個の MCP ツール

各ツールは JSON Schema に照らして検証される JSON 引数を受け取り、エラー時には名前付き理由コードを含む構造化 JSON を返します。どのツールも言語モデルを呼び出しません。エージェントのインストールで 27 種類すべてが必要になることはほとんどありません。core プロファイルでは、コードインテリジェンスツール 8 種類のみが登録されます。

Server:                  health_check
Index and resolve:       analyze_codebase · index_codebase · resolve_graph · lsp_resolve · cluster_graph · ingest_traces
Coverage:                index_status
Search and context:      search_codebase · get_symbol · get_context · query_graph
Impact and processes:    get_impact · get_processes · detect_changes
History:                 index_history
Verification:            check_security_gates · verify_semantic_diff · validate_prd_against_graph · check_doc_claims
Artifact export:         prepare_prd_input
Finding records:         extract_finding · refine_finding · start_verification · append_clarification · finalize_verification · abort_verification
ツールコア内容
health_checkはいサーバー名とバージョン、MCP プロトコルのバージョン、登録済みツール数を返します。登録済みツール数からアクティブなプロファイルが分かります。
analyze_codebaseはいインデックス作成、解決、クラスタリングを1回の呼び出しで実行し、検索インデックスを構築します。lsp: true を指定すると、言語サーバーによる処理が追加されます。統計情報とカバレッジレポートを返します。
index_codebaseリポジトリを走査して解析し、<output_dir>/graph/ に保存します。デフォルトでは差分更新されます。チーム共有グラフアーティファクトのエクスポートまたはインポートも可能です。
resolve_graph信頼度スコア付きで、ファイル間の Imports、Calls、Implements、Extends、Uses エッジを追加します。
lsp_resolverust-analyzer、pyright、typescript-language-server を通じて、未解決の呼び出しを解決します。
cluster_graphコミュニティ(C2 修復を伴う Louvain 法)を検出し、エントリーポイントからプロセスを追跡します。
ingest_traces実行時の呼び出し元から呼び出し先への観測(OTel スパン、プロファイラー、カバレッジトレース)をグラフに取り込み、静的解析で解決できなかった箇所に OBSERVED_CALLS エッジを追加します。
index_statusノード数とエッジ数、およびカバレッジレポートを返します。
search_codebaseはいシンボルを対象とするハイブリッドランキング検索と、ドキュメントファイルを対象とする BM25 検索を行います。
get_symbolはい修飾名で完全一致検索し、すべての入力エッジと出力エッジを返します。sibling_graphs は他のリポジトリのグラフから定義を検索します。
get_contextはい1つのシンボルについて、種類別にグループ化した関連情報、所属するコミュニティ、関連するプロセスを返します。
query_graphはい読み取り専用の Cypher クエリをページ単位で返します。graph: "missed" を指定すると、インデックスに含まれなかった項目を一覧表示します。
get_impactはいシンボルまたはファイルの逆依存関係を、影響を受けるコミュニティやプロセス、認識上のラベルとともに返します。
get_processesエントリーポイント、エントリーの種類(main、test、proof、handler、lib_entry)、深さ、サイズを含む実行フローを一覧表示します。
detect_changesはい統合差分、または base_ref..head_ref を、変更が及ぶシンボル、コミュニティ、プロセスに対応付けます。
index_historyGit の履歴を Commit ノードと Version ノードとして追加し、各コミットで変更されたファイルやシンボルに関連付けます。
check_security_gates変更されたシンボルのリストを確認し、認証コミュニティへの影響、公開 API の変更、未解決のインポート、テストカバレッジの不足を検出します。
verify_semantic_diff変更前と変更後のグラフを比較し、追加・削除されたノードとエッジ、参照切れ、新たな未解決インポート、新たな循環(Tarjan SCC)、ヒューリスティックによる回帰スコアを提示します。
validate_prd_against_graphプロダクト要件定義書をグラフと照合し、記載されているが存在しないシンボル、複数のコミュニティにまたがる変更、プロセスへの所属と矛盾する「Xに影響しない」という主張を検出します。
check_doc_claimsドキュメントに記載されたコードに関する主張を、file:line の正確なテキストに根拠付けて1件ずつ確認します。存在するシンボル、ファイル、モジュール、pub として宣言された項目、テストと証明の件数、列挙型のバリアント数を確認します。各行は、証拠として再実行可能なクエリを添えて、裏付けあり、矛盾あり、見つからない、検証不可(理由を提示)、またはアンカー不正のため却下のいずれかに分類されます。項目が存在しない場合や、グラフ上で下限としてしか得られない件数を、矛盾ありとは判定しません。
prepare_prd_input指摘事項または自由記述の機能説明をもとに、一致したシンボル、影響を受けるコミュニティとプロセス、グラフ統計などのグラフ情報をまとめた JSON バンドルを書き出します。
extract_finding、refine_finding受け取った指摘事項を標準的な JSON レコードに正規化し、エージェントによるその指摘事項の修正内容を保存します。
start_verification、append_clarification、finalize_verification、abort_verification指摘事項に関する質疑応答形式の確認を記録し、やり取りの SHA-256 ダイジェストを付けて確定します。
validate_prd_against_graph、prepare_prd_input、および検出結果記録ツールは、呼び出しで指定された output_dir の下に、JSON アーティファクトを生成または検証します。ai-architect-mcp-spec のような仕様ツールやその他のコンシューマーがこれらを読み取れます。サーバー自体はコンシューマーに依存しません。

検証結果の意味は限定的です。check_security_gates は、チェックで重大なフラグが立たなかった場合に gates_passed: true を返します。また、report.assessment_complete は別途報告されます。シンボルリストが空の場合、チェックがスキップされた場合、または変更されたシンボルを解決できなかった場合は、後者は false になります。Rust パーサーが unsafe を記録するまでは、危険なシンボルのチェックはスキップされます。どちらのフィールドもセキュリティを保証するものではありません。verify_semantic_diff の clean 判定には、回帰スコアがしきい値を下回り、新しい未解決のインポートがないことが必要です。これは、動作上の同等性やコンパイルについて何も保証しません。それらを確認するのは、テスト、コンパイラー、または証明です。確定した確認ダイジェストは、記録されたトランスクリプトのバイト列を結び付けるものであり、検出結果が真実であることを立証するものではありません。

回答で示される限界

読み取りツールは、発見した内容と併せて、確認できなかった内容も報告します。CHANGELOG の 0.12.0 の項目には、以下のカバレッジ、影響、言語サーバー、レシーバー解決、新鮮さに関する詳細があります。

カバレッジレポート

analyze_codebase、index_status、および query_graph(graph: "missed") は、parse_incomplete、skipped、または quarantined だったファイルに加え、0.12.0 で追加された Rust の 3 つの分類を報告します。outside_build_targets は、cargo metadata --no-deps に基づき、コンパイル対象の Cargo ターゲットのいずれにも含まれない、インデックス済みの .rs ファイルを列挙します(Kani の証明ファイルや、除外された fuzz/ ディレクトリなど)。feature_gated は、デフォルト機能では #[cfg(feature = ...)] が false である mod 宣言を経由してのみ到達するモジュールを列挙します。unlinked_file は、rust-analyzer 自身がどのクレートにも属さないと報告したファイルを列挙します。これは、LSP パスでファイルを開いた際に記録されます。cargo_attribution.status は、Cargo から導出される 2 つの分類が判定されたかどうかを示します。値は known、unknown(cargo metadata の呼び出しが失敗したか、cargo が存在しないため、空の分類は「未判定」を意味します)、not_applicable、または古い記録に対する not_recorded です。coverage.pruned_dirs は、ポリシーにより走査をスキップしたすべてのディレクトリと、その理由を示します。カバレッジレポートが空でも、完全性の証明にはなりません。

影響に関する認識上の境界

get_impact は、カバレッジ記録のすべての分類にギャップがなく、cargo_attribution.status が unknown ではなく、対象を指す未解決の呼び出し箇所もない場合に限り、回答を exact とします。それ以外の場合、回答は理由とともに lower-bound になります。unresolved_callsites_naming_target は、呼び出し先の名前が対象と一致する未解決の呼び出し箇所の数を示します。unresolved_callsites_outside_targets は、コンパイル対象の Cargo ターゲット外にあるそのような箇所の数を示すため、呼び出し元リストが空の場合と、呼び出し元が存在しないシンボルとを区別できます。

言語サーバーパス

lsp: true の場合、analyze_codebase は lsp_status.state を disabled、completed、completed_unresolved(解決が必要な箇所があったものの、どれも解決されなかった場合)、または failed として報告します。Cargo ワークスペース内にネストされているものの、メンバーとして登録されていない Rust クレートでは、解決要求を送信する前に、Cargo レベルでの修正方法を示す lsp_workspace_load_failed とともにパスが失敗します。パスが失敗した場合も、利用可能なグラフを使って解析を続行します。server_health には、言語サーバー自身が最後に報告したヘルス状態が含まれます。

静的なレシーバー呼び出しの解決

0.12.0 以降、静的リゾルバーは、Rust の self.m() と Self::m()、Python の self.m()、TypeScript の this.m() を、囲んでいる型のメソッドに 結び付けます(resolution_method: "receiver-type")。Rust ではさらに、 囲んでいる関数内で、型付きパラメーター、型付きの let、または let x = T::assoc(..) によって x が一度だけ束縛されている場合、 x.m() も結び付けます("receiver-local-binding")。また、初期化に使われた 同じファイル内の自由関数の宣言済み戻り値の型からも x の型を推定します (let x = make();、および let Some(x) = .. else、.expect(..)、 .unwrap()、? によってアンラップされる Option または Result)。 信頼度は低めです("receiver-return-type"、0.85)。型を推定できない レシーバーは未解決のままになり、名前だけを使った検索にはフォールバックしません。

クエリの切り詰めとページング

query_graph は、クエリに LIMIT がない場合、1 ページあたり最大 500 行に制限します (limit_injected: true)。ページの後にさらに行がある場合、truncated は true になり、 next_offset で次のページを取得できます。行数の上限によって結果が切り詰められた場合、 total_count は下限値になります。ページングの安定性は、クエリに ORDER BY が 指定されている場合に限られ、その状態は order_stable で報告されます。このツールの JSON Schema の説明に、契約の詳細が記載されています。

最新性のレシート

search_codebase、get_symbol、get_impact は、エラーを含むすべての応答で graph_freshness(state: fresh | stale | unknown、dirty_files、 checked_files、commits_behind、commits_ahead)を返すため、作業ツリーより古い グラフに基づく回答には、その旨が示されます。0.11.x でインデックス化されたグラフは、 再インデックス化されるまで unknown と表示されます。

言語

Rust、Python、TypeScript(TSX 文法による JavaScript を含む)、Java、Kotlin、 Swift、Objective-C、C、C++、Go は、言語ごとの仕様によって詳細な抽出が行われます。 対象には定義、呼び出し、インポートに加え、仕様に記録されている場合は可視性と型の 関係も含まれます。Ruby は簡易階層です (ADR-0056)。関数、メソッド、 クラス、モジュール、および呼び出しが対象となり、可視性とインポートのエッジは ありません(require は呼び出しとして扱われます)。その他のファイルは、ドキュメントや 設定ファイルも含め、File ノードとしてインデックス化されます。ドキュメント ファイル(md、markdown、mdx、txt、rst、adoc、最大 256 KiB)のテキストは、 BM25 で検索できます。言語サーバーによる処理は Rust、Python、TypeScript に対応しています。

セキュリティモデル

サーバーは、2 つのレイヤーによって query_graph からグラフへの読み取り専用アクセスを 強制します。エンジンのコンパイル済みプランのチェックではデータベースへの書き込みを 拒否し、字句ゲートでは、エンジンが読み取り専用に分類するファイルシステム文 (COPY … TO、EXPORT DATABASE、ATTACH など)に加え、2 つのプロシージャの 許可リスト外にあるすべての CALL を拒否します。Git の参照は検証され、言語サーバーの コマンドは既知の 4 つのバイナリに制限されます。また、走査にはサイズと深さの上限があり、 解析にはファイルごとの制限時間があります。リリースバイナリには Sigstore の来歴情報が 付与され、Claude Code プラグインは実行前にこれを検証します。

docs/security.mdには、すべての制限と、query_graph に2つのレイヤーが 必要な理由の分析が記載されています。また、docs/ASSURANCE-CASE.md にはセキュリティ上の論拠が記載されています。脆弱性はSECURITY.mdから 報告してください。

グリーンソフトウェアエンジニアリング

LLM を活用したコーディングワークフローで最も大きなエネルギーコストは、構造クエリなら一度で答えられる質問に答えるために、ファイルを読み直す際のモデル推論です。このバイナリの CPU 使用量は、それに比べればわずかです。エージェントが処理しないトークンはすべて、実行されることのない計算です。 Green Software Foundation はこれをエネルギー比例性と呼んでおり、ここでは定数が最も大きい部分に適用しています。

事前登録したプロトコルに基づく直接比較評価では、API キーなしでオフライン再現可能な条件で、n=20 の需要を測定しています。

需要項目グラフツールGrep/Glob/Read のベースライン削減率
ペイロードトークンの代理指標43.14 ± 17.26550.36 ± 330.2814.26x(質問ごとの比率の平均)
モデル化したツール呼び出し回数1.00 ± 0.005.20 ± 1.645.20x

コストはモデル化した値です。どちらの比較でも、ペイロードサイズを 4 で割ったトークンの代理指標を使用しており、インデックス作成、クライアントのプロンプト、実際の MCP レスポンスエンベロープ、モデルの推論は除外しています。このコーパスは修正 #87 と #92 の参考になったため、これはリグレッションベンチマークです。ペイロード総量を割ると 12.76x となり、別の統計値になります。このリポジトリではジュールを測定しておらず、トークン数をワット時に換算できないため、これらの数値からエネルギー量や CO2 排出量は算出していません。 docs/evaluation.md に、完全な表、プロトコル、誤りと判明した初回実行を記載しています。

サーバー側では、型付き構造体を使った UNWIND によるグラフの一括書き込みは、エッジあたり 0.127 ms です。単純な生文字列の経路では 9.658 ms であり、同じ出力に対する処理量は 76 分の 1 です(2026-07-28 に lbug 0.18 と tests/lbug_bulk_investigation.rs を使って測定)。Tree-sitter はモデルを使わずに構造を抽出し、インデックス作成はデフォルトでインクリメンタルです。サーバー側の測定値と日付は docs/evaluation.md に記載しています。

ゼテティックな基準

zetetic-team-subagents から受け継いでいます。

柱問い
論理的一貫していますか?
批判的真実ですか?
合理的役に立ちますか?
本質的必要ですか?

このコードベースでは、次のように適用しています。

  1. すべてのアルゴリズムは出典をたどれるようにしています。Louvain:Blondel et al. 2008。Leiden の C2 修復:Traag et al. 2019。RRF:Cormack、Clarke、Büttcher 2009。強連結成分:Tarjan 1972。BM25(Tantivy 経由):Robertson et al. 1994。
  2. 名前付き定数には出典または測定に基づく根拠を記録します。src/search/rrf.rs の RRF 定数 K = 60.0 は Cormack 2009 を出典として記載しています。BULK_BATCH_SIZE = 500 は LadybugDB の実践者向けガイダンスと 2026 年 4 月のスケーラビリティ監査を出典として記載しています。CONTRIBUTING.md では、有効数字が 3 桁以上の数値定数すべてに // source: アノテーションを付けることを求めています。裏付けとなる測定のない効率性の主張は採用されません。
  3. 数値を捏造しません。判断で値を選んだ場合は、コメントでその旨と運用上の根拠を示します。
  4. エラーレスポンスでは、違反したルールを明示します。たとえば、unsafe finding_id (spec §5.1.4, §9.3 Q4): must not contain '..' です。
  5. 機能を利用できない場合、ツールは平易な言葉でその旨を伝えます。たとえば、言語サーバーではないバイナリ上での lsp_resolve は、lsp_probe_failed: found on PATH but didn't respond as an LSP server (stdout closed immediately; likely a stub, proxy, or non-LSP binary) を返します。

開発

cargo build --release
cargo test                                            # full suite (3200+ tests)
cargo test --test graph_accuracy                      # structural accuracy gate
cargo clippy --all-targets -- -D warnings             # zero warnings, enforced in CI
python3 scripts/check_doc_claims.py                   # README numbers against their sources

CI では cargo llvm-cov を使って行カバレッジ(80% の下限)も測定し、その実行結果に基づいて上記のカバレッジバッジとテスト件数バッジを確認します。コントリビューションには DCO サインオフ(git commit -s)が必要です。CONTRIBUTING.md にはレイヤーのルールとコーディング標準を、docs/architecture.md にはモジュール構成、依存関係、設計記録を記載しています。評価プログラムについては docs/evaluation.md で説明しています。

リポジトリの構成

ai-architect-mcp-codebase/
├── src/
│   ├── main.rs                    ← MCP server entry point and dispatch
│   ├── tool_schemas.rs            ← JSON Schemas, one file per tool group
│   ├── tool_profile.rs            ← core and full profiles
│   ├── graph_store/               ← LadybugDB port
│   ├── parser/                    ← tree-sitter extraction, one spec per language
│   ├── indexer/                   ← walk, parse, persist, coverage
│   ├── resolver/                  ← cross-file resolution
│   ├── lsp_client/ · lsp_resolver/
│   ├── clustering/                ← communities, processes, impact
│   ├── search/                    ← BM25, sparse TF-IDF, RRF
│   ├── history/                   ← git history layer
│   ├── prd_input/ · prd_validator/ · security_gates/
│   └── semantic_diff.rs · git_diff.rs
├── tests/                         ← integration tests and graph_accuracy.rs
├── benchmarks/                    ← eval_headtohead, token_surface, incremental_speed
├── stages/                        ← design specs and decision records
├── docs/                          ← install, configuration, security, architecture, evaluation
├── scripts/                       ← doc-claim and pin gates
├── bin/                           ← plugin launcher and release verification
├── skills/                        ← host-native workflows
├── plugins/                       ← Codex plugin package
├── mcp-contract.json
└── Cargo.toml

ステータス

バージョン 0.14.0 です。上記の機能はテストスイートと CI の精度ゲートでカバーされており、メンテナーのマシンでエンドツーエンドの動作確認が完了しています。ただし、まだ本番環境へのデプロイで検証されていません。unsafe シンボルのセキュリティチェックは、Rust パーサーでの unsafe 抽出に依存しています。サーバーはコードを編集しないため、名前変更ツールとリファクタリングツールは対象外です。今後の方向性はdocs/ROADMAP.mdに、リリース済みの内容はCHANGELOG.mdに記載されています。

関連プロジェクト

これらはそれぞれ単独で動作します。Cortexは永続メモリを備えた MCP サーバーで、ai-architect-mcp-specは PRD の生成と仕様の検証を行う MCP サーバーです。このサーバーと ai-architect-mcp-spec の両方を登録したエージェントは、search_codebase、get_context、get_impact、または prepare_prd_input が書き出す JSON ファイルを通じて、グラフに基づいた仕様を作成し、validate_prd_against_graphでその結果を検証できます。

ライセンス

MIT ライセンスです。詳しくはLICENSEをご覧ください。crates.io ではai-architect-mcp-codebaseとして公開され、MCP Registryには以下の名前で登録されています。

mcp-name: io.github.cdeust/ai-architect-mcp-codebase

このソフトウェアは Clément Deust が独自に開発したものです。雇用関係の外で開発されており、過去または現在の雇用主との提携、推薦、所有関係はありません。

ここで使用しているグラフおよび検索アルゴリズム(C2 修復を伴う Louvain コミュニティ検出、BM25、RRF ランク融合、tree-sitter による解析、Tarjan の強連結成分)は、公開された研究に基づいています。引用は // source: 注釈と docs/ に記載されています。MIT ライセンスが適用されるのはこの実装であり、基盤となるアルゴリズムの所有権を主張するものではありません。アルゴリズムの権利は、それぞれの原著者に帰属します。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。