code-analyze-mcp

[!NOTE] ネイティブエージェントツール（正規表現検索、パス一致、ファイル読み取り）は、対象を絞った検索に適しています。aptu-coder は、ディレクトリ構造のマッピング、シンボルの抽出、コールグラフのトレースといった、機械的で AI を必要としない作業を処理します。この作業を専用ツールにオフロードすることで、トークン使用量を削減し、より高い精度でコーディングを高速化できます。

ベンチマーク

Claude Code 上での Django（Python）ソースツリーに対する認証マイグレーションタスク。完全な方法論

Claude Code 上での OpenFAST（Fortran）ソースツリーに対する AeroDyn 統合監査タスク。完全な方法論

Related MCP server: CodeGraphMCPServer

概要

aptu-coder は、AI エージェントにコードベースの正確な構造的コンテキスト（ディレクトリツリー、シンボル定義、コールグラフ）を、生のファイルを読み取らずに提供する Model Context Protocol サーバーです。18 言語をサポートし（対応言語 を参照）、MCP 互換のオーケストレーターと統合できます。

対応言語

インストール

Homebrew（macOS および Linux）

brew install clouatre-labs/tap/aptu-coder

更新: brew upgrade aptu-coder

cargo-binstall（Rust 不要）

cargo binstall aptu-coder

cargo install（Rust ツールチェーンが必要）

cargo install aptu-coder

クイックスタート

ソースからビルド

cargo build --release

バイナリは target/release/aptu-coder にあります。

MCP クライアントの設定

2 つのトランスポートが利用可能です。デリゲートを生成するオーケストレーター（例: goose coder）を使用する場合は、Streamable HTTP が推奨されます。単一のサーバープロセスがオーケストレーターとすべてのエージェント間で共有され、各 stdio サブプロセスが独自の分離インスタンスを取得する際に発生する拡張機能のドリフトを排除します。

Streamable HTTP（マルチエージェント構成に推奨）

Homebrew を使用すると、1 つのコマンドでログイン時にサーバーが起動し、実行し続けます:

brew services start aptu-coder

Homebrew フォーミュラはデフォルトでポート 49200 でサーバーを起動します。次に、拡張機能を ~/.config/goose/config.yaml に 1 回追加します:

extensions:
  aptu-coder:
    type: streamable_http
    uri: http://127.0.0.1:49200/mcp
    name: aptu-coder
    timeout: 300

または Claude Code の場合:

claude mcp add --transport http aptu-coder http://127.0.0.1:49200/mcp

別のポートを使用するには、再起動前に APTU_CODER_PORT を設定します:

APTU_CODER_PORT=4000 brew services restart aptu-coder

brew services を使用せずに直接起動する場合:

aptu-coder --port 49200
# or equivalently
APTU_CODER_PORT=49200 aptu-coder

stdio（シングルクライアント使用）

サーバーを必要とするプロセスが 1 つだけの場合に適しています。クライアントがプロセスのライフサイクルを所有し、自動的に起動します:

claude mcp add --transport stdio aptu-coder -- aptu-coder

または、プロジェクトルートの .mcp.json に手動で追加します（バージョン管理を通じてチームと共有されます）:

{
  "mcpServers": {
    "aptu-coder": {
      "command": "aptu-coder",
      "args": []
    }
  }
}

ツール

すべてのオプションパラメータは省略可能です。analyze_directory、analyze_file、analyze_symbol の共有オプションパラメータ:

ツールのパラメータ、制約、例は、MCP クライアントのツールインスペクタまたは tools/list レスポンスで確認できます。

MCP リソース

ナレッジグラフ機能は、analyze_symbol 呼び出し中に構築された構造グラフをナビゲートするための MCP リソーステンプレートを公開します。リソースは URI アドレス指定されます。利用可能なテンプレートを確認するには resources/templates/list を使用してください。

ページネーション: 結果はページ分割されます。前回のレスポンスから不透明な cursor 値を渡して次のページを取得します。

深度パラメータ: blast-radius テンプレートは、オプションの depth クエリパラメータ（1〜5 の整数、デフォルト 3）を受け入れます。

コールドキャッシュ: 最初にディレクトリに対して analyze_symbol を呼び出してグラフを構築します。グラフが利用可能になるまで、リソースは情報メッセージを返します。

