de en es ja ko ru zh

semantic-code-intelligence

Name: semantic-code-intelligence
Author: saitarrun

by saitarrun

Overview Schema Source Related Servers Discussions Admin

Python

Local

Semantische Code-Intelligenz

Lokale semantische Suche und zitierte Code-Durchläufe für Software-Repositories.

Semantic Code Intelligence parst ein Repository in symbolbewusste Chunks, indexiert diese Chunks mit FAISS und BM25, fusioniert beide Ergebnismengen und bewertet die stärksten Kandidaten mit einem Cross-Encoder neu. Die Ergebnisse enthalten exakte Dateipfade und Zeilenbereiche. Alles läuft lokal; kein Cloud-API-Schlüssel erforderlich.

Was es bietet

Hybride semantische und lexikalische Codesuche
Exakte Symbol-, Pfad- und Kontextbegriffs-Boostings
Zuverlässigkeitskennzeichnungen der Suche basierend auf Retrieval-Übereinstimmung
Python-AST-Parsing und strukturelles Parsing für gängige Programmiersprachen
Exakte Zitate wie src/auth.py:L42-L67
Browser-Dashboard und REST-API
CLI-, MCP- und LSP-Schnittstellen
Lokale, von Ollama unterstützte Code-Durchläufe mit deterministischem Evidenz-Fallback
FAISS-, BM25- und SQLite-Index-Persistenz
Inkrementelle Dateisystemüberwachung
Symbol- und Abhängigkeitsgraphen
Reproduzierbare Indexierungs- und Retrieval-Benchmarks

Related MCP server: codebase-analyser

Anforderungen

macOS oder Linux
Python 3.10 oder neuer
Git
Ungefähr 2–4 GB freier Speicherplatz für Python-Abhängigkeiten und lokale Modell-Caches
Optional: uv für schnellere Umgebungsverwaltung
Optional: Ollama für generierte Code-Durchläufe

Die ersten Indexierungs- und Reranking-Vorgänge erfordern Internetzugriff, um Hugging-Face-Modellgewichte herunterzuladen. Nachdem die Modelle zwischengespeichert sind, funktioniert das Retrieval offline.

Schnellstart auf einem sauberen Rechner

1. Repository klonen

git clone https://github.com/saitarrun/Semantic-code-intelligence.git
cd semantic-code-intelligence

2. Umgebung erstellen und Anwendung installieren

Mit uv:

uv venv
source .venv/bin/activate
uv pip install -e .

Mit Standard-Python-Werkzeugen:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e .

Windows ist derzeit kein getestetes Ziel, aber der entsprechende Aktivierungsbefehl lautet .venv\Scripts\activate.

3. Retrieval-Modelle herunterladen und Index erstellen

Modell-Downloads sind standardmäßig absichtlich deaktiviert, damit normale Anwendungsanfragen nie unerwarteten Netzwerkverkehr auslösen. Aktivieren Sie Downloads explizit beim ersten Index und der ersten Abfrage:

export CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1

code-intel index .
code-intel query "Where is HybridRetrievalPipeline implemented?" --citations-only

unset CODE_INTEL_ALLOW_MODEL_DOWNLOADS

Dies bereitet vor:

sentence-transformers/all-MiniLM-L6-v2 für dichte Einbettungen
cross-encoder/ms-marco-MiniLM-L-6-v2 für das Reranking

Der Repository-Index wird in .code_intel_index/ gespeichert. Das Verzeichnis enthält den FAISS-Index, BM25-Daten und SQLite-Metadaten und sollte nicht eingecheckt werden.

4. Webanwendung starten

code-intel serve --host 127.0.0.1 --port 8000

Öffnen Sie http://127.0.0.1:8000.

Das Dashboard umfasst:

Semantische Suche
Code-Durchlauf
Abhängigkeitskarte
Diff- und LSP-Werkzeuge
Repository-Auswahl und Neuindizierungssteuerung
Latenz pro Stufe und Retrieval-Zuverlässigkeitsindikatoren

Ein anderes Repository indizieren

Indexdaten werden standardmäßig im Ziel-Repository gespeichert:

code-intel index /absolute/path/to/project

Dieses Repository durchsuchen:

