NEAT MCP server

NEAT

NEAT solves the AI coding context problem. It constructs a live deterministic model of your codebase — static code and live runtime behavior fused into one graph — and hands your AI agents the grounded, full-stack context they need to query, code, debug, and write rules against it. This achieves the following:

• Coding LLMs hallucinate less & are more accurate.
• Rather than endlessly grepping files and guessing problems, NEAT provides time-travelling error logs along the model's nodes and edges so the LLM can infer exactly what's wrong.
• Rules & Policies allow agents to write new features while adhering to rules set by previous features, other LLMs, or engineers. For example, only use postgres for services x and y, and mongoDB for services p and q (the possibilities are endless).

TL;DR The deterministic grounded truth of code for your agents.

NEAT is in active development. Capability ships as patch releases on the npx neat.is surface; see open issues for what's on deck.

One command

npx neat.is

Run it from inside your project (or npx neat.is ). It discovers your services, extracts the static graph, wires in OpenTelemetry, starts the daemon, and opens the dashboard — no config. Then run your app and watch the live edges populate.

On Windows, use the neat command, not npx neat.is. npm generates a shim literally named neat.is, and Windows won't execute a .is file — it hands it to a file association instead. Install once and run the dotless binary: npm i -g neat.is, then neat (or neat ). Without a global install: npx -p neat.is neat. Every npx neat.is below becomes neat this way.

A more in-depth explanation:

At the center of NEAT is one live graph of your system, fused from two streams into a single model you can query many ways:

• Static analysis — tree-sitter over your source (JavaScript, TypeScript, Python), package.json, and yaml / env config. Every source file becomes a node; imports between them become edges; the calls each file makes to databases, queues, and external hosts are extracted from the code.
• Runtime telemetry — OpenTelemetry spans, attributed back to the exact file and line that made the call. NEAT wires the instrumentation for you, so the runtime edge lands on the same file node the static edge does.

Both streams land on the same nodes, so the graph holds what your code declares and what your system does side by side. From there, the useful questions fall out of one model: what would break if this node dies (blast radius), what broke first (root cause), which architectural rules a change would violate (policies), and where declared intent and observed reality part ways (divergence). Same graph, different traversals.

The file is the primary unit. A relationship in the graph runs from a file — src/services/billing.ts ──CALLS──▶ api.stripe.com — not from a vague service blob. Anchoring relationships to files and lines is what keeps every one of those answers sharp: a finding names this file, calling this target, rather than a service-shaped shrug.

Every edge carries a provenance tag so a consumer knows exactly how much weight a claim deserves:

Shortened. The full README is on GitHub.