Weavatrix

Weavatrix — native MCP repository intelligence

Part of the Weavatrix ecosystem: evidence infrastructure for AI software agents.

Give your coding agent repository evidence before it starts guessing.

Weavatrix is the native MCP product that answers the questions agents otherwise invent: what breaks if this file changes, who consumes this n8n field, whether an MCP schema still accepts yesterday’s request, which viem call sites follow an ABI layout change, and whether .weavatrix/architecture.json still holds. 67 read-only operations, one revision-bound graph, no LSP and no prompt pack.

Codex, Claude Code, Cursor, and Grok get impact, architecture, APIs, Git history, duplicates, dead code, search, semantic links, temporal memory, exported n8n workflows (n8n_*), Dify YAML apps (dify_*), Agent Plugins/Skills/MCP catalogs (agent_*), Mermaid flowcharts (diagram_*), and Web3 ABI/consumer impact (web3_*). Those parsers are domains on Weavatrix Core, not new MCP products. Dedicated pages: n8n · Dify · parsers.

It does not answer from a larger grep or an invented confidence score. Every bounded result can carry the repository revision, file, line, extractor, evidence kind, and confidence that produced it.

Adjacent MCP tools (not this host)

This repository is the stdio MCP host and plugin pack. It pins weavatrix-rust. It does not grow a second indexer, and it does not compete with the engine crate for the same README story.

The host’s unique job is transport: profiles, watching, npm/crate distributions, and the 67-tool catalog over one engine session. Measured engine times live in weavatrix-rust benchmarks, not here.

Ecosystem place (UNDERSTAND)

Weavatrix (this) — code facts

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

Loom consumes Weavatrix facts for semantic classification (e.g. “this fn is a candidate for data.json.parse@1”). Loom must not grow a second product code indexer. Normative Loom side: ADR-0012.

The same source is distributed in two forms:

The npm package exists for convenience; it does not contain a different JavaScript engine. Both distributions run the same native adapter and the same weavatrix-rust analysis engine. The separately versioned weavatrix-js package is the legacy JavaScript implementation used for compatibility and historical baselines; it is not bundled into weavatrix.

Install as a plugin

The repository ships one plugin bundle for Cursor, Codex, Claude Code, and Grok Build. Each client starts the published native npm distribution and loads the same read-only MCP tools. Its optional Weavatrix skill activates only for tasks that benefit from indexed, cross-file evidence; detailed tool routing is loaded separately when needed.

Cursor plugin

Search for Weavatrix in Cursor's Plugins view after its marketplace review is complete. The bundle can be tested before listing by copying or linking plugins/weavatrix to ~/.cursor/plugins/local/weavatrix and reloading the Cursor window.

Codex plugin

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

codex plugin add weavatrix@weavatrix

Claude Code plugin

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

claude plugin install weavatrix@weavatrix

Grok Build plugin

grok plugin marketplace add Weavatrix/weavatrix

Open /marketplace and install Weavatrix. Grok also accepts the plugin directly with grok plugin install Weavatrix/weavatrix#plugins/weavatrix.

Install in 30 seconds

Run the convenient prebuilt npm distribution:

npx -y weavatrix mcp .

Or install the same MCP product through 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 .

Everything after -- is the server command, so -y reaches npx instead of Grok. The equivalent hand-written entry:

# ~/.grok/config.toml

[mcp_servers.weavatrix] command = "npx" args = ["-y", "weavatrix", "mcp", "."] startup_timeout_sec = 120

The package unpacks to roughly 40 MB, so the first npx launch can spend longer fetching it than Grok's 30-second default startup timeout allows. startup_timeout_sec covers that once; npm i -g weavatrix or cargo install weavatrix removes the cold start for every later session.

Use --scope project to write .grok/config.toml inside a repository instead, so a clone carries the server with it.

Cursor

Prefer the Cursor plugin (it already passes ${workspaceFolder}). For a hand-written user entry, pin the server to the open workspace — not the host process cwd — and avoid running both a user MCP and the plugin at once:

// ~/.cursor/mcp.json

{ "mcpServers": { "weavatrix": { "command": "npx", "args": ["-y", "weavatrix@1.17.5", "mcp", "${workspaceFolder}"] } } }

Profiles expose bounded views of the same engine:

npx -y weavatrix@1.17.5 mcp . --profile=all

npx -y weavatrix@1.17.5 mcp . --profile=code npx -y weavatrix@1.17.5 mcp . --profile=seo npx -y weavatrix@1.17.5 mcp . --profile=n8n npx -y weavatrix@1.17.5 mcp . --profile=dify npx -y weavatrix@1.17.5 mcp . --profile=agent npx -y weavatrix@1.17.5 mcp . --profile=diagram npx -y weavatrix@1.17.5 mcp . --profile=web3

The npm package contains native binaries for Windows x64/arm64, macOS x64/arm64, and glibc Linux x64/arm64. It has no install script and performs no runtime download.

Halve every answer on a client that reads structured output

An MCP result carries the payload twice: once as structuredContent, and once mirrored into a text block for clients that read only content. The mirror is the pretty-printed copy, so it is the larger of the two.

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

Measured on run_audit over a real repository, the response falls from 8931 to 3589 bytes, 59.8% smaller. Whether a client reads structured output does not change between calls, so it is chosen once at startup rather than restated as an argument on every call; WEAVATRIX_OUTPUT_FORMAT=structured does the same where a flag is awkward, and a call that names its own output_format still wins.

json is the default and keeps the mirror, because a client that ignores structuredContent would otherwise see an empty result. text returns only the text block, but that block still contains serialized JSON; it is not a summary mode. For an architecture question, call architecture_inventory without arguments and summarize its bounded style hypotheses in prose.

What the new domains actually answer

What an agent can ask

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?

The graph is built once per revision. Impact, API traces, health findings, architecture checks, clone families, and context bundles therefore agree about repository identity instead of recomputing incompatible partial views.

See it answer

Real answers from Weavatrix analyzing its own repository at commit ec8bf30, abridged (…) and with