code-intel query \
  "How are access tokens validated?" \
  --dir /absolute/path/to/project

Verwenden Sie ein separates Indexverzeichnis, wenn das Quell-Repository unberührt bleiben soll:

code-intel index /absolute/path/to/project \
  --index-dir /absolute/path/to/index-storage

code-intel query \
  "Where is the database connection pool created?" \
  --dir /absolute/path/to/project \
  --index-dir /absolute/path/to/index-storage

Erzwingen Sie einen sauberen Neuaufbau nach Änderungen am Parser- oder Einbettungsverhalten:

code-intel index /absolute/path/to/project --force

Semantische Suche

Der Hybridmodus wird empfohlen. Er kombiniert Ähnlichkeit in natürlicher Sprache mit exakter Bezeichnerübereinstimmung:

code-intel query "How does the application serve the web UI?"

Exakte Symbolsuche:

code-intel query "Where is serve_ui implemented?"

Mehr Ergebnisse zurückgeben:

code-intel query "authentication middleware" --top-k 10

Zitate anzeigen, ohne Code zu drucken:

code-intel query "database transaction rollback" --citations-only

Eine einzelne Retrieval-Strategie für Diagnosen auswählen:

code-intel query "PaymentProcessor" --mode sparse
code-intel query "logic responsible for charging a customer" --mode dense
code-intel query "charge customer payment" --mode hybrid

Cross-Encoder-Reranking deaktivieren, wenn geringere Latenz wichtiger ist als Präzision:

code-intel query "configuration loader" --no-rerank

So funktioniert das Ranking

Die standardmäßige Hybrid-Pipeline führt diese Schritte aus:

Erweitert häufige Entwicklerabsichten um deterministische Code-Domänenbegriffe.
Ruft bis zu 50 dichte FAISS-Kandidaten ab.
Ruft bis zu 50 lexikalische BM25-Kandidaten ab.
Fusioniert bis zu 60 eindeutige Kandidaten mit Reciprocal Rank Fusion.
Bewertet bis zu 40 Kandidaten mit einem lokalen Cross-Encoder neu.
Verstärkt exakte Symbole, Pfade und kontextuelle Begriffstreffer.
Entfernt doppelte Zitate und begrenzt sich wiederholende Ergebnisse aus derselben Datei.
Gibt ein Zuverlässigkeitslabel mit den zugrunde liegenden Belegen zurück.

Zuverlässigkeit ist kein LLM-Konfidenzwert. Sie berichtet beobachtbare Retrieval-Signale wie dichte/lexikalische Übereinstimmung, exakte Symboltreffer, Pfadüberlappung und semantische Ähnlichkeit.

Code-Durchläufe

Deterministischer Evidenzmodus

Dieser Modus erfordert kein Ollama. Er gibt abgerufene Symbole, Bereiche, Abhängigkeiten, Quellblöcke und Zitate zurück, ohne Verhalten zu erfinden:

code-intel ask \
  "How does the indexing pipeline persist metadata?" \
  --provider extractive

Generierte lokale Durchläufe mit Ollama

Installieren und starten Sie Ollama, dann laden Sie das Standardmodell herunter:

ollama pull qwen2.5-coder:7b

Führen Sie einen zitierten Durchlauf aus:

code-intel ask "Explain the hybrid retrieval control flow"

Verwenden Sie ein anderes lokales Modell oder einen anderen Ollama-Server:

export CODE_INTEL_OLLAMA_MODEL=deepseek-coder-v2:lite
export OLLAMA_BASE_URL=http://127.0.0.1:11434

Wenn Ollama nicht erreichbar ist, kennzeichnet die Anwendung die Antwort deutlich als extractive-fallback und gibt deterministische Quellbelege zurück.

Interaktive CLI

Starten Sie eine kontinuierliche Suchsitzung:

code-intel interactive --dir /absolute/path/to/project

Indexstatistiken anzeigen:

code-intel stats --dir /absolute/path/to/project

Alle Befehle anzeigen:

code-intel --help
code-intel query --help

REST-API

Server starten:

code-intel serve --host 127.0.0.1 --port 8000

Gesundheitscheck:

curl http://127.0.0.1:8000/api/health

Ein Repository indizieren:

