Serveur MCP code-context-engine
Commit 17 oct. 2026Fournit un graphe de code en local-first et des paquets de preuves compressés pour aider les agents de codage IA à identifier les fichiers pertinents tout en réduisant la consommation de tokens de contexte.
Aussi connu sous ParsaVictor/code-context-engine
- Étoiles
- 5
- Outils
- —
- Téléchargements, 30 jours
- —
- Dernière version
- —
- Dernier commit
- 17 oct. 2026
- Licence
- MIT
Qu'est-ce que code-context-engine MCP ?
code-context-engine est un serveur MCP. Fournit un graphe de code en local-first et des paquets de preuves compressés pour aider les agents de codage IA à identifier les fichiers pertinents tout en réduisant la consommation de tokens de contexte.
Résumé généré à partir du README du projet
À propos du MCP server code-context-engine
Les développeurs utilisant des agents de codage IA comme Claude Code, Cursor ou Zed peuvent utiliser ce moteur pour fournir un contexte de code précis sans submerger le modèle avec des dépôts entiers. Il fonctionne comme un MCP server local-first qui construit un graphe de code par projet afin d'identifier uniquement les fichiers les plus pertinents pour une tâche spécifique. En utilisant un paquet de preuves compressé (folded evidence packet), le moteur fournit les signatures de fonctions tout en masquant les corps de code volumineux pour économiser les tokens de contexte.
Cet outil prend en charge un large éventail d'environnements au-delà du code web standard, incluant les notebooks Python, les scripts shell et les artefacts de machine learning tels que les datasets et les modèles. Il cartographie également les fichiers de configuration comme YAML, JSON et les paramètres Hydra directement vers le code qu'ils paramètrent. Les utilisateurs l'installent localement en indexant leur projet avec le CLI neuromesh et en le connectant à leur client MCP préféré via stdio. Cette approche permet de réduire l'utilisation des tokens de contexte et les coûts lors de sessions de codage prolongées.
Ce que vous pouvez faire avec
- 1Naviguer dans des bases de code de machine learning complexesUn développeur peut demander à un agent de tracer les relations entre les modèles, les datasets et les boucles d'entraînement.
- 2Résoudre les dépendances entre configuration et codeUn agent peut identifier quels paramètres de code sont contrôlés par des clés de configuration YAML ou JSON spécifiques.
- 3Rechercher par littéraux de chaîneUn développeur peut demander à un agent de trouver où sont définies des variables d'environnement ou des routes API spécifiques.
Extrait du README du projet. Chaque cas d'utilisation est vérifié par rapport à une citation du document.
Configuration
CARGO_BUILD_JOBSNM_EXPLAIN
| Nom | Description | Type |
|---|---|---|
| CARGO_BUILD_JOBS | — | |
| NM_EXPLAIN | — |
Vérifications automatisées
Exécuté le 14 nov. 2026Rapport complet →Pas encore vérifié. Un serveur nécessite un score de 80, aucune faille sérieuse et suffisamment de données pour que nous puissions effectuer les vérifications. Fonctionnement des vérifications · Ce qu'il faut corriger pour gagner des points
- Dépôt source lié et accessibleparsavictor/code-context-engine is public and reachablegithub.com/parsavictor/code-context-engine ↗Réussi
- Le nom du package correspond au dépôt sourceNon vérifié
- Provenance du build (attestation Sigstore)Non vérifié
- Licence open source (OSI)MITspdx.org/licenses/MIT.html ↗Réussi
- Commit ou version publiée au cours de l'année écouléeLast commit or release 2026-10-17github.com/parsavictor/code-context-engine ↗Réussi
- OpenSSF ScorecardNon vérifié
- Nom du package non proche d'un package populaireNon vérifié
- Aucun avis critique dans le package ou ses dépendancesNon vérifié
- Aucune instruction cachée destinée au modèle0 tool descriptions and the README read; no override phrases, credential paths or hidden charactersRéussi
- Les outils destructifs sont étiquetésNon vérifié
- Le point de terminaison distant répond à la poignée de main MCPNon vérifié
README
Voir sur GitHubcode-context-engine
Ship the right code, not the whole repo. A local-first MCP context engine for AI coding agents: a per-project code graph, seed resolution from the task as written, and a folded evidence packet — measured on repositories it was never tuned on.
Cursor · Claude Code · Codex · VS Code · Zed · any MCP client
Why · Measured · Install · How it works · Benchmarks · FAQ · Roadmap · Docs
Why this fork
NeuroMesh is a strong local-first context engine for web codebases. This repository continues it with two goals that the baseline did not meet:
| Goal | Baseline v0.9.0 | This project |
|---|---|---|
| Project isolation — zero cross-project files in a packet | one live graph per process; a mis-detected workspace could contaminate it | deterministic ProjectId, single-project invariant on the live graph, leakage gate in CI (offered upstream) |
| Universal codebases — not only web | no notebooks, no config→code layer, no ML node types | .ipynb, YAML/JSON/argparse/Hydra config→code edges, ML artifact graph (Dataset · Model · Checkpoint · Metric · TrainLoop), shell scripts, string-literal index (routes, tool names, env vars) |
| Honest numbers | one-repo demo table | gold sets on 10 third-party repositories, four of them never tuned on; a model-executed task-success benchmark with a separate judge |
Everything the engine claims is in docs/measured.md, with what is not measured listed next to it.
What is measured
Gold sets are written from reading the source before the engine runs. Recall = the gold files the packet contains; precision = share of packet files that are gold; forbidden = a file the task must not ship.
Repositories the engine was never tuned on (2026-09-21, main):
| Holdout | Languages / stack | Recall | Precision | Forbidden |
|---|---|---|---|---|
| gin + torchvision | Go, Python | 1.000 | 0.700 | 0 |
| libuv + fmt | C, C++ | 1.000 | 0.589 | 0 |
| os-lib + cli + Flux.jl | Scala, R, Julia | 1.000 | 0.589 | 1 |
| peft + keras-hub | Hugging Face / Keras 3 libraries | 1.000 | 0.632 | 0 |
Sets that have been tuned on (dev-class): nanoGPT / express / vit-pytorch / fastapi-template 1.000 / 0.938 · django + ultralytics 1.000 / 0.675 · Hydra + argparse configs 1.000 / 0.767 · Fastify + Next.js app router (30 q) 0.800 / 0.608 · this repository (30 real questions) 0.833 / 0.578.
Task success with a real model (DeepSeek-V4-Pro answering, GLM-5.3 judging against the real source, real verify for patch tasks):
| Set | packet | whole gold files | naive grep |
|---|---|---|---|
| fixtures (26 tasks) | 0.808 · 4.2k tokens | 0.808 · 8.7k tokens | 0.577 |
| gin holdout (10) | 1.000 · 8.1k | 1.000 · 11.1k | 0.800 |
| torchvision holdout (10) | 1.000 · 7.8k | 0.800 · 8.7k | 0.600 |
The packet matches or beats "just open the right files" at 1.4–2.1× the success per token, and beats grep everywhere. Recall is the strength; precision (1–3 neighbour files too many) is the open front — see ROADMAP.md.
Against the baseline it was forked from
Same 112 gold tasks on 15 third-party repositories, same machine, same day (2026-09-21); NeuroMesh v0.9.0 built from the baseline-v0.9.0 tag, this fork from main. Scored per task by file name from each engine's own optimize output — raw results in docs/baseline-vs-fork-2026-09-21.txt, script in scripts/compare-baseline.sh.
| NeuroMesh v0.9.0 (baseline) | this fork | |
|---|---|---|
| gold files found (recall, 112 tasks) | 0.735 | 0.938 |
| share of packet files that were wanted (precision) | 0.206 | 0.633 |
| forbidden files shipped | 12 | 7 |
| Scala / R / Julia repositories | 0.000 recall (not parsed) | 1.000 |
| Hydra + argparse config questions | 0.500–0.750 recall | 1.000 |
| C / C++ (libuv, fmt) | 0.688–0.875 recall | 1.000 |
shell scripts, notebooks, .ps1 |
skipped at index time | indexed |
| cross-project leakage | one live graph per process | ProjectId invariant + CI leakage gate |
Same recall where the baseline already worked (Go, Python, Django, ultralytics); three times the precision everywhere — the baseline ships four to six files for every one that is wanted. The web-stack front (Fastify + Next.js) is the one place both are weak (0.65 recall), which is why it is the current focus.
What this fork adds
| Capability | What it does | Measured by |
|---|---|---|
| Project isolation | deterministic ProjectId, single-project invariant on the live graph, a CI test that indexes two projects sharing a file and asserts zero leakage |
P0 gate in CI |
| Config → code | YAML / JSON / .env keys and argparse flags become nodes; cfg.x, args.x, self.hparams.x become Parameterizes edges; Hydra defaults: composition is an import; a key's named reader takes a seat |
holdout-cfg 1.000 / 0.712 (F55, F71, F72) |
| ML artifact graph | Dataset · Model · Layer · TrainLoop · EvalLoop · Checkpoint · Metric nodes from a PyTorch / Keras overlay; notebooks parsed cell by cell | holdout-ml2 1.000 / 0.632 untuned (F26, F58) |
| String-literal index | quoted names — routes, MCP tool names, event names, env vars, camelCase hooks — resolve to the files that spell them | F75, F78, F80 |
| Twin resolution | same-named definitions settled by directory words, body words and prompt anchors, plural-tolerant; framework-convention stems (route.ts, index, layout) are not "named" |
F64, F70, F80, F82 |
| Noise discipline | guesses never land in docs / tests / fixtures / examples unless asked; alias terms must start a word; acronyms resolve exactly | F61, F73, F75 |
| Deterministic packets | every tie has a total order; the same question gives the same packet | F17, F63, F70 |
| A learning loop that learns the path | positive feedback reinforces only the edges a successful task walked; negative feedback reaches required files | F57, F69 |
| Task-success harness | packet vs whole gold files vs grep with a real model, a separate judge that reads the real source, real verify for patch tasks |
phase C, F76, F77 |
| 12 languages + shell, PowerShell, notebooks | tree-sitter grammars plus light parsers for YAML, JSON, SQL, shell, .ipynb |
F78 |
In a Claude Code session
Same task, same model (Sonnet), claude -p with and without the MCP server, cost from the CLI's own usage report:
| Repository | plain (Read / Grep) | with this engine | context tokens | cost |
|---|---|---|---|---|
| Django, 3,516 files | 8 turns · 233k context tokens · $0.239 | 5 turns · 129k · $0.204 | −45% | −15% |
| fastify/demo, 68 files | 8 turns · 244k · $0.408 | 7 turns · 194k · $0.391 | −20% | −4% |
The system prompt and tool definitions are re-read every turn and dominate small repositories; the engine only shrinks the code-context share. "99% reduction" figures compare a packet with the whole repository, which no agent sends; the numbers above are what a session actually pays.
Install
Pre-built binaries for Linux x86_64, macOS (Apple Silicon) and Windows x86_64 are on the releases page (v1.0.0 is the first).
curl -fsSL https://raw.githubusercontent.com/ParsaVictor/code-context-engine/main/install.sh | sh
irm https://raw.githubusercontent.com/ParsaVictor/code-context-engine/main/install.ps1 | iex
Or from source:
git clone https://github.com/ParsaVictor/code-context-engine
cd code-context-engine
CARGO_BUILD_JOBS=2 cargo build --release -p neuromesh-cli # target/release/neuromesh
Then, from the root of the project you want to index:
neuromesh doctor # binary + workspace check
neuromesh connect --global --agent-rules # write MCP config + agent rule (Cursor, Claude, VS Code, …)
neuromesh index # build the graph (seconds on most repos)
Manual MCP config (any client):
{ "mcpServers": { "neuromesh": { "command": "neuromesh", "args": ["mcp"] } } }
Per-client paths, engines and options: docs/mcp.md · docs/configuration.md.
How it works
task as written ──► seed resolution ──► graph activation ──► selection ──► folded packet
identifiers, files, Calls / Imports / required + signatures kept,
config keys, string Parameterizes / callees + bodies folded,
literals, path words twins, pheromones ranked fill budget-capped
- Index — tree-sitter (and light parsers for YAML/JSON/shell/notebooks) turns every file into nodes and edges; string literals that look like names (
"/api/users","neuromesh_record_feedback",DATABASE_URL) are indexed too. - Seed — the prompt's code names resolve to nodes; twins with the same name are settled by directory and body words; guesses that land in docs/tests/fixtures are dropped.
- Activate & select — energy spreads along typed edges; seeds and the callees the prompt names get required seats; the rest is a ranked, budgeted fill.
- Fold — bodies outside the question are folded to signatures; the agent can expand a fold on demand.
- Learn —
record_feedbackreinforces the path a successful task walked, never a whole neighbourhood.
The MCP agent loop (get_context_packet → search_symbols / expand_gap → expand_fold → trace → record_feedback) is documented in docs/agent-guide.md.
Run the benchmarks
bash scripts/benchmark-holdout.sh # every gold set, one line each (checkouts fetched, graphs cached)
bash scripts/benchmark-holdout.sh holdout-web # one set
NM_EXPLAIN=1 bash scripts/benchmark-holdout.sh dev # + per-task reasons in target/explain-dev.txt
Rules the project holds itself to: holdout sets are never tuned on; ratchets only move up; a mixed result is reverted and recorded, never shipped. Every finding since the fork (F1–F82) is written down with its measurement in docs/planning/stage5-findings.fa.md.
Documentation
| Read this when you want to… | |
|---|---|
| wire an agent to the engine | Agent guide · MCP tools |
| use the CLI | CLI · Configuration · Engines |
| understand the design | Architecture · Isolation |
| check the numbers | Measured · Quality methodology |
| ask the short questions | FAQ |
| follow or join the work | ROADMAP.md · Planning & findings (Persian) · Contributing |
Independent derivative of NeuroMesh by yoosef alipour, MIT. Baseline tag baseline-v0.9.0. See NOTICE and ATTRIBUTION.md. MIT · LICENSE
Questions sur code-context-engine MCP
Prend-il en charge d'autres langages que les technologies web ?
Oui, il prend en charge 12 langages ainsi que shell, PowerShell et les notebooks grâce aux grammaires tree-sitter et à des parseurs légers.