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

语义代码智能

面向软件仓库的本地优先语义搜索与带引用的代码走查。

语义代码智能将仓库解析为符号感知的代码块，使用 FAISS 和 BM25 对这些代码块建立索引，融合两组结果，并使用交叉编码器对最强候选进行重排序。结果包含精确的文件路径和行范围。一切均在本地运行；无需云 API 密钥。

功能

混合语义与词法代码搜索
精确符号、路径和上下文术语加权
基于检索一致性的搜索可靠性标签
Python AST 解析和常见编程语言的结构化解析
精确引用，如 src/auth.py:L42-L67
浏览器仪表盘和 REST API
CLI、MCP 和 LSP 接口
本地 Ollama 驱动的代码走查，并带有确定性证据回退
FAISS、BM25 和 SQLite 索引持久化
增量文件系统监视
符号和依赖图
可复现的索引和检索基准测试

Related MCP server: codebase-analyser

要求

macOS 或 Linux
Python 3.10 或更高版本
Git
约 2–4 GB 的可用磁盘空间，用于 Python 依赖和本地模型缓存
可选：uv 用于更快的环境管理
可选：Ollama 用于生成代码走查

首次索引和重排序操作需要互联网访问以下载 Hugging Face 模型权重。模型缓存后，检索即可离线工作。

从全新机器快速开始

1. 克隆仓库

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

2. 创建环境并安装应用

使用 uv：

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

使用标准 Python 工具：

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

Windows 目前不是测试目标，但等效的激活命令是 .venv\Scripts\activate。

3. 下载检索模型并创建索引

模型下载默认被有意禁用，因此正常应用请求永远不会触发意外的网络流量。在首次索引和查询时显式启用下载：

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

这将准备：

sentence-transformers/all-MiniLM-L6-v2 用于密集嵌入
cross-encoder/ms-marco-MiniLM-L-6-v2 用于重排序

仓库索引存储在 .code_intel_index/ 中。该目录包含 FAISS 索引、BM25 数据和 SQLite 元数据，不应提交。

4. 启动 Web 应用

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

打开 http://127.0.0.1:8000。

仪表盘包括：

语义搜索
代码走查
依赖图
Diff 和 LSP 工具
仓库选择与重新索引控制
各阶段延迟和检索可靠性指示器

索引另一个仓库

索引数据默认存储在目标仓库内：

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

搜索该仓库：

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

当源仓库应保持不动时，使用单独的索引目录：

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

在更改解析器或嵌入行为后强制干净重建：

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

语义搜索

推荐使用混合模式。它结合了自然语言相似性与精确标识符匹配：

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

精确符号搜索：

code-intel query "Where is serve_ui implemented?"

返回更多结果：

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

显示引用而不打印代码：

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

选择单个检索策略进行诊断：

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

当延迟比精度更重要时，禁用交叉编码器重排序：

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

排名如何工作

默认的混合流水线执行以下阶段：

使用确定性的代码域术语扩展常见开发者意图。
检索最多 50 个密集 FAISS 候选。
检索最多 50 个词法 BM25 候选。
使用倒数排名融合融合最多 60 个唯一候选。
使用本地交叉编码器对最多 40 个候选进行重排序。
提升精确符号、路径和上下文术语匹配。
移除重复引用并限制重复的同文件结果。
返回带有证据的可靠性标签。

可靠性不是 LLM 置信度分数。它报告可观察的检索信号，如密集/词法一致性、精确符号匹配、路径重叠和语义相似性。

代码走查

确定性证据模式

此模式不需要 Ollama。它返回检索到的符号、作用域、依赖、源代码块和引用，而不虚构行为：

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

使用 Ollama 生成本地走查

安装并启动 Ollama，然后下载默认模型：

ollama pull qwen2.5-coder:7b

运行带引用的走查：

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

使用另一个本地模型或 Ollama 服务器：

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

如果无法访问 Ollama，应用会明确将响应标记为 extractive-fallback 并返回确定性源证据。

交互式 CLI

启动连续搜索会话：

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

检查索引统计信息：

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

显示所有命令：

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

REST API

启动服务器：

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

健康检查：

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

索引仓库：

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
  }'

运行混合搜索：

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
  }'

生成走查：

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"
  }'

重要端点：

方法	端点	用途
`GET`	`/api/health`	服务和索引状态
`GET`	`/api/stats`	文件、行、块和索引清单
`GET`	`/api/index/stream`	SSE 索引进度
`POST`	`/api/index`	同步仓库索引
`POST`	`/api/search`	密集、稀疏或混合搜索
`POST`	`/api/synthesize`	带引用的代码答案
`POST`	`/api/synthesize/stream`	流式带引用答案
`GET`	`/api/graph`	符号和依赖图
`POST`	`/api/watcher/toggle`	启动或停止增量监视
`GET`	`/api/lsp/inspect`	定义、引用和悬停数据
`POST`	`/api/patch/generate`	生成建议的统一 diff
`POST`	`/api/patch/apply`	将统一 diff 应用到所选仓库

除非有意需要远程访问，否则绑定到 127.0.0.1。补丁和文件打开端点操作本地文件系统，不应暴露给不受信任的网络。

MCP 集成