curl -X POST http://127.0.0.1:8000/api/index \
  -H 'Content-Type: application/json' \
  -d '{
    "target_dir": "/absolute/path/to/project",
    "force": false
  }'

Hybride Suche ausführen:

curl -X POST http://127.0.0.1:8000/api/search \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "Where is token validation implemented?",
    "repo_path": "/absolute/path/to/project",
    "top_k": 5,
    "mode": "hybrid",
    "rerank": true
  }'

Einen Durchlauf generieren:

curl -X POST http://127.0.0.1:8000/api/synthesize \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "Explain token validation failure paths",
    "repo_path": "/absolute/path/to/project",
    "top_k": 8,
    "provider": "extractive"
  }'

Wichtige Endpunkte:

Methode	Endpunkt	Zweck
`GET`	`/api/health`	Dienst- und Indexstatus
`GET`	`/api/stats`	Dateien, Zeilen, Chunks und Indexmanifest
`GET`	`/api/index/stream`	SSE-Indexierungsfortschritt
`POST`	`/api/index`	Synchrones Repository-Indexing
`POST`	`/api/search`	Dichte, spärliche oder hybride Suche
`POST`	`/api/synthesize`	Zitierte Code-Antwort
`POST`	`/api/synthesize/stream`	Gestreamte zitierte Antwort
`GET`	`/api/graph`	Symbol- und Abhängigkeitsgraph
`POST`	`/api/watcher/toggle`	Inkrementelle Überwachung starten oder stoppen
`GET`	`/api/lsp/inspect`	Definitionen, Referenzen und Hover-Daten
`POST`	`/api/patch/generate`	Vorgeschlagenen Unified-Diff generieren
`POST`	`/api/patch/apply`	Unified-Diff auf das ausgewählte Repository anwenden

Binden Sie an 127.0.0.1, sofern kein Remote-Zugriff beabsichtigt ist. Patch- und Dateiöffnungs-Endpunkte arbeiten auf dem lokalen Dateisystem und sollten nicht ungeschützten Netzwerken ausgesetzt werden.

MCP-Integration

Der MCP-Server ermöglicht es VS Code, Cursor, Claude Code und anderen kompatiblen Coding-Agenten, die indizierte Codebasis zu durchsuchen und exakte Quellbereiche abzurufen. Installieren und indizieren Sie das Projekt zuerst:

git clone https://github.com/saitarrun/Semantic-code-intelligence.git
cd Semantic-code-intelligence
python -m venv .venv
source .venv/bin/activate
pip install -e .
code-intel index --dir /absolute/path/to/your/project

Verwenden Sie den absoluten ausführbaren Pfad, der von which code-intel ausgegeben wird, in den folgenden Beispielen.

VS Code

Erstellen Sie .vscode/mcp.json in dem Projekt, das der Agent durchsuchen soll:

{
  "servers": {
    "semanticCodeIntelligence": {
      "type": "stdio",
      "command": "/absolute/path/to/Semantic-code-intelligence/.venv/bin/code-intel",
      "args": ["mcp", "--dir", "${workspaceFolder}"],
      "cwd": "${workspaceFolder}"
    }
  }
}

Führen Sie MCP: List Servers aus der Befehlspalette aus, starten Sie semanticCodeIntelligence und genehmigen Sie dessen Werkzeuge. Wenn die alte Werkzeugliste zwischengespeichert ist, führen Sie MCP: Reset Cached Tools aus.

Cursor

Erstellen Sie .cursor/mcp.json im Zielprojekt:

{
  "mcpServers": {
    "semantic-code-intelligence": {
      "command": "/absolute/path/to/Semantic-code-intelligence/.venv/bin/code-intel",
      "args": ["mcp", "--dir", "${workspaceFolder}"]
    }
  }
}

Claude Code

Registrieren Sie den lokalen stdio-Server aus dem Projekt, das Sie durchsuchen möchten:

claude mcp add --transport stdio --scope project semantic-code-intelligence -- \
  /absolute/path/to/Semantic-code-intelligence/.venv/bin/code-intel mcp --dir /absolute/path/to/your/project
claude mcp get semantic-code-intelligence