出力管理

大規模なコードベースの場合、いくつかのメカニズムがコンテキストオーバーフローを防ぎます。

ページネーション

analyze_file と analyze_symbol は、出力が切り詰められたときに NEXT_CURSOR: 行を追加します。トークンを cursor として渡して次のページを取得します。summary=true と cursor は相互に排他的です。両方を渡すとエラーが返ります。

# Response ends with:
NEXT_CURSOR: eyJvZmZzZXQiOjUwfQ==

# Fetch next page:
analyze_symbol path: /my/project symbol: my_function cursor: eyJvZmZzZXQiOjUwfQ==

exec_command の出力上限

exec_command は、大きなコマンド出力がコンテキストを圧迫しないよう、3つの独立したバイトレベルの上限を適用します:

30kのstdout上限はデータ駆動型です: 観測された27,981回の exec_command 呼び出しの分析では、この上限を超えるのはわずか0.33%です。いずれかの上限が発動すると、レスポンスに output_truncated: true が設定され、JSONLメトリクスに記録されます。

drain_timeout_secs は、子プロセスが終了した後、パイプを開いたまま保持しているバックグラウンドのサブプロセスをサーバーが待機する時間を制御します。デフォルトは500msです(0または省略時)。負の値は INVALID_PARAMS を返します。ドレイン期間がパイプが閉じる前に満了すると、output_truncated: true が設定されます。

exec_command 出力フィルター

組み込みのフィルターテーブルは、出力がモデルに到達する前に、冗長なCLIツールからのファイル単位のノイズを抑制します。フィルターは成功時のみstdout、stderr、およびインターリーブされた出力に適用されます。失敗時は常に生の出力が保持されます。

プロジェクトローカルのルールは .aptu/filters.toml に追加できます。パースエラーや認識されない schema_version 値(version != 1)は、警告をログに記録して組み込みテーブルにフォールバックします。クラッシュは発生しません。フィルターが発動すると、structuredContent 内の filter_applied がどのルールが一致したかを識別します。

非対話型パイプライン

シングルパスのサブエージェントセッションでは、プロンプトキャッシュは書き込まれますが再利用されません。ベンチマークでは、MCPレスポンスがネイティブのみのワークフローより約2倍多くキャッシュに書き込み、品質向上なしにコストを追加することが示されました。このオーバーヘッドを回避するには、DISABLE_PROMPT_CACHING=1(Haiku固有のパイプラインでは DISABLE_PROMPT_CACHING_HAIKU=1)を設定します。

サーバー自身の指示は、未知のリポジトリに対する4ステップの推奨ワークフローを公開しています: max_depth=2 で analyze_directory を使用してリポジトリルートを調査し、ソースパッケージに掘り下げ、主要ファイルに対して analyze_module を実行して関数/インポートのインデックスを取得し(シグネチャと型が必要な場合は analyze_file)、その後 analyze_symbol を使用してコールグラフを追跡します。サーバーの指示を表示するMCPクライアントは、このワークフローをエージェントに自動的に提示します。

環境変数

キャッシュとランタイム

可観測性

JSONLスキーマ、OTel設定、スパン属性ポリシーについては、以下を参照してください:

• OBSERVABILITY.md (リポジトリルート)

• docs/METRICS.md

ドキュメント

• AGENTS.md - コントリビューター向けリファレンス: プロジェクト構造、コマンド、rmcpの落とし穴、ツールパラメータの制約

• ARCHITECTURE.md - 設計目標、モジュールマップ、データフロー、言語ハンドラーシステム、キャッシュ戦略

• CONTRIBUTING.md - 開発ワークフロー、コミット規約、PRチェックリスト

• DESIGN-GUIDE.md - 設計上の決定、根拠、高性能MCPサーバー構築のための再現ガイド

• MCP Best Practices - エージェンティックループ、オーケストレーションパターン、MCPツール設計、メモリ管理、安全制御のベストプラクティス

• METRICS.md - メトリクススキーマ、JSONL形式、保持ポリシー

• ROADMAP.md - 開発履歴と今後の方向性

• SECURITY.md - セキュリティポリシーと脆弱性報告

ライセンス

Apache-2.0。詳細は LICENSE を参照してください。