A
licenseA
qualityA
maintenanceLocal-first code intelligence MCP server with hybrid BM25 + ONNX vector search, symbol-level impact analysis, diff-aware PR review with risk scoring, and persistent memory tied to git state.
36
398 npm
82
MIT
project-code-intelligence
by cvandesande
Project Code Intelligence
面向编码智能体的仓库情报与变更安全证据。
Project Code Intelligence (PCI) 为 Git 仓库建立索引，并为编码智能体提供结构化证据，以支持研究、重构、维护和安全工作。智能体可以在编辑代码之前，按概念或标识符搜索、检查候选关系、评估变更的爆炸半径、发现重复的实现形态，并查询静态分析结果。
PCI 不是自主审查器，其图谱也不是编译器级别的调用图。它缩小发现范围并提供证据；智能体仍需在源码中验证重要结论。
它能帮助什么
研究与定位
搜索精确的标识符、文件名、配置键和已知字符串。
当相关名称未知时，按行为进行搜索。
检查仓库语言、文件角色、快照、解析器覆盖率和索引新鲜度。
获取包含路径、行范围、元数据和源码片段的受限记录。
通过命名集合和仓库过滤器在多个仓库之间开展工作。
更安全的变更
查找候选调用方、被调用方、引用、测试和模块级接线。
在移除、重命名或更改符号之前，检查爆炸半径证据。
呈现入口点、孤儿代码和测试覆盖率信号。
当定义被添加或移除时，向受支持的编码智能体注入附近的证据。
维护与冗余
查找重复同一调用形态模式的函数组。
按相似度、估算的抽象成本和可能的净价值对冗余候选进行排序。
运行仓库审计，以发现过期索引、重复名称、冗余候选和静态发现。
安全与静态分析
将 SARIF 报告与源码记录一起摄取。
按工具、规则、级别、基线状态或路径搜索规范化后的发现。
获取诊断信息、代码流和运行元数据，而无需让智能体解析原始 SARIF 工件。
Related MCP server: Graft
工作原理
pci index 将仓库文件解析为受限记录，提取元数据和候选关系，并将快照存储在 Postgres/pgvector 中。语义嵌入是可选的：使用 --no-embed 时，词法搜索和大多数结构证据仍然可用。
pci mcp 通过本地 stdio MCP 服务器暴露索引。编码智能体使用其面向过滤的工具来发现可能相关的代码，然后在行动之前阅读并验证实时源码。
默认的本地架构是：
Postgres/pgvector： Docker 或 Podman Compose。
Linux 嵌入服务： 由用户 systemd 管理的 Podman Quadlet 单元。
Apple Silicon 嵌入： 原生 MLX 服务。
智能体集成： 一个 stdio MCP 服务器，带有可选的编辑证据钩子。
当这种取舍是刻意选择的结果时，支持远程 Postgres 和 OpenAI 兼容的嵌入端点。
快速开始
从检出目录安装 CLI：
uv tool install /path/to/project-code-intelligence
export PATH="$HOME/.local/bin:$PATH"启动捆绑的数据库和最佳可用的本地嵌入后端：
pci doctor --start
pci doctor为一个 Git 仓库建立索引：
cd /path/to/repo
pci index .为你的编码智能体安装 MCP 配置：
pci mcp install --target codex支持的目标包括 claude、codex、opencode、pi、vscode、copilot、cline 和 zed。有关客户端特定的设置、项目范围界定和凭据处理，请参阅 docs/MCP_SETUP.md。
如需不带嵌入的词法搜索：
pci doctor --start-db
pci index --no-embed .核心智能体工具
工具 | 用途 |
| 索引新鲜度、范围、记录计数和查询能力。 |
| 按语言、角色、路径或生成/测试状态过滤的文件清单。 |
| 对符号、文件名、键和已知字符串进行精确的索引搜索。 |
| 当标识符未知时的概念搜索。 |
| 获取完整的索引记录和元数据。 |
| 候选调用方、被调用方、引用和相关符号的证据。 |
| 针对拟议变更的调用方、测试、接线、入口点信号和语义邻居。 |
| 按可能的重构价值排序的重复调用形态组。 |
| 过滤规范化后的 SARIF 发现。 |
| 获取诊断信息、代码流和静态分析运行详情。 |
运行 pci audit 获取整棵树的证据报告。
证据，而非裁决
PCI 刻意将较强的索引事实与近似的和启发式的证据区分开来。
候选关系边不是经过类型检查的调用图事实。
爆炸半径无法证明变更是否安全。
冗余分数无法决定两个函数是否应该共享抽象。
静态发现保留其原始分析器的局限。
在未提交或新近提交的变更之后，索引可能会过期。
语义检索可能遗漏相关代码，或返回看似合理的邻居。
在实时源码中验证重要的调用方和发现。对于已知路径和小型受限问题，使用直接的文件读取；当位置、名称或影响尚不可知时，PCI 最为有用。
安装
Python CLI
使用 uv 为当前用户安装：
uv tool install /path/to/project-code-intelligence如需可编辑的开发安装：
cd /path/to/project-code-intelligence
python -m venv .venv
. .venv/bin/activate
python -m pip install -e .Nix
在 NixOS 或另一个启用了 flakes 的 Linux 主机上：
nix build
nix run . -- doctor --skip-db --embedding skip
nix develop持久安装到用户 profile 中：
nix profile install .#project-code-intelligenceNix 闭包包含 CLI、MCP 服务器、Python 依赖项以及捆绑的 Compose 和 Quadlet 资产。重量级的 Linux 嵌入运行时仍保留在 Podman 容器中，而不会成为主机原生的 Nix 依赖项。
本地数据库
仅启动捆绑的 Postgres/pgvector 数据库：
pci doctor --start-db安装的 Compose 文件会被实例化到用户缓存中。如需改用自定义副本：
export PCI_COMPOSE_FILE=/path/to/docker-compose.yml
pci doctor --start-db本地嵌入服务
CLI 包含服务模板；没有单独的 PCI 嵌入包。在 Linux 上，安装 Podman 并确保 systemctl --user 可用，然后运行：
pci doctor
pci doctor --start-embeddingPCI 检测可用硬件，仅在 ~/.config/containers/systemd/ 下实例化所选后端，重新加载用户 systemd，并将其启动。其他嵌入后端的过期 PCI 单元会被停止并移除。镜像和默认模型会在首次使用时下载。
如果需要，可显式选择后端：
# AMD GPU
pci doctor --start-embedding --embedding-backend rocm
# NVIDIA GPU
pci doctor --start-embedding --embedding-backend cuda
# Portable CPU fallback
pci doctor --start-embedding --embedding-backend fastembed
# AMD Ryzen AI NPU (experimental)
pci doctor --start-embedding --embedding-backend lemonade可用的选择器有 auto、fastembed、lemonade、rocm、cuda 和 apple。当请求的后端所需的硬件或运行时不可用时，PCI 会拒绝该后端。apple 原生运行，而非通过 Quadlet。
要同时启动数据库和一个显式后端：
pci doctor --start --embedding-backend rocm容器化后端默认在 http://127.0.0.1:18081/v1/embeddings 上发布一个 OpenAI 兼容的端点。由于它们共享此端点，请一次只运行一个本地后端。
硬件 | 后端 | 运行时说明 |
CPU | FastEmbed | 可移植的回退方案；Podman Quadlet。 |
Apple Silicon | MLX | 使用 Apple GPU 的原生进程。 |
AMD Ryzen AI NPU | Lemonade FLM | 实验性；需要受支持的 XDNA 硬件、驱动程序和固件。 |
AMD GPU | llama.cpp ROCm | Podman Quadlet，使用 |
NVIDIA GPU | llama.cpp CUDA | 需要 NVIDIA 驱动程序、Container Toolkit 和 Podman CDI 支持。 |
停止嵌入服务而不触碰数据库：
pci doctor --stop-embedding移除生成的本地服务、缓存和捆绑的数据库卷：
pci doctor --clean--clean 具有破坏性，并会在移除数据前提示确认。
远程嵌入
仅启动数据库，然后配置一个受信任的 OpenAI 兼容提供商：
pci doctor --start-db
export PCI_ALLOW_REMOTE_EMBEDDING=1
export PCI_EMBEDDING_ENDPOINT=https://api.openai.com/v1/embeddings
export PCI_EMBEDDING_ENDPOINT_MODEL=text-embedding-3-small
export OPENAI_API_KEY=...
pci doctor远程端点会接收源自源码的文本。仅当这对被索引的仓库来说可以接受时，才启用它们。
为仓库建立索引
为一个仓库建立索引：
pci index /path/to/repo将多个仓库作为一个工作区建立索引：
cd /path/to/workspace
pci index service-api web-ui shared-libPCI 从路径中推断集合和仓库名称。MCP 客户端按这些逻辑名称（而非绝对文件系统路径）进行过滤。索引是增量的：当存在兼容的快照时，未更改的文件会被复用。
在索引仓库路径下发现的 SARIF 报告会被自动摄取。使用以下命令重置并重建一个仓库：
pci index --reset /path/to/repo使用 pci status 检查索引运行情况，使用 pci index --help 查看解析器、嵌入、集合和数据库选项。
MCP 与智能体钩子
创建项目范围的只读数据库凭据，并打印 MCP 配置：
pci index --init-db --mcp-config codex .在不重新索引的情况下安装或移除 MCP 配置：
pci mcp install --target codex
pci mcp install --target codex --uninstall生成的客户端配置不包含数据库密码。凭据以模式 0600 存储在用户的 PCI 配置目录下。Pi 使用项目本地的 .pi/extensions/ MCP 桥接。Cline 需要 --config-path，因为其设置文件是用户范围的。
可选的钩子可以提醒智能体使用索引，并在添加或移除定义的编辑附近注入证据：
pci hook install --target codex钩子支持和安装细节因客户端而异。钩子是一种辅助手段，而非强制执行或正确性机制。请参阅 docs/MCP_SETUP.md 和 docs/SYSTEM_PROMPT.md。
隐私与安全
本地默认配置将源自源码的记录和嵌入保留在机器上。但这并不意味着每个工件都可以安全发布。
不要提交或分发数据库转储、恢复工件、SARIF 输出、嵌入缓存、模型文件、向量索引、来自私有仓库的生成数据或本地 MCP 凭据文件。它们可能包含派生自源码的源码片段、路径、符号、发现、元数据和嵌入。
集合用于组织仓库，但并非安全边界。当仓库需要更强的隔离时，请使用单独的数据库或数据库用户。项目范围的 MCP 凭据限制了常规访问，但不能替代主机和数据库安全。
何时 PCI 是合适的选择
PCI 在以下情况下往往会有帮助：
仓库或工作区很大或不熟悉；
任务开始时标识符未知；
生成的文件使广泛读取成本高昂或噪声很大；
重构需要调用方、测试和接线证据；
维护工作需要重复模式发现；
静态发现需要与源码相关联；
必须通过一个界面搜索多个仓库。
对于一个小型且熟悉的仓库、已知的文件和行范围，或一个通过一次受限的 rg 或文件读取就能回答的问题，它可能价值不大。目标不是取代标准开发者工具，而是改进围绕它们的不确定发现和变更规划步骤。
降低 token 和成本消耗可以是一个有用的附带效果，但 PCI 并不对此作出承诺。使用 docs/EVALUATING_VALUE.md 和 会话回顾提示词 来衡量索引是否改善了真实会话。
开发
MCP 服务器使用 stdio；Docker Compose 用于本地数据库，而非用于托管 MCP 进程。使用以下命令运行完整的开发门禁：
nix develop
make check对于涉及摄取、数据库或 MCP 行为的变更，还请运行：
docker compose up -d pgvector
make integration-smoke有关项目约定和发布保障措施，请参阅 CONTRIBUTING.md 和 AGENTS.md。
文档
docs/PUBLIC_API.md — CLI、环境、MCP 和 Python 兼容性接口
docs/EVALUATING_VALUE.md — 在真实编码会话中评估 PCI
docs/SYSTEM_PROMPT.md — 使用 PCI 的代理指令
docs/SYSTEM_PROMPT_RATIONALE.md — 提示词设计原理
docs/SESSION_RETROSPECTIVE_PROMPT.md — 会话结束时的评估提示词
.env.example — 环境配置参考
CONTRIBUTING.md — 开发工作流
许可证
MIT。参见 LICENSE。
Available Tools
8 toolscode_intel_statusC
Check code intelligence snapshot, file, record, edge, and embedding state.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| collection | No | ||
| repo | No | ||
| snapshot_id | No | ||
| include_historical | No |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It implies a read-only operation ('Check'), but does not explicitly declare side-effect-free behavior, authentication needs, or any other behavioral traits. This is insufficient for a 4-param tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with a clear verb and list of resources. It is concise but lacks structure; could benefit from additional sentences or bullet points for clarity. Not overly verbose, but not optimally organized.
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?
Given 4 parameters, no output schema, and siblings that cover similar ground, the description is incomplete. It does not explain what the tool returns, how parameters interact, or how it relates to other tools. The agent would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters are described in the schema. The description does not add any parameter-level details, such as how 'collection', 'repo', 'snapshot_id', or 'include_historical' affect the result. This is a critical gap.
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?
Description clearly states the action 'Check' and lists the resources being checked (snapshot, file, record, edge, and embedding state). It distinguishes from sibling tools which focus on individual items or specific aspects, but lacks explicit differentiation.
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 alternatives like get_code_intel_record or search_code_intel_semantic. Usage context is implied but not stated, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_code_intel_recordA
Fetch one code intelligence record by numeric ID, including display content.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read operation ('Fetch') and adds that the result includes display content, but does not disclose other behavioral traits such as authentication requirements, rate limits, or potential side effects. For a simple fetch, this is minimally adequate.
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?
The description is a single sentence with no wasted words. It front-loads the verb and resource, and efficiently conveys the key details. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is reasonably complete. It covers what the tool does and hints at the response content ('including display content'). Some may argue it is adequate enough to use correctly.
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?
The input schema has 0% description coverage, so the description must compensate. It adds 'by numeric ID', which is already inferred from the integer type in the schema. It does not explain the meaning of the ID, valid range, or any other details beyond what the schema provides. This adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'code intelligence record', and the method 'by numeric ID', along with the additional feature 'including display content'. This distinguishes it from sibling search tools and other get tools like get_static_code_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the numeric ID is known, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the sibling tools. It gives clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_static_code_flowC
Fetch ordered SARIF/CodeQL code-flow steps for one static-analysis finding.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| finding_id | Yes | ||
| flow_index | No |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, error handling (e.g., if finding_id does not exist), or any side effects. The description only says 'Fetch' implying a read operation, but lacks further detail.
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?
The description is a single concise sentence, front-loading the key action and resource. However, it could include more context without becoming verbose, such as noting the optional parameter.
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?
Given no output schema or annotations, the description leaves gaps: it does not explain the ordering of steps, the SARIF/CodeQL format, or the role of the optional flow_index. An agent might not know how to properly use flow_index or interpret the response.
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?
With 0% schema description coverage, the description adds minimal meaning beyond the schema. It implies finding_id identifies the finding, but does not explain flow_index or the structure of code-flow steps. The schema already defines types and requirements, so the description adds little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches ordered SARIF/CodeQL code-flow steps for a single static-analysis finding, using a specific verb and resource. It distinguishes from siblings like get_static_finding which fetches a finding itself, and search_static_findings which searches for findings.
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 is provided on when to use this tool versus alternatives, nor when not to use it or what prerequisites are needed. For example, it does not mention that finding_id likely comes from get_static_finding or search_static_findings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_static_findingC
Fetch one SARIF/static-analysis finding with rule, locations, and code-flow steps.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
TDQS
C2.8/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 only states the action and returned fields but does not disclose behavioral traits such as read-only nature, idempotency, authentication requirements, or any side effects. For a fetch tool, read-only hint would be expected but is missing.
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?
The description is a single sentence that is concise and front-loaded with the verb 'Fetch'. However, it lacks important details about parameters and usage, which reduces its efficiency for an agent. Slightly better than average due to its brevity.
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?
Given the tool's simplicity (one parameter, no output schema), the description is incomplete. It does not describe the parameter 'id', does not define what constitutes a 'finding', and does not provide any context for the return value. An agent would need additional information to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one integer parameter 'id' with no description. The schema description coverage is 0%, meaning the description adds no meaning beyond the schema's type definition. It does not explain what the 'id' represents (e.g., finding ID, expected format) or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Fetch' and the resource 'one SARIF/static-analysis finding', and lists included fields (rule, locations, code-flow steps). This distinguishes it from siblings like 'get_static_code_flow' (which likely returns only code flow) and 'search_static_findings' (which lists findings).
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?
The description does not provide any guidance on when to use this tool vs. alternatives like 'search_static_findings' or 'get_static_code_flow'. The use case (fetch a specific finding by ID) is implied but not explicitly stated, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_code_intel_semanticC
Embed a query with the configured embedding backend and search embedded code intelligence records.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| collection | No | ||
| repo | No | ||
| record_type | No | ||
| language | No | ||
| file_role | No | ||
| content_class | No | ||
| confidence_kind | No | ||
| source_path | No | ||
| symbol | No | ||
| metadata_key | No | ||
| metadata_value | No | ||
| metadata_contains | No | ||
| snapshot_id | No | ||
| include_historical | No |
TDQS
C2.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits beyond the basic operation. There's no mention of safety, permissions, side effects, or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It lacks important details that would help the agent, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It fails to convey search behavior, filtering logic, or return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 16 parameters, the description adds no meaning to any parameter. No enum values or additional context are provided.
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 clearly states the action 'embed a query' and 'search embedded code intelligence records', indicating it performs semantic search. However, it could be more precise about what 'embedded' means and how it differs from text search.
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 vs siblings like search_code_intel_text or search_static_findings. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_code_intel_textC
Search or list code intelligence records with optional PostgreSQL full-text search and exact filters.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| limit | No | ||
| collection | No | ||
| repo | No | ||
| record_type | No | ||
| language | No | ||
| file_role | No | ||
| content_class | No | ||
| confidence_kind | No | ||
| source_path | No | ||
| symbol | No | ||
| metadata_key | No | ||
| metadata_value | No | ||
| metadata_contains | No | ||
| snapshot_id | No | ||
| include_historical | No |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose whether the operation is read-only, any side effects, rate limits, or pagination behavior. The description is minimal and does not provide behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with front-loaded purpose, but lacks structure such as breaking down search vs list modes. It is concise but could be more organized without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain pagination limits, return format, or how parameters interact, leaving the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 16 parameters. The description adds no meaning beyond the schema parameter names, failing to explain how 'query', 'collection', 'metadata_contains', etc., function together. The baseline for 0% coverage is low, and the description does not compensate.
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 clearly states the tool searches or lists code intelligence records, mentioning PostgreSQL full-text search and exact filters. It distinguishes from sibling 'search_code_intel_semantic' by implying a text-based approach, but lacks explicit differentiation.
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 alternatives like semantic search or static findings search. There is no mention of prerequisites, excluded cases, or context for full-text vs exact filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_static_findingsC
Search SARIF/static-analysis findings with exact filters.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| collection | No | ||
| repo | No | ||
| tool | No | ||
| rule_id | No | ||
| level | No | ||
| baseline_state | No | ||
| source_path | No | ||
| snapshot_id | No | ||
| include_historical | No |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a terse description, important behavioral details are missing, such as how filters combine (AND/OR), pagination behavior, performance considerations, or what happens when no filters are applied. The agent is left to infer behavior from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It could be improved by adding a second sentence to mention key behavioral aspects without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is severely incomplete. An agent cannot effectively use this tool without guessing parameter semantics and expected behavior.
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 0%, meaning the description must explain parameter meanings, but it does not mention any parameters beyond 'exact filters'. The agent has no information on how parameters like 'limit', 'collection', or 'include_historical' affect the search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for SARIF/static-analysis findings with exact filters, which distinguishes it from sibling tools like search_code_intel_semantic and search_code_intel_text that likely perform semantic or text-based searches.
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 is provided on when to use this tool versus its siblings, nor are there any exclusions or prerequisites mentioned. The description lacks context for appropriate use.
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.
8 tool updates
v0.1.0- First observed
code_intel_status - First observed
get_code_intel_record - First observed
get_static_code_flow - First observed
get_static_finding - First observed
related_code_intel - First observed
search_code_intel_semantic - First observed
search_code_intel_text - First observed
search_static_findings
TDQS
B3/5.0
Scored across 8 tools
Disambiguation4/5
Tools are mostly distinct in purpose: status overview, individual retrieval of records/findings/flow, semantic/text search, and graph relationships. However, 'get_code_intel_record' and 'related_code_intel' both involve records, but descriptions clarify the difference.
Naming Consistency3/5
Naming mixes patterns: 'get_code_intel_record' vs 'get_static_finding' (different ordering), 'search_code_intel_semantic' vs 'search_static_findings' (inconsistent prefix). 'code_intel_status' and 'related_code_intel' lack verb prefixes, breaking the verb_noun pattern.
Tool Count5/5
With 8 tools, the count is well-scoped for a code intelligence server covering status, retrieval, search, and relationships. Neither sparse nor bloated.
Completeness4/5
Covers core needs: status, record/finding retrieval, two search modes, and graph edges. Missing explicit listing endpoints, but search can substitute. No clear dead ends for a read-only intelligence server.
Maintenance
ActivitySlowing
ResponsivenessUnresponsive
Related MCP Connectors
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Enterprise code intelligence for M&A, security audits, and tech debt. Hosted server with 200k free.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Related MCP Servers
- AlicenseBqualityDmaintenanceLocal-first codebase context engine that parses code into a ranked dependency graph and serves it to AI tools via MCP for deep structural understanding.59 npm1MIT
- AlicenseBqualityAmaintenanceHigh-performance code intelligence MCP server. Indexes codebases into a persistent knowledge graph — average repo in milliseconds. 159 languages, sub-ms queries, 99% fewer tokens. Single static binary, zero dependencies.81746,667MIT
- AlicenseNot gradedqualityAmaintenanceA local code-intelligence engine for AI agents that indexes repositories into a PostgreSQL-backed code graph and serves structured, token-budgeted context over MCP and HTTP, enabling targeted queries on symbols, dependencies, contracts, and impact analysis.7Apache 2.0