MCP 服务器允许 VS Code、Cursor、Claude Code 和其他兼容的编码代理搜索已索引的代码库并检索精确的源代码范围。首先安装并索引项目：

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

在下面的示例中使用 which code-intel 打印的绝对可执行路径。

VS Code

在您希望代理搜索的项目中创建 .vscode/mcp.json：

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

从命令面板运行 MCP: List Servers，启动 semanticCodeIntelligence 并批准其工具。如果其旧工具列表被缓存，请运行 MCP: Reset Cached Tools。

Cursor

在目标项目中创建 .cursor/mcp.json：

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

Claude Code

从您希望搜索的项目中注册本地 stdio 服务器：

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

对于其他 MCP 兼容代理，将相同的可执行文件配置为本地 stdio 服务器，参数为 mcp --dir /absolute/path/to/your/project。服务器仅向 stdout 写入 JSON-RPC 消息，符合 stdio 客户端的要求。

可用的 MCP 工具：

code_intel_search：混合、密集或稀疏检索，带有精确行和可靠性元数据
code_intel_symbol_graph：仓库或符号的依赖和调用图数据
code_intel_index：从编码代理构建或刷新索引
code_intel_read_file：安全读取配置仓库内最多 400 行

目标项目必须在搜索请求之前建立索引。默认情况下，其索引存储在 <project>/.code_intel_index；使用单独的索引目录时，请将 --index-dir /path/to/index 传递给 MCP 命令。模型下载保持可选：如果嵌入或重排序模型尚未缓存，请设置 CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1。

LSP 和文件系统监视器

启动 stdio LSP 桥接：

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

启动增量监视器：

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

监视器观察支持的源文件并在更改后刷新索引状态。使用 Ctrl+C 停止任一进程。

配置

环境变量：

变量	默认值	描述
`CODE_INTEL_ALLOW_MODEL_DOWNLOADS`	`0`	设置为 `1` 以允许 Hugging Face 模型下载
`CODE_INTEL_OLLAMA_MODEL`	`qwen2.5-coder:7b`	用于生成走查的 Ollama 模型
`OLLAMA_BASE_URL`	`http://127.0.0.1:11434`	Ollama API 基础 URL
`CODE_INTEL_CORS_ORIGINS`	本地主机来源	API 允许的逗号分隔的浏览器来源
`CODE_INTEL_PIPELINE_CACHE_SIZE`	`4`	API 缓存的最大仓库流水线数量

程序化配置：

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)

支持的文件

默认扫描器包括：

Python
JavaScript 和 TypeScript
Go
Rust
Java
C 和 C++
C#
Ruby
PHP
Swift
Kotlin 和 Scala
Shell 脚本
SQL
HTML 和 CSS
JSON、YAML、TOML 和 Markdown

常见的生成目录、虚拟环境、依赖文件夹、锁文件、二进制文件、压缩资源、.git、.code_intel_index 和 oss_evaluation 默认被排除。请参阅 semantic_code_intel/config.py 中的 ParserConfig 以自定义扩展名和忽略模式。

架构

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]

核心模块：

包	职责
`parser`	仓库扫描和结构化代码分块
`indexing`	嵌入、FAISS、BM25、SQLite 和监视
`retrieval`	查询扩展、融合、重排序、可靠性和引用
`generation`	基于证据的提示、Ollama 合成和确定性回退
`api`	FastAPI 端点和浏览器仪表盘
`cli`	命令行接口
`graph`	符号和依赖图
`mcp`	模型上下文协议服务器
`lsp`	语言服务器协议桥接
`benchmark`	合成仓库生成和检索评估

测试

运行完整测试套件：

uv run pytest -q

或使用激活的环境：

pytest -q

该套件涵盖解析器、FAISS、BM25、查询扩展、精确匹配加权、融合、引用、API 端点、本地合成行为、MCP、LSP、补丁、监视和基准生成。

基准测试

运行可复现的合成基准测试：

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

运行器写入 benchmark_report.json，包含：

数据集和索引大小
索引吞吐量
密集、稀疏、重排序器和端到端延迟百分位数
命中率和平均倒数排名
执行的查询记录
Python、平台、硬件、包和模型元数据

基准测试结果取决于硬件、模型缓存状态、仓库组成和查询集。将历史数据视为测量值，而非保证。

故障排除

模型在本地不可用

启用下载后运行失败的操作一次：

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

未找到索引

用于查询的 --dir 和 --index-dir 值必须与索引时使用的值匹配。

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

走查提示 Ollama 不可用

验证本地服务器和已安装的模型：

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

您始终可以使用确定性证据模式：

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

搜索结果较弱

使用已知的确切类、函数、方法、端点或配置名称。
常规使用优先选择混合模式。
当答案涉及多个文件时，增大 --top-k。
更改解析器或嵌入配置后，使用 --force 重新建立索引。
检查可靠性标签；低可靠性意味着检索信号之间没有强烈一致。

服务器端口已被占用

选择另一个端口：

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

项目状态

该项目正在积极开发中。在应用生成的补丁之前请先审查，常规使用时应将 API 绑定到 localhost，并在您自己的目标仓库上验证基准测试声明。

许可证

尚未添加开源许可证。对仓库的公开访问本身并不授予复制、修改或重新分发代码的权限。

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