Konfigurieren Sie für einen anderen MCP-kompatiblen Agenten dieselbe ausführbare Datei als lokalen stdio-Server mit den Argumenten mcp --dir /absoluter/pfad/zu/ihrem/projekt. Der Server schreibt nur JSON-RPC-Nachrichten auf stdout, wie von stdio-Clients gefordert.

Verfügbare MCP-Werkzeuge:

code_intel_search: hybride, dichte oder spärliche Abfrage mit exakten Zeilen und Zuverlässigkeitsmetadaten
code_intel_symbol_graph: Abhängigkeits- und Aufrufgraphendaten für ein Repository oder Symbol
code_intel_index: Index aus dem Coding-Agenten erstellen oder aktualisieren
code_intel_read_file: sicher bis zu 400 Zeilen innerhalb des konfigurierten Repositorys lesen

Das Zielprojekt muss vor Suchanfragen indiziert sein. Standardmäßig wird sein Index unter <projekt>/.code_intel_index gespeichert; übergeben Sie --index-dir /pfad/zum/index an den MCP-Befehl, wenn Sie ein separates Indexverzeichnis verwenden. Modell-Downloads bleiben optional: Setzen Sie CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1, wenn das Einbettungs- oder Reranking-Modell nicht bereits zwischengespeichert ist.

LSP- und Dateisystem-Watcher

Starten Sie die stdio-LSP-Brücke:

code-intel lsp --dir /absolute/path/to/project

Starten Sie den inkrementellen Watcher:

code-intel watch --dir /absolute/path/to/project

Der Watcher beobachtet unterstützte Quelldateien und aktualisiert den Indexstatus nach Änderungen. Verwenden Sie Ctrl+C, um einen der beiden Prozesse zu stoppen.

Konfiguration

Umgebungsvariablen:

Variable	Standard	Beschreibung
`CODE_INTEL_ALLOW_MODEL_DOWNLOADS`	`0`	Auf `1` setzen, um Hugging-Face-Modell-Downloads zu erlauben
`CODE_INTEL_OLLAMA_MODEL`	`qwen2.5-coder:7b`	Ollama-Modell für generierte Durchläufe
`OLLAMA_BASE_URL`	`http://127.0.0.1:11434`	Basis-URL der Ollama-API
`CODE_INTEL_CORS_ORIGINS`	Localhost-Ursprünge	Kommagetrennte Browser-Ursprünge, die von der API erlaubt sind
`CODE_INTEL_PIPELINE_CACHE_SIZE`	`4`	Maximale Anzahl von Repository-Pipelines, die von der API zwischengespeichert werden

Programmatische Konfiguration:

from pathlib import Path

from semantic_code_intel.config import CodeIntelConfig
from semantic_code_intel.indexing.engine import HybridIndexer
from semantic_code_intel.retrieval.pipeline import HybridRetrievalPipeline

project = Path("/absolute/path/to/project")
config = CodeIntelConfig(project_root=project)
config.retrieval.dense_top_k = 75
config.retrieval.sparse_top_k = 75
config.retrieval.final_top_k = 8

HybridIndexer(config).index_codebase(project)
response = HybridRetrievalPipeline(config).query(
    "Where is request authentication enforced?",
    top_k=8,
)

for result in response.results:
    print(result.citation, result.chunk.symbol_name, result.score)

print(response.reliability, response.reliability_reasons)

Unterstützte Dateien

Der Standard-Scanner umfasst:

Python
JavaScript und TypeScript
Go
Rust
Java
C und C++
C#
Ruby
PHP
Swift
Kotlin und Scala
Shell-Skripte
SQL
HTML und CSS
JSON, YAML, TOML und Markdown

Gängige generierte Verzeichnisse, virtuelle Umgebungen, Abhängigkeitsordner, Sperrdateien, Binärdateien, minifizierte Assets, .git, .code_intel_index und oss_evaluation sind standardmäßig ausgeschlossen. Siehe ParserConfig in semantic_code_intel/config.py, um Erweiterungen und Ignorier-Muster anzupassen.

Architektur

