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
Inteligencia de repositorios y evidencia de seguridad de cambios para agentes de codificación.
Project Code Intelligence (PCI) indexa repositorios Git y proporciona a los agentes de codificación evidencia estructurada para tareas de investigación, refactorización, mantenimiento y seguridad. Los agentes pueden buscar por concepto o identificador, inspeccionar relaciones candidatas, estimar el radio de impacto de un cambio, encontrar formas de implementación repetidas y consultar hallazgos de análisis estático antes de editar código.
PCI no es un revisor autónomo y su grafo no es un grafo de llamadas de nivel compilador. Acota el descubrimiento y aporta evidencia; el agente sigue verificando las conclusiones importantes en el código fuente.
Con Qué Ayuda
Investigación y orientación
Buscar identificadores exactos, nombres de archivo, claves de configuración y cadenas conocidas.
Buscar por comportamiento cuando los nombres relevantes son desconocidos.
Inspeccionar lenguajes del repositorio, roles de archivos, instantáneas, cobertura del analizador y frescura del índice.
Obtener registros acotados con rutas, rangos de líneas, metadatos y fragmentos de código fuente.
Trabajar en varios repositorios mediante colecciones con nombre y filtros de repositorio.
Cambios más seguros
Encontrar llamadores, llamados, referencias, pruebas y cableado a nivel de módulo candidatos.
Comprobar la evidencia de radio de impacto antes de eliminar, renombrar o cambiar un símbolo.
Exponer señales de puntos de entrada, código huérfano y cobertura de pruebas.
Inyectar evidencia cercana en agentes de codificación compatibles cuando se añaden o eliminan definiciones.
Mantenimiento y redundancia
Encontrar grupos de funciones que repiten un motivo de forma de llamada.
Clasificar candidatos a redundancia por similitud, coste estimado de abstracción y valor neto probable.
Ejecutar una auditoría del repositorio para índices obsoletos, nombres duplicados, candidatos a redundancia y hallazgos estáticos.
Seguridad y análisis estático
Ingerir informes SARIF junto con los registros de código fuente.
Buscar hallazgos normalizados por herramienta, regla, nivel, estado de línea base o ruta.
Obtener diagnósticos, flujos de código y metadatos de ejecución sin que un agente tenga que analizar artefactos SARIF sin procesar.
Related MCP server: Graft
Cómo Funciona
pci index analiza los archivos del repositorio en registros acotados, extrae metadatos y relaciones candidatas, y almacena instantáneas en Postgres/pgvector. Los embeddings semánticos son opcionales: la búsqueda léxica y la mayor parte de la evidencia estructural siguen disponibles con --no-embed.
pci mcp expone el índice a través de un servidor MCP local por stdio. Los agentes de codificación usan sus herramientas orientadas a filtros para descubrir código probablemente relevante y luego leen y verifican el código fuente real antes de actuar.
La arquitectura local predeterminada es:
Postgres/pgvector: Docker o Podman Compose.
Servicios de embeddings en Linux: unidades Podman Quadlet gestionadas por systemd de usuario.
Embeddings en Apple Silicon: un servicio MLX nativo.
Integración con agentes: un servidor MCP por stdio, con ganchos opcionales de evidencia de edición.
Se admiten endpoints remotos de Postgres y de embeddings compatibles con OpenAI cuando esa compensación es intencionada.
Inicio Rápido
Instala la CLI desde un clon del repositorio:
uv tool install /path/to/project-code-intelligence
export PATH="$HOME/.local/bin:$PATH"Inicia la base de datos incluida y el backend de embeddings local más adecuado disponible:
pci doctor --start
pci doctorIndexa un repositorio Git:
cd /path/to/repo
pci index .Instala la configuración de MCP para tu agente de codificación:
pci mcp install --target codexLos destinos compatibles incluyen claude, codex, opencode, pi, vscode, copilot, cline y zed. Consulta docs/MCP_SETUP.md para la configuración específica de cada cliente, el ámbito de proyecto y el manejo de credenciales.
Para búsqueda léxica sin embeddings:
pci doctor --start-db
pci index --no-embed .Herramientas Principales del Agente
Tool | Propósito |
| Frescura del índice, ámbito, recuentos de registros y capacidades de consulta. |
| Inventario de archivos filtrado por lenguaje, rol, ruta o estado de generado/prueba. |
| Búsqueda indexada exacta de símbolos, nombres de archivo, claves y cadenas conocidas. |
| Búsqueda por concepto cuando los identificadores son desconocidos. |
| Obtener registros indexados completos y metadatos. |
| Evidencia de llamadores, llamados, referencias y símbolos relacionados candidatos. |
| Llamadores, pruebas, cableado, señales de puntos de entrada y vecinos semánticos para un cambio propuesto. |
| Grupos de formas de llamada repetidas clasificados por su probable valor de refactorización. |
| Filtrar hallazgos SARIF normalizados. |
| Obtener diagnósticos, flujos de código y detalles de ejecuciones de análisis estático. |
Ejecuta pci audit para obtener un informe de evidencia de todo el árbol.
Evidencia, No Veredictos
PCI distingue deliberadamente los hechos indexados más sólidos de la evidencia aproximada y heurística.
Las aristas de relaciones candidatas no son hechos de grafo de llamadas verificados por tipos.
El radio de impacto no puede probar que un cambio sea seguro.
Las puntuaciones de redundancia no pueden decidir si dos funciones deberían compartir una abstracción.
Los hallazgos estáticos conservan las limitaciones de su analizador de origen.
Un índice puede estar desactualizado después de cambios sin confirmar o recién confirmados.
La recuperación semántica puede omitir código relevante o devolver vecinos plausibles.
Verifica los llamadores y hallazgos importantes en el código fuente real. Usa lecturas directas de archivos para rutas conocidas y preguntas pequeñas y acotadas; PCI es más útil cuando la ubicación, el nombre o el impacto aún no se conocen.
Instalación
CLI de Python
Instala para el usuario actual con uv:
uv tool install /path/to/project-code-intelligencePara una instalación de desarrollo editable:
cd /path/to/project-code-intelligence
python -m venv .venv
. .venv/bin/activate
python -m pip install -e .Nix
En NixOS u otro host Linux con flakes habilitados:
nix build
nix run . -- doctor --skip-db --embedding skip
nix developInstala de forma persistente en el perfil de usuario:
nix profile install .#project-code-intelligenceEl cierre de Nix contiene la CLI, el servidor MCP, las dependencias de Python y los recursos Compose y Quadlet incluidos. Los tiempos de ejecución pesados de embeddings en Linux permanecen en contenedores Podman en lugar de convertirse en dependencias Nix nativas del host.
Base de datos local
Inicia solo la base de datos Postgres/pgvector incluida:
pci doctor --start-dbEl archivo Compose instalado se materializa en la caché del usuario. Para usar una copia personalizada en su lugar:
export PCI_COMPOSE_FILE=/path/to/docker-compose.yml
pci doctor --start-dbServicio de embeddings local
La CLI incluye las plantillas de servicio; no hay un paquete de embeddings PCI separado. En Linux, instala Podman y asegúrate de que systemctl --user funcione; luego ejecuta:
pci doctor
pci doctor --start-embeddingPCI detecta el hardware disponible, materializa solo el backend seleccionado en ~/.config/containers/systemd/, recarga el systemd de usuario y lo inicia. Las unidades PCI obsoletas de otros backends de embeddings se detienen y eliminan. Las imágenes y los modelos predeterminados se descargan en el primer uso.
Elige un backend explícitamente cuando lo desees:
# 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 lemonadeLos selectores disponibles son auto, fastembed, lemonade, rocm, cuda y apple. PCI rechaza un backend solicitado cuando su hardware o tiempo de ejecución requerido no está disponible. apple se ejecuta de forma nativa en lugar de mediante Quadlet.
Para iniciar la base de datos y un backend explícito juntos:
pci doctor --start --embedding-backend rocmLos backends contenedorizados publican un endpoint compatible con OpenAI en http://127.0.0.1:18081/v1/embeddings de forma predeterminada. Ejecuta un solo backend local a la vez porque comparten este endpoint.
Hardware | Backend | Notas de tiempo de ejecución |
CPU | FastEmbed | Respaldo portátil; Podman Quadlet. |
Apple Silicon | MLX | Proceso nativo que usa la GPU de Apple. |
AMD Ryzen AI NPU | Lemonade FLM | Experimental; requiere hardware XDNA compatible, controlador y firmware. |
AMD GPU | llama.cpp ROCm | Podman Quadlet con |
NVIDIA GPU | llama.cpp CUDA | Requiere el controlador NVIDIA, Container Toolkit y soporte CDI de Podman. |
Detén los servicios de embeddings sin tocar la base de datos:
pci doctor --stop-embeddingElimina los servicios locales generados, las cachés y el volumen de base de datos incluido:
pci doctor --clean--clean es destructivo y solicita confirmación antes de eliminar datos.
Embeddings remotos
Inicia solo la base de datos y luego configura un proveedor compatible con OpenAI de confianza:
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 doctorLos endpoints remotos reciben texto derivado del código fuente. Habilítalos solo cuando eso sea aceptable para los repositorios que se están indexando.
Indexación de Repositorios
Indexa un repositorio:
pci index /path/to/repoIndexa varios repositorios como un espacio de trabajo:
cd /path/to/workspace
pci index service-api web-ui shared-libPCI infiere los nombres de colección y repositorio a partir de las rutas. Los clientes MCP filtran por estos nombres lógicos en lugar de por rutas absolutas del sistema de archivos. La indexación es incremental: los archivos sin cambios se reutilizan cuando existen instantáneas compatibles.
Los informes SARIF encontrados en las rutas de repositorio indexadas se ingieren automáticamente. Restablece y reconstruye un repositorio con:
pci index --reset /path/to/repoUsa pci status para inspeccionar las ejecuciones de indexación y pci index --help para las opciones de analizador, embeddings, colección y base de datos.
MCP y Ganchos de Agente
Crea credenciales de base de datos de solo lectura con ámbito de proyecto y muestra una configuración MCP:
pci index --init-db --mcp-config codex .Instala o elimina la configuración de MCP sin reindexar:
pci mcp install --target codex
pci mcp install --target codex --uninstallLa configuración de cliente generada no contiene contraseña de base de datos. Las credenciales se almacenan en el directorio de configuración de PCI del usuario con modo 0600. Pi usa un puente MCP local al proyecto en .pi/extensions/. Cline requiere --config-path porque su archivo de configuración tiene ámbito de usuario.
Los ganchos opcionales pueden recordar a un agente que use el índice e inyectar evidencia cerca de las ediciones que añaden o eliminan definiciones:
pci hook install --target codexEl soporte de ganchos y los detalles de instalación varían según el cliente. Los ganchos son una ayuda, no un mecanismo de aplicación forzosa o de corrección. Consulta docs/MCP_SETUP.md y docs/SYSTEM_PROMPT.md.
Privacidad y Seguridad
La opción local predeterminada mantiene los registros y embeddings derivados del código fuente en la máquina. Eso no hace que todos los artefactos sean seguros de publicar.
No confirmes ni distribuyas volcados de base de datos, artefactos de restauración, salida SARIF, cachés de embeddings, archivos de modelo, índices vectoriales, datos generados a partir de repositorios privados ni archivos locales de credenciales MCP. Pueden contener fragmentos de código fuente, rutas, símbolos, hallazgos, metadatos y embeddings derivados del código fuente.
Las colecciones organizan repositorios, pero no son una frontera de seguridad. Usa bases de datos o usuarios de base de datos separados cuando los repositorios requieran un aislamiento más estricto. Las credenciales MCP con ámbito de proyecto restringen el acceso normal, pero no sustituyen la seguridad del host y de la base de datos.
Cuándo PCI Es Adecuado
PCI tiende a ser útil cuando:
el repositorio o espacio de trabajo es grande o desconocido;
los identificadores son desconocidos al comienzo de una tarea;
los archivos generados hacen que las lecturas amplias sean costosas o ruidosas;
una refactorización necesita evidencia de llamadores, pruebas y cableado;
el trabajo de mantenimiento necesita descubrimiento de patrones repetidos;
los hallazgos estáticos deben correlacionarse con el código fuente;
varios repositorios deben buscarse a través de una única interfaz.
Puede aportar poco valor para un repositorio pequeño y conocido, un archivo y rango de líneas conocidos, o una pregunta respondida con una búsqueda rg acotada o una lectura de archivo. El objetivo no es reemplazar las herramientas estándar de desarrollo; es mejorar los pasos inciertos de descubrimiento y planificación de cambios en torno a ellas.
La reducción de tokens y costes puede ser un efecto secundario útil, pero PCI no lo promete. Mide si el índice mejora sesiones reales usando docs/EVALUATING_VALUE.md y el prompt de retrospectiva de sesión.
Desarrollo
El servidor MCP usa stdio; Docker Compose es para la base de datos local, no para alojar el proceso MCP. Ejecuta la compuerta de desarrollo completa con:
nix develop
make checkPara cambios de ingesta, base de datos o comportamiento de MCP, ejecuta también:
docker compose up -d pgvector
make integration-smokeConsulta CONTRIBUTING.md y AGENTS.md para conocer las convenciones del proyecto y las salvaguardas de publicación.
Documentación
docs/MCP_SETUP.md — clientes MCP, alcances, credenciales y modelo de seguridad
docs/PUBLIC_API.md — superficies de compatibilidad de CLI, entorno, MCP y Python
docs/EVALUATING_VALUE.md — evaluación de PCI en sesiones de codificación reales
docs/SYSTEM_PROMPT.md — instrucciones del agente para usar PCI
docs/SYSTEM_PROMPT_RATIONALE.md — justificación del diseño del prompt
docs/SESSION_RETROSPECTIVE_PROMPT.md — prompt de evaluación de fin de sesión
.env.example — referencia de configuración del entorno
CONTRIBUTING.md — flujo de trabajo de desarrollo
Licencia
MIT. Ver 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