Weavatrix

Weavatrix — ネイティブ MCP リポジトリーインテリジェンス

Weavatrix エコシステムの一部：AI ソフトウェアエージェント向けのエビデンス基盤です。

推測を始める前に、コーディングエージェントにリポジトリーのエビデンスを提供しましょう。

Weavatrix は、エージェントがそれ以外の方法ではでっち上げてしまう質問に答える、ネイティブ MCP 製品です。このファイルを変更すると何が壊れるか、この n8n フィールドを使用しているのは誰か、MCP スキーマが昨日のリクエストを引き続き受け入れるか、ABI レイアウトの変更にどの viem 呼び出し箇所が従うか、そして .weavatrix/architecture.json が依然として有効か、といった質問に答えます。読み取り専用の 67 個の操作、リビジョンに紐づいた単一のグラフ、LSP もプロンプトパックもありません。

Codex、Claude Code、Cursor、Grok では、影響分析、アーキテクチャ、API、Git 履歴、重複、デッドコード、検索、セマンティックリンク、時間的メモリー、エクスポートされた n8n ワークフロー（n8n_*）、Dify YAML アプリ（dify_*）、Agent プラグイン／スキル／MCP カタログ（agent_*）、Mermaid フローチャート（diagram_*）、Web3 ABI／利用箇所への影響（web3_*）を利用できます。これらのパーサーは Weavatrix Core 上のドメインであり、新しい MCP 製品ではありません。専用ページ： n8n · Dify · パーサー。

より大規模な grep や、でっち上げの信頼度スコアをもとに回答することはありません。範囲が限定された各結果には、それを生成したリポジトリーのリビジョン、ファイル、行、抽出器、エビデンスの種類、信頼度を含めることができます。

隣接する MCP ツール（このホストには含まれません）

このリポジトリーはstdio MCP ホストとプラグインパックです。weavatrix-rust を固定して使用します。2 つ目のインデクサーを追加することはなく、エンジンクレートと同じ README の役割を取り合うこともありません。

すでに使用している可能性があるもの	用途	次の場合は代わりにこのホストを使用
Serena	エージェント内での LSP による正確な名前変更、参照、編集	読み取り専用の影響分析、アーキテクチャ、来歴が必要で、エージェントに言語サーバーを起動させたくない
Repomix MCP	圧縮したリポジトリーを次のプロンプトに詰め込む	ターンごとにパックのトークンコストを払わずに、範囲を限定した回答（change_impact、verify_architecture）が必要
Aider RepoMap	1 回のチャットに収まるシンボルをランキングする	n8n／Dify／Agent／Web3／Mermaid ドメインを含む、リビジョンに紐づいた完全なグラフが必要
Claude Context / vector MCP	「これに似たコード」のセマンティック検索	最近傍チャンクではなく、抽出器に裏付けられたエッジが必要
GitNexus / CodeGraph daemons	IDE の隣で長時間稼働するグラフサービス	追加のデータベースプロセスなしで、公開済みのネイティブバイナリを使いたい

このホスト独自の役割はトランスポートです。プロファイル、監視、npm／クレート配布、そして 1 回のエンジンセッションで利用できる 67 ツールのカタログを提供します。計測済みのエンジン実行時間は、ここではなく weavatrix-rust のベンチマークに掲載されています。

エコシステムにおける位置づけ（理解する）

Weavatrix (this) — code facts
        │
        ▼
Weavatrix Loom — semantic composition (capabilities, registry, compile → Rust)
        │
        ▼
Realforge — artifact construction (scaffold / package / deploy)

製品	担当範囲	担当しない範囲
Weavatrix（本製品）	リポジトリ／コードグラフ、シンボル、依存関係、検索、影響分析	機能相互運用の Registry、WVX プロジェクトグラフ
Weavatrix Loom	機能・実装・エビデンス・GraphPatch・セマンティックコンパイラー	リポジトリの詳細なインデックス作成（これは引き続きこちらが担当します）
FerroSift	決定論的な変換レシピ／オペレーション	機能 Registry、コードインテリジェンス
Cortex Loom	エージェントのワークフロー／コンテキスト予算	コードインデックス、Loom の承認ポリシー