flowchart LR
    A[Repository] --> B[Scanner and ignore rules]
    B --> C[Python AST or polyglot parser]
    C --> D[Symbol-aware chunks]
    D --> E[Local embedding model]
    E --> F[(FAISS)]
    D --> G[Code-aware tokenizer]
    G --> H[(BM25)]
    D --> I[(SQLite metadata)]

    Q[Query] --> X[Intent expansion]
    X --> F
    X --> H
    F --> R[Reciprocal Rank Fusion]
    H --> R
    R --> J[Cross-encoder reranker]
    J --> K[Exact symbol and path boosts]
    K --> L[Diversity and reliability]
    L --> M[CLI, API, Web, MCP, LSP]

Kernmodule:

Paket	Verantwortung
`parser`	Repository-Scanning und strukturelles Code-Chunking
`indexing`	Einbettungen, FAISS, BM25, SQLite und Überwachung
`retrieval`	Abfrageerweiterung, Fusion, Reranking, Zuverlässigkeit und Zitate
`generation`	Fundierte Prompts, Ollama-Synthese und deterministischer Fallback
`api`	FastAPI-Endpunkte und Browser-Dashboard
`cli`	Befehlszeilenschnittstellen
`graph`	Symbol- und Abhängigkeitsgraphen
`mcp`	Model Context Protocol Server
`lsp`	Language Server Protocol Brücke
`benchmark`	Synthetische Repository-Generierung und Retrieval-Bewertung

Testen

Führen Sie die vollständige Testsuite aus:

uv run pytest -q

Oder mit einer aktivierten Umgebung:

pytest -q

Die Suite deckt Parser, FAISS, BM25, Abfrageerweiterung, Exakt-Treffer-Boosting, Fusion, Zitate, API-Endpunkte, lokales Syntheseverhalten, MCP, LSP, Patchen, Überwachung und Benchmark-Generierung ab.

Benchmarking

Führen Sie einen reproduzierbaren synthetischen Benchmark aus:

code-intel benchmark \
  --workspace ./benchmark_workspace \
  --loc 40000 \
  --queries 30

Der Runner schreibt benchmark_report.json mit:

Datensatz- und Indexgrößen
Indexierungsdurchsatz
Latenz-Perzentile für dichte, spärliche, Reranker- und End-to-End-Abfragen
Trefferquote und mittlerer reziproker Rang
Ausgeführte Abfragedatensätze
Python-, Plattform-, Hardware-, Paket- und Modellmetadaten

Benchmark-Ergebnisse hängen von Hardware, Modell-Cache-Zustand, Repository-Zusammensetzung und Abfragesatz ab. Behandeln Sie historische Zahlen als Messungen, nicht als Garantien.

Fehlerbehebung

Modell ist lokal nicht verfügbar

Führen Sie den fehlgeschlagenen Vorgang einmal mit aktivierten Downloads aus:

CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1 code-intel index /absolute/path/to/project --force
CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1 code-intel query "warm up reranker" --dir /absolute/path/to/project

Index nicht gefunden

Die für die Abfrage verwendeten --dir- und --index-dir-Werte müssen mit denen der Indizierung übereinstimmen.

code-intel stats --dir /absolute/path/to/project

Durchlauf sagt, Ollama sei nicht verfügbar

Überprüfen Sie den lokalen Server und die installierten Modelle:

ollama list
curl http://127.0.0.1:11434/api/tags

Sie können jederzeit den deterministischen Evidenzmodus verwenden:

code-intel ask "your question" --provider extractive

Suchergebnisse sind schwach

Verwenden Sie den genauen Klassen-, Funktions-, Methoden-, Endpunkt- oder Konfigurationsnamen, wenn bekannt.
Bevorzugen Sie den Hybrid-Modus für den normalen Gebrauch.
Erhöhen Sie --top-k, wenn sich die Antwort über mehrere Dateien erstreckt.
Indizieren Sie mit --force erneut, nachdem Sie die Parser- oder Embedding-Konfiguration geändert haben.
Überprüfen Sie das Zuverlässigkeits-Label; eine geringe Zuverlässigkeit bedeutet, dass die Abrufsignale nicht stark übereinstimmen.

Serverport ist bereits belegt

Wählen Sie einen anderen Port:

code-intel serve --host 127.0.0.1 --port 8010

Projektstatus

Dieses Projekt befindet sich in aktiver Entwicklung. Überprüfen Sie generierte Patches, bevor Sie sie anwenden, halten Sie die API für den normalen Gebrauch an localhost gebunden und validieren Sie Benchmark-Behauptungen an Ihren eigenen Ziel-Repositories.

Lizenz

Es wurde noch keine Open-Source-Lizenz hinzugefügt. Der öffentliche Zugriff auf das Repository gewährt für sich genommen keine Erlaubnis, den Code zu kopieren, zu modifizieren oder weiterzuverbreiten.

Available Tools

4 tools

code_intel_indexC

Build or refresh the semantic and lexical indexes for a local repository.

ParametersJSON Schema

Name	Required	Description
`force`	No
`index_dir`	No	Optional index storage directory.
`repo_path`	No	Repository root; defaults to the server --dir.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the full behavioral burden. It doesn't disclose cost/duration (indexing can be slow), whether it blocks, whether it overwrites existing indexes, or what happens on failure. 'Refresh' hints at mutation but no depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single clear sentence with verb and scope front-loaded, zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations, no output schema, and an undocumented 'force' parameter, the description is too thin. It leaves the agent guessing about cost, prerequisites, and the effect of force.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, with index_dir and repo_path already documented in the schema. The 'force' parameter (schema has no description) is undocumented anywhere, and the description doesn't compensate. Baseline 3 given partial coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Build or refresh') and resource ('semantic and lexical indexes for a local repository'). It's distinct from siblings like code_intel_search, though it doesn't explicitly name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to run this versus using existing indexes, nor prerequisites like whether search requires prior indexing. Purely descriptive, no when-to-use direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

code_intel_read_fileB

Read a bounded line range from a source file inside the configured repository.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Repository-relative or absolute file path.
`end_line`	No	Inclusive; at most 400 lines are returned.
`repo_path`	No	Repository root; defaults to the server --dir.
`start_line`	No

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose two useful traits: reads are bounded to a line range and restricted to the configured repository. However, it never states that the operation is read-only/side-effect free, nor how it behaves on a missing file, an out-of-repo absolute path, or a range exceeding the cap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the core action and its two constraints are stated immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter read tool with no annotations and no output schema, the description is adequate but thin: it omits read-only confirmation, error/edge-case behavior, and any hint of the return shape (raw lines vs numbered lines). An agent can call it, but cannot fully predict its behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so the schema already documents path, end_line, and repo_path; only start_line's default relies on the schema's default keyword. The description's 'bounded line range' and 'inside the configured repository' echoes rather than extends the end_line cap and repo_path semantics, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Read a bounded line range from a source file') and scopes it to the configured repository, which is enough for an agent to distinguish it from code_intel_search, code_intel_symbol_graph, and code_intel_index. It stops short of explicitly naming which sibling to use when, but the purpose itself is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as code_intel_search for locating content versus this tool for reading it. An agent must infer the read-content use case purely from the verb.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

code_intel_searchB

Search indexed code with hybrid semantic and lexical retrieval, exact citations, match reasons, and reliability scoring.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No		hybrid
`query`	Yes	Question, behavior, or symbol to find.
`top_k`	No
`rerank`	No
`index_dir`	No	Optional index storage directory.
`repo_path`	No	Repository root; defaults to the server --dir.

TDQS

B3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose some behavioral traits: hybrid semantic/lexical retrieval, exact citations, match reasons, and reliability scoring. However it omits key operational facts such as whether the index must already exist, which repo/index is targeted by default, and whether results are bounded or truncated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; every clause adds information. It is efficient, though the terse packing of output traits without any usage context borders on under-specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter tool with no annotations, no output schema, and half the parameters undocumented, the description is only partially complete. It hints at the return content (citations, match reasons, reliability) but leaves prerequisites and most parameter behavior unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, and the description adds no parameter meaning at all – it does not explain mode options (hybrid/dense/sparse), rerank, top_k limits, index_dir, or repo_path defaults. An agent must infer the effect of switching from hybrid to dense/sparse with no help.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Search indexed code") and names the retrieval techniques (hybrid semantic + lexical) plus output traits, so the agent knows this is a code search tool. It does not name or differentiate itself from siblings like code_intel_symbol_graph or code_intel_read_file, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this over code_intel_symbol_graph (symbol relations) or code_intel_read_file (direct reads), nor any preconditions such as needing the repository indexed first. Usage is only weakly implied by the verb "Search".

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

code_intel_symbol_graphC

Return repository dependency/call-graph data, optionally centered on a symbol.

ParametersJSON Schema

Name	Required	Description
`symbol`	No	Optional function, class, or symbol name.
`index_dir`	No	Optional index storage directory.
`repo_path`	No	Repository root; defaults to the server --dir.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does state that symbol centering is optional and that graph data is returned, but says nothing about output format, graph depth/limits, whether an index must exist first (relevant given index_dir), or cost/size of the result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with no waste, front-loading the resource (dependency/call-graph data) before the optional scoping. Very brief, which is efficient but leaves little room for behavioral detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read tool with no annotations and no output schema, the description is minimally adequate. It should mention whether an index is required beforehand and what the returned graph looks like, since an agent has no other source for that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already documented. The description only adds that symbol centering is optional, which is already reflected in the schema's 'Optional' prefix; baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Return) and resources (dependency/call-graph data) with a scoping qualifier (optionally centered on a symbol). Clear enough to distinguish from siblings like code_intel_search or code_intel_read_file, though it doesn't explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus code_intel_search (symbol lookup) or code_intel_index (index building). The optional symbol scoping is implied but no conditions or prerequisites are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 11, 2026
- First observedcode_intel_index
- First observedcode_intel_read_file
- First observedcode_intel_search
- First observedcode_intel_symbol_graph

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-09-11 14:40 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: indexing, hybrid search, dependency/call-graph retrieval, and bounded file reading. Although search and read_file both return code, their boundaries are clear from descriptions (retrieval vs direct file access).

Naming Consistency4/5

All tools share the consistent code_intel_ prefix, which provides a predictable namespace. However, suffixes mix verb forms (search, index) and noun forms (symbol_graph), so the pattern is mostly but not perfectly consistent.

Tool Count5/5

Four tools is well-scoped for a code intelligence server, covering the essential operations of indexing, searching, graph exploration, and reading without redundancy or bloat.

Completeness4/5

The core lifecycle (index → search → explore graph → read file) is covered, but missing operations such as listing indexed repositories, retrieving symbol definitions, or index management could create minor dead ends for some agent workflows.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ref-tools-mcp AOAuth
tools.ref
Token-efficient search for coding agents over public and private documentation.
Documentation Access Search Coding Agents
221,180
GraphifyOAuth
io.github.Graphify-Labs
Search indexed code, trace dependencies, assess change impact, and recall repository memory.
Code Analysis Knowledge & Memory
1
Maguyva
ai.maguyva
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code Analysis Coding Agents
23
ContextStream MCP ServerOAuth
io.github.contextstream
Project memory, semantic code search, and grounded agent context.
Knowledge & Memory Code Analysis RAG Systems
144

Related MCP Servers

Qurio MCP Server
RAG Systems Search
irahardianto
A
license
Not graded
quality
D
maintenance
Enables AI coding assistants to search and retrieve information from a locally ingested knowledge base using hybrid search, grounded in user-curated documentation.
Updated 8 months ago (2026-02-15 22:06 UTC)
16
MIT
codebase-analyser
akshith120
F
license
Not graded
quality
D
maintenance
Enables AI agents and IDEs to ingest and search code repositories using hybrid retrieval (dense + sparse) with exact line-level citations for precise code analysis.
Updated 3 months ago (2026-07-20 14:32 UTC)
1
-
shelfmark
RAG Systems Knowledge & Memory Search
LucasSantana-Dev
A
license
A
quality
A
maintenance
Enables coding agents to query local notes, decisions, docs, and code with hybrid retrieval (BM25 + embeddings + reranking) and get path:line citations. It provides tools like rag_query for full-corpus search and search_knowledge for project-scoped knowledge recall.
Updated 8 days ago (2026-10-06 23:56 UTC)
2
1
MIT
LexiconLocal
Knowledge & Memory RAG Systems Search
alexeymohr
A
license
A
quality
B
maintenance
Enables coding agents to search a local, offline archive of past sessions and repository Markdown docs using hybrid lexical and semantic retrieval, and read matching records to ground new work in prior knowledge without external calls.
Updated a month ago (2026-09-11 16:18 UTC)
2
MIT