Loom はセマンティック分類（例：「この fn は data.json.parse@1 の候補です」）のために、Weavatrix の事実を利用します。Loom が 2 つ目の製品コードインデクサーを作ることはありません。Loom 側の規範については、ADR-0012を参照してください。

同じソースは、次の 2 つの形態で配布されています。

配布形態	インストール	最適な用途
crates.io の weavatrix	cargo install weavatrix	Rust を優先する環境とソースからのビルド
npm の weavatrix	npx -y [email protected] mcp <repo>	Rust ツールチェーンなしで使える、すぐに利用可能なクロスプラットフォームバイナリ

npm パッケージは利便性のために用意されており、別の JavaScript エンジンが含まれているわけではありません。どちらの配布形態でも、同じネイティブアダプターと同じ weavatrix-rust 分析エンジンが実行されます。別途バージョン管理されている weavatrix-js パッケージは、互換性と過去のベースラインのために使われるレガシーな JavaScript 実装であり、weavatrix にはバンドルされていません。

プラグインとしてインストールする

このリポジトリには、Cursor、Codex、Claude Code、Grok Build 向けのプラグインバンドルが 1 つ含まれています。各クライアントは、公開済みのネイティブ npm 配布版を起動し、同じ読み取り専用 MCP ツールを読み込みます。オプションの Weavatrix スキルは、インデックス化されたファイル横断エビデンスが役立つタスクでのみ有効になります。詳細なツールの振り分けは、必要なときに別途読み込まれます。

Cursor プラグイン

マーケットプレイスの審査が完了したら、Cursor の Plugins ビューで Weavatrix を検索してください。掲載前にバンドルをテストするには、plugins/weavatrix を ~/.cursor/plugins/local/weavatrix にコピーまたはリンクし、Cursor のウィンドウを再読み込みします。

Codex プラグイン

codex plugin marketplace add Weavatrix/weavatrix --sparse .agents/plugins plugins/weavatrix
codex plugin add weavatrix@weavatrix

Claude Code プラグイン

claude plugin marketplace add Weavatrix/weavatrix --sparse .claude-plugin plugins
claude plugin install weavatrix@weavatrix

Grok Build プラグイン

grok plugin marketplace add Weavatrix/weavatrix

/marketplace を開いて Weavatrix をインストールしてください。Grok では、プラグインを直接 grok plugin install Weavatrix/weavatrix#plugins/weavatrix でインストールすることもできます。

30 秒でインストール

便利なビルド済み npm 配布版を実行します。

npx -y weavatrix mcp .

または、同じ MCP 製品を Cargo でインストールします。

cargo install weavatrix
weavatrix mcp .

Codex

# ~/.codex/config.toml
[mcp_servers.weavatrix]
command = "npx"
args = ["-y", "weavatrix", "mcp", "."]

Claude Code

claude mcp add weavatrix -- npx -y weavatrix mcp .

Grok

grok mcp add weavatrix -- npx -y weavatrix mcp .

-- の後はすべてサーバーコマンドになるため、-y は Grok ではなく npx に渡されます。同等の手書きエントリは次のとおりです。

# ~/.grok/config.toml
[mcp_servers.weavatrix]
command = "npx"
args = ["-y", "weavatrix", "mcp", "."]
startup_timeout_sec = 120

パッケージの展開サイズは約 40 MB のため、最初の npx の起動では、Grok のデフォルトの起動タイムアウトである 30 秒を超えてダウンロードに時間がかかる場合があります。startup_timeout_sec を設定すれば初回の起動に対応できます。または、npm i -g weavatrix か cargo install weavatrix を実行すると、以降のセッションでコールドスタートが発生しなくなります。

代わりに --scope project を使うと、リポジトリ内の .grok/config.toml に書き込まれるため、リポジトリをクローンすればサーバーも一緒に引き継がれます。

Cursor

Cursor プラグインを使うことをおすすめします（すでに ${workspaceFolder} を渡します）。ユーザーエントリを手書きする場合は、ホストプロセスの cwd ではなく、開いているワークスペースをサーバーに指定し、ユーザー MCP とプラグインを同時に実行しないようにしてください。

// ~/.cursor/mcp.json
{
  "mcpServers": {
    "weavatrix": {
      "command": "npx",
      "args": ["-y", "[email protected]", "mcp", "${workspaceFolder}"]
    }
  }
}

プロファイルでは、同じエンジンの範囲を制限したビューを利用できます。

npx -y [email protected] mcp . --profile=all
npx -y [email protected] mcp . --profile=code
npx -y [email protected] mcp . --profile=seo
npx -y [email protected] mcp . --profile=n8n
npx -y [email protected] mcp . --profile=dify
npx -y [email protected] mcp . --profile=agent
npx -y [email protected] mcp . --profile=diagram
npx -y [email protected] mcp . --profile=web3

npm パッケージには、Windows x64/arm64、macOS x64/arm64、glibc Linux x64/arm64 向けのネイティブバイナリが含まれています。インストールスクリプトはなく、実行時のダウンロードも行いません。

構造化出力を読み取るクライアントでは、すべての回答を半分に

MCP の結果にはペイロードが 2 回含まれています。structuredContent として一度、そして content だけを読み取るクライアント向けにテキストブロックにもミラーリングされています。ミラーは整形済みのコピーなので、2 つのうちサイズが大きいほうです。

npx -y weavatrix mcp . --output-format=structured

実際のリポジトリで run_audit を測定したところ、応答は 8931 バイトから 3589 バイトに減少し、59.8% 小さくなりました。クライアントが構造化出力を読み取るかどうかは呼び出しごとに変わらないため、毎回の呼び出しで引数として繰り返すのではなく、起動時に一度だけ選択します。フラグを指定しにくい場合は WEAVATRIX_OUTPUT_FORMAT=structured でも同じ設定ができ、呼び出し側で独自の output_format を指定した場合は、そちらが優先されます。

json がデフォルトで、ミラーを保持します。そうしないと、structuredContent を無視するクライアントには空の結果が表示されてしまいます。text はテキストブロックのみを返しますが、そのブロックにはシリアライズされた JSON が含まれます。要約モードではありません。アーキテクチャに関する質問には、引数なしで architecture_inventory を呼び出し、範囲が限定されたスタイル仮説を文章で要約してください。

新しいドメインが実際に答えること

質問	ツール	正確な制約
この MCP スキーマは、昨日のリクエストを引き続き受け付けますか？	agent_change_impact	string → integer は互換性がありません。一部のみのカタログでツールが見つからない場合は、削除されたのではなく unconfirmed です。
イベントのレイアウト変更後、この ABI を呼び出すのは誰ですか？	web3_impact	コメントや文字列にある「呼び出し」は利用者ではありません。ABI が一致しても、デプロイが稼働中とは限りません。
エクスポートされた n8n ワークフローで、このフィールドを読み取るのは誰ですか？	n8n_trace	シークレットはグラフに表示されません。
start_node.query を消費する Dify ノードはどれですか？	dify_trace	会話変数は、有向エッジであり、文字列の存在ではありません。
この Mermaid の矢印はコードの呼び出しを証明しますか？	diagram_*	矢印は declared_architecture であり、決して Calls ではありません。
.weavatrix/architecture.json は今も正しいですか？	verify_architecture	不明なルールはフェイルクローズします。

エージェントが尋ねられること

What breaks if I change src/auth/middleware.ts?
Trace POST /api/orders through this backend and its clients.
Which production symbols are dead, and what evidence proves it?
Show duplicate implementations but suppress router boilerplate.
Which dependency violates .weavatrix/architecture.json?
Find every GraphQL, gRPC, Kafka, RabbitMQ, NATS, JMS, SQS, or SNS
contract affected by this branch.
Build the smallest source bundle needed to edit this symbol safely.
Show me this file as it was two commits ago, without a checkout.
Suggest internal links without mixing inferred SEO relationships into
the deterministic code graph.
If I change the email recipient in this exported n8n workflow, who reads it?
If I change start_node.query in this Dify YAML, which nodes consume it?
Did this MCP catalog make `id` an integer so old string requests fail?
Which viem `decodeEventLog` sites still assume the old Deposit layout?
Is this Mermaid arrow a real call, or only declared architecture?

グラフはリビジョンごとに一度だけ構築されます。そのため、影響範囲、API トレース、健全性に関する検出結果、アーキテクチャチェック、クローンファミリー、コンテキストバンドルで、互換性のない部分的なビューを再計算することなく、リポジトリの識別情報が一致します。

回答を見る

Weavatrix が自身のリポジトリをコミット ec8bf30 で分析した実際の回答です。一部を省略（…）し、ローカルのルートパスを短縮しています。次のコマンドで、どの回答も再現できます：weavatrix tool <name> . '<arguments>'。

1 回の呼び出しで全体を把握 — どのリポジトリとリビジョンが回答したのかも正確に確認できます：

{"name": "graph_stats", "arguments": {}}

{
  "nodes": 1294,
  "edges": 2771,
  "freshness": {"state": "CURRENT", "source_revision": "sha256:dd3d96d3…"},
  "relations": {"calls": 651, "contains": 1271, "imports": 419, "references": 314, "…": "…"},
  "repository_context": {
    "root": "…/weavatrix",
    "git_head": "ec8bf3041588623f23ec5e7ebbaff3a333da9ca7",
    "scan_revision": "sha256:dd3d96d3…",
    "graph_age_seconds": 0
  }
}

すべての回答には、この repository_context ブロックが含まれています。1.11.1 以降、各 MCP プロセスはセッション中、起動時のルートを固定します。--allow-retarget を指定して起動していない限り、別のパスへの open_repo は拒否されます。また、省略された expected_repository には、その固定されたルートが設定されます。フォルダー名がすでに分かっている場合も、"expected_repository": "weavatrix" を指定してください。一致しないサーバーは、別のリポジトリについて回答するのではなく、明示的にエラーになります。

編集前に影響範囲を確認：

{"name": "get_dependents", "arguments": {"label": "file:src/mcp/server/mod.rs", "max_nodes": 6}}

{
  "dependents": [
    {"distance": 1, "node": {"id": "file:src/main.rs", "language": "rust"}},
    {"distance": 1, "node": {"id": "file:src/mcp/mod.rs"}},
    {"distance": 1, "node": {"id": "file:src/mcp/server/tests/catalog.rs"}},
    {"…": "…"}
  ]
}

チェックアウトせずにファイルの当時の内容を確認（git_read_blob）：

{"name": "git_read_blob", "arguments": {"path": "Cargo.toml", "revision": "HEAD~3", "max_bytes": 400}}

{
  "path": "Cargo.toml",
  "revision": "70b5bc788a10ec89ab28b9ecbc005e3b9c7f9829",
  "oid": "f5f54bac00a4feb6e965c0d87c5c6d4d25782e91",
  "kind": "utf8-text",
  "lines": ["[package]", "name = \"weavatrix\"", "version = \"1.9.2\"", "…"],
  "size_bytes": 1224,
  "returned_bytes": 400,
  "truncated": true
}

ec8bf30 の 3 つ前のコミットでは、このパッケージのバージョンは 1.9.2 でした。エージェントは作業ツリーに触れることなく、差分の続きにあたる内容を読み取ります。バイナリ BLOB は、意味のないデータにデコードされるのではなく、フェイルクローズします。

67 個の読み取り専用操作

ワークフロー	操作
グラフの概要把握	graph_stats, get_node, get_neighbors, query_graph, god_nodes, shortest_path, get_community, list_communities, module_map, build_graph
変更の影響	get_dependents, change_impact, select_tests, verified_change, prepare_change, graph_diff
正確なソースコンテキスト	search_code, read_source, inspect_symbol, go_to_definition, find_references, context_bundle, map_stacktrace
健全性と品質	find_duplicates, find_dead_code, run_audit, coverage_map, hot_path_review, perf_attribution

| API とトランスポート | list_endpoints, trace_endpoint, trace_api_contract | | アーキテクチャ | architecture_inventory, get_architecture_contract, verify_architecture, verify_capabilities, explain_architecture_violation, propose_architecture_exception | | ローカル CI | ci_restrictions, explain_restriction | | Git とリポジトリ | git_history, git_read_blob, cross_repo_git, open_repo, list_known_repos, rebuild_graph | | ネイティブ拡張 | vector_search, semantic_link, seo_link_suggestions, memory_context | | n8n ワークフロー | n8n_inventory, n8n_trace, n8n_context | | Dify アプリ | dify_inventory, dify_trace, dify_context | | エージェントパッケージ | agent_inventory, agent_trace, agent_context, agent_change_impact | | Mermaid 図 | diagram_inventory, diagram_trace, diagram_context | | Web3 統合 | web3_inventory, web3_trace, web3_impact, web3_context |

coverage_map はテストランナーではなく、取り込み処理です。Weavatrix Quality の quality_run と組み合わせて使用してください。これは .weavatrix/coverage/lcov.info をエンジンの検索パスに書き込みます。 レポートがない場合は、カバレッジが計測されていないのであり、0%ではありません。

すべての操作は、分析対象のリポジトリに対して読み取り専用です。 ページネーションと明示的な上限によって、大規模な近傍、履歴、検索、 コントラクトの一覧が制限されます。

build_graph と architecture_inventory は、同じ型付きビルドモデルを共有するようになりました。 architecture_inventory のデフォルトは detail:"summary" です。上限付きの応答で、 グラフ全体の合計、代表的なコンポーネントパス、支配的な結合、 明確にラベル付けされたサイクル候補を提示します。また、モジュール化されたソース構成、 オニオン型の依存関係、ポートとアダプター、階層化された依存関係、デプロイトポロジーについて、 独立したスタイル仮説も報告します。各仮説では、根拠、矛盾点、不明点、ステータスを示します。 宣言されたコントラクトのスタイルが、決して証明として扱われることはありません。 ページ分割されたエッジとソースの根拠を取得するには、detail:"full" を指定してください。 output_format:"text" を指定しても詳細度は下がりません。 Rust では、明示的な impl Trait for Type はオニオン型またはポートとアダプターの分析結果を 裏付ける場合がありますが、固有の impl Type では裏付けになりません。 ネストされた Cargo、npm/TypeScript、Go、Python のコンポーネント、 多対多の宣言済みメンバーシップ、衝突しない識別子、構成述語、 不変のソース根拠が保持されます。コンポーネントの合計と SCC／サイクルの証拠は、 ページネーションの前に完全な射影を対象として算出されるため、応答の上限によって グラフの判定が変わることはありません。商コンポーネントのサイクルは、 シンボルの再帰と誤って分類されることなく、アーキテクチャ上のサイクルとして報告されます。

ci_restrictions は、ローカルの GitHub Actions ワークフローとリテラルなチェックを読み取る際、 同じターゲット対応トポロジーを再利用します。ルートファイル、繰り返されるコマンド、 UTF-8 BOM のオフセット、任意のイベント、ベースブランチ、変更パスのシナリオについては、 正確な根拠が保持されます。動的条件、相互排他的な構成の和集合、実際の実行、 リモートの必須チェックは、明示的に不明として扱われます。ワークフローファイルだけでは、 ゲートの通過は決して確立されません。

言語とリポジトリの対象範囲

エンジンは、65 の登録済み拡張子にまたがる 24 の名前付き対象範囲を認識します。 サポートの根拠は対象ごとに異なります。情報を失わないトークン化を、型付きの意味解決として示すことはありません。

グループ	対象範囲
コード	Rust；JavaScript/JSX；TypeScript/TSX；Python；Go；Java；C#；C；C++；SQL；Bash/Zsh；Swift；Solidity
コントラクトと構成	GraphQL；Protobuf/gRPC；JSON/JSONC（解析後の n8n）；YAML/Kubernetes（解析後の Dify）；Terraform/HCL；XML
ドキュメントと UI	HTML/Vue/Svelte；CSS/SCSS/Sass/Less；Markdown/MDX；reStructuredText；AsciiDoc

対象範囲をまたぐパスにより、HTTP ルートと呼び出し、GraphQL のオペレーションとスキーマ型、gRPC のサービスとストリーミングモード、Kafka、RabbitMQ/AMQP、JMS、NATS、SQS、SNS のプロデューサーとコンシューマーを関連付けます。パッケージマニフェスト、ロックファイル、カバレッジ成果物、アーキテクチャコントラクトも根拠になります。

証明できない動的ディスパッチは未解決のままです。静的到達可能性を実測カバレッジとは呼びません。また、存在しない任意の根拠は、明示的に不在として扱います。

ワークフローのエクスポート対象領域

n8n と Dify は、新しい MCP サーバー、エディター、ランタイムではありません。同じエビデンスグラフ上の対象領域です。JSON は引き続き JSON アダプターを通り、YAML は引き続き Kubernetes アダプターを通ります。解析後、認識されたエクスポートは型付きノード、ポート、関係になります。package.json が n8n ワークフローになることはありません。Kubernetes の ConfigMap が Dify アプリになることもありません。

flowchart LR
  export["n8n JSON / Dify YAML in git"] --> parse["Existing JSON / YAML parse"]
  parse --> domain["After-parse domain"]
  domain --> graph["Revision-bound evidence graph"]
  graph --> inventory["inventory"]
  graph --> trace["trace"]
  graph --> context["context"]

製品ページ：n8n · Dify · パーサー。

n8n（1.12.0 で提供）

エクスポートされたワークフロー JSON → n8n_inventory、n8n_trace、n8n_context。

すでに git にあるエクスポートについて、どのノードがこのフィールドを読み取るか、どのノードがその出力にデータを渡すか、このファイルに実際に何が含まれているか、といった質問に使います。エージェントはリポジトリのリビジョンを参照し続けます。n8n にログインすることはありません。

• ID はファイルごとにスコープされます。2 つのワークフローで同じ表示名が使われていても、別々のノードのままです。複数に該当する短いラベルは ambiguous になります。
• flows_to は制御フローです。depends_on_output はデータです。これらを 1 つの関係としてたどることはありません。
• すべての $('Name') / $node / $items の出現箇所がバインドされます。最初の一致箇所だけではありません。.item と .first() は別個に扱われます。動的な $('' + prefix) は unresolved:dynamic_node になります。
• typeVersion の 1.7 は整数に変換されません。
• サブワークフローが見つからない場合は「削除済み」ではなく「提供されていない」と扱われます。
• シークレット、Cookie、認証ヘッダー、URL 認証情報、pinData、staticData、$env の値は、デフォルトのグラフとコンテキストに含まれません。

npx -y [email protected] mcp . --profile=n8n

Dify（1.13.0 で提供）

エクスポートされた DSL YAML → dify_inventory、dify_trace、dify_context。

ローカルの YAML エクスポートについて、どのノードが start_node.query を消費するか、どの Code または Template 領域にセレクターへの言及があるか、エクスポートから何が省かれているか、といった質問に使います。エージェントはリポジトリのリビジョンを参照し続けます。Dify コンソールを呼び出すことはありません。

• AppKey はコーパスとアーティファクトの出所で構成されます。data.title は表示専用です。
• ノードのサブジェクト型は node.data.type であり、キャンバスの custom UI 型ではありません。
• イテレーション／ループの子要素は parentId のスコープを維持します。フラット化されません。
• {{#start_node.query#}} マーカーと構造化セレクターは、ソース範囲を伴う reads_variable / depends_on_output になります。
• 会話アサイナーの読み取りと書き込みは型付きのまま維持されます。Code と Template の領域は一覧化されますが、実行されません。
• Chat などのモードは認識されます。サポートされていないモードは、正常な空のグラフではなく structure_only になります。
• 環境値と認証情報のようなラベルは、デフォルトの一覧とコンテキストから除外されます。

npx -y [email protected] mcp . --profile=dify

エージェントパッケージ（1.14.0 で同梱）

ローカルのプラグイン、スキル、カタログ、観測ファイル → agent_inventory、 agent_trace、agent_context、agent_change_impact。

すでに Git にあるパッケージについての質問に使用します。プラグインが公開するカタログツール、サーバーを関連付ける MCP 設定、サポート対象のスキーマ部分において 2 つのカタログスナップショットの互換性が維持されているか、といった質問に対応します。サポートされていないキーワードは undetermined のままです。ツールラベルが重複している場合は ambiguous-identity になります。エージェントはコマンドを実行せず、allowed-tools は宣言であり、呼び出しが確認されたことを示すものではありません。

npx -y [email protected] mcp . --profile=agent

Mermaid 図（1.14.0 で同梱）

.mmd、.mermaid、Markdown／MDX のフェンス → diagram_inventory、 diagram_trace、diagram_context。

描画された矢印は declared_architecture であり、Calls ではありません。これらによってデッドコードの検出結果が解消されることはありません。バインディングは .weavatrix/diagram-links.json からのみ取得されます。名前の一致は厳密ではありません。change_impact.documentation は本番環境への影響とは別です。

npx -y [email protected] mcp . --profile=diagram

Web3 統合（1.15.0 で同梱）

ABI JSON、提供された solc／Foundry アーティファクト、静的な viem／wagmi コンシューマー → web3_inventory、web3_trace、web3_impact、web3_context。

コントラクトインターフェースが変更され、確認済みのクライアント呼び出し箇所やデコーダー箇所が必要な場合に使用します。コンシューマーは、対応するアーティファクトファイルに基づいて解析されます。候補が見つからない場合は、メンバーが削除されたのではなく missing_input になります。呼び出しオブジェクト内のコメントプロパティは呼び出し先ではありません。インデックス付きマスクのイベント変更により、誤ったデコードが気付かれないまま発生することがあります。ABI が同一であっても、稼働中のデプロイが証明されるわけではありません。エンジンはコントラクトをコンパイルせず、RPC を呼び出さず、ウォレットを開きません。

npx -y [email protected] mcp . --profile=web3

隣接するツールとの比較

これらのツールはそれぞれ異なる用途に対応します。Weavatrix は稼働中のコンソールや CI リンターの代わりにはなりません。

ニーズ	使用するもの
Git にすでにある n8n または Dify エクスポートの変更影響を確認する	同じリビジョンに紐づくグラフ上の Weavatrix n8n_*／dify_*
稼働中の n8n インスタンスを操作する（実行、認証情報、エディター API）	n8n-mcp
稼働中の Dify コンソールを操作する（実行、公開、150 以上の API ツール）	dify-mcp
CI で Dify YAML をリンティングまたは差分確認する	difyctl

Weavatrix が答えるのは、「このリポジトリのこのリビジョンで、この変数を使用しているのは誰か」です。式、Jinja、Code ノードを実行せず、アプリをデプロイまたは公開することもありません。

共通エンジンのベンチマーク

n8n と Dify のエビデンスは、解析後のプロセス内で生成されます。これらのツールが n8n または Dify ホストへ HTTP リクエストを送信することはありません。パーサーごとのミリ秒単位の数値を捏造することもありません。

実測したインストール済み MCP 境界（2026-08-03、パッケージ版 1.2.0／ weavatrix-rust 2.1.1 と weavatrix-js 0.3.15、同じ JavaScript サービスリポジトリ）は、これらのドメインに共通する正確なエンジン性能の数値です。

インストール済み境界	Rust 1.2.0	JavaScript 0.3.15	比率
コールド境界の中央値（起動から最初のツール結果まで）	157.34 ms	5,068.22 ms	32.21x
ウォーム状態の tools/call 中央値	7.94 ms	292.55 ms	36.85x

測定方法：リリースエビデンスおよび docs/benchmarks.md。

これは対象外です

式や Jinja の実行は行いません。n8n や Dify のデプロイは行いません。自動編集は行いません。新しいグラフエンジンではありません。不明な DSL バージョンや、エクスポートに含まれる非表示フィールドを完全にサポートしているかのように装うこともありません。

製品の境界

Weavatrix は、プロトコルに依存しないエンジンと薄い製品アダプターに意図的に分割されています。

coding agent
    |
    | MCP over stdio
    v
weavatrix 1.17.5
    profile catalog · session refresh · filesystem watcher · MCP framing
    |
    v
weavatrix-rust 2.17.4
    typed graph · analysis pipeline · 67 product operations including local CI, n8n, Dify, agent packages, Mermaid, and Web3
    |
    +-- weavatrix-scan      repository discovery and selection
    +-- weavatrix-parse     lossless tokenization and structural facts
    +-- weavatrix-graph     graph model and algorithms
    +-- weavatrix-git       direct Git-object evidence
    +-- weavatrix-search    bounded content and index search
    +-- vector / clone / semantic / memory components

このリポジトリが担うのは、MCP トランスポート、ウォッチャー、ネイティブ npm パッケージング、およびクライアント向けの ID weavatrix です。 weavatrix-rust クレートは再利用可能なエンジンとスタンドアロンの診断用 CLI を担っており、MCP サーバーではありません。 weavatrix-stream は Weavatrix の観測結果向けのアダプターを提供する別個のクレートです。このホストは実行時にこれへ依存しません。 そのため、別個のバイナリでは --version に weavatrix-rust <engine-version> が表示される一方、この製品では weavatrix の製品バージョンと組み込みエンジンのバージョンの両方が表示されます。

エンジンを組み込みたい Rust アプリケーションは、このクレートに依存してください。

[dependencies]
weavatrix-rust = "2"

use weavatrix_rust::{Weavatrix, operations};

let mut engine = Weavatrix::open(".")?;
let result = operations::call(
    &mut engine,
    "change_impact",
    blazingly_json::json!({"files": ["src/auth.rs"]}),
)?;
# Ok::<(), weavatrix_rust::Error>(())

リリースのエビデンス

リリースゲートでは、プロセス内のマイクロベンチマークではなく、インストール後の npm 境界を測定します。双方をパッケージ化し、分離された npm ルートにインストールして、HOME、XDG、AppData、グラフキャッシュが空の状態で起動します。ハーネスは、パッケージ／ネイティブ／initialize の ID、公開される操作、成功した MCP の結果、およびプロセスのクリーンアップを検証します。

weavatrix-rust 2.1.1 を基盤とするパッケージ済みの 1.2.0 製品を、2026-08-03 に、同じ実際の JavaScript サービスリポジトリ（ノード 2,165 個／エッジ 5,712 個）上で、インストール済みの weavatrix-js 0.3.15 と比較して測定しました。各ツールについて、新規プロセスを3組用意し、起動順を交互にしました。

インストール後の境界	Rust 1.2.0	JavaScript 0.3.15	比率
コールド境界の中央値（起動から最初のツール結果まで）	157.34 ms	5,068.22 ms	32.21x
ペア比較のコールド高速化率、6組の中央値	-	-	32.06x
ウォーム時のツール呼び出し中央値	7.94 ms	292.55 ms	36.85x

リリースのしきい値（コールド時 24x、ウォーム時 30x）はどちらも達成しました。また、ペア比較のコールド時中央値は 1.0.0 のベースラインで記録された 30.34x をわずかに上回っているため、3つの新しいツール、トークン予算、依存性注入のエビデンスによって、インストール後の境界で性能が低下していないことが確認できました。生のエビデンスと手法は、benchmark-results および docs/benchmarks.md にあります。

安全性と決定性

• 読み取り専用の MCP サーフェスです。
• ソースを書き込む操作はありません。
• リポジトリのコードを実行しません。
• ネイティブエンジンから git、rg、言語サーバー、Node、Python を起動しません。
• リポジトリの分析でネットワーク経路を使用しません。
• npm のインストールスクリプトやインストール後のバイナリダウンロードはありません。
• ファイル、バイト数、結果、履歴、ページネーションに上限を設けています。
• 順序とリビジョンの出所が安定しています。
• ファーストパーティのエンジンクレートでは Rust の unsafe を禁止しています。
• 製品、エンジン、保守対象のファーストパーティコンポーネントには MIT ライセンスを適用しています。

ファイルシステムの監視は、派生状態を無効化するだけです。次の操作で上限付きの更新を行い、リポジトリを編集することはありません。監視に必要なメモリは一定です。各イベントは受信時に分類され、保留中の変更フラグ1つに集約されます。そのため、target/ や node_modules/ の下でビルド出力が頻繁に更新されても、ツール呼び出しの間に待機しているサーバーにイベントが蓄積することはありません。

アーキテクチャと開発

製品アダプターは、ポートとアダプターのパターンに従います。

inbound MCP server
        |
application session
        |
repository + change-monitor ports
        |
weavatrix-rust adapter · notify adapter

mcport はインバウンドサーバーにのみ分離されています。アプリケーション層は MCP フレームにも notify イベントにも依存せず、エンジンもいずれにも依存しません。

ローカルのゲート：

cargo fmt --all -- --check
cargo clippy --all-targets -- -D warnings
cargo test --all-targets

ネイティブ npm アーティファクトは scripts/build-npm-packages.mjs でビルドされます。公開は、すべてのプラットフォーム用バイナリ、ID チェック、パッケージチェック、およびインストール後の境界ゲートを通過した後、保護された GitHub Actions ワークフローによって行われます。

ドキュメント

• はじめに
• ツールリファレンス
• エビデンスモデル
• 言語サポート
• MCP 製品アーキテクチャ
• npm 配布
• 依存関係
• ベンチマーク
• n8n エクスポートのエビデンス
• Dify エクスポートのエビデンス
• ワークフローパーサー
• エンジン API とアーキテクチャ

ライセンス

MIT。詳細はLICENSEをご覧ください。