Skip to main content
Glama
deenesjakoruzh
cvandesande

project-code-intelligence

by cvandesande
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Project Code Intelligence

Repository intelligence and change-safety evidence for coding agents.

Project Code Intelligence (PCI) indexes Git repositories and gives coding agents structured evidence for research, refactoring, maintenance, and security work. Agents can search by concept or identifier, inspect candidate relationships, estimate a change's blast radius, find repeated implementation shapes, and query static-analysis findings before they edit code.

PCI is not an autonomous reviewer and its graph is not a compiler-grade call graph. It narrows discovery and supplies evidence; the agent still verifies important conclusions in source.

What It Helps With

Research and orientation

  • Search exact identifiers, filenames, configuration keys, and known strings.

  • Search by behavior when the relevant names are unknown.

  • Inspect repository languages, file roles, snapshots, parser coverage, and index freshness.

  • Fetch bounded records with paths, line ranges, metadata, and source snippets.

  • Work across several repositories through named collections and repo filters.

Safer changes

  • Find candidate callers, callees, references, tests, and module-level wiring.

  • Check blast-radius evidence before removing, renaming, or changing a symbol.

  • Surface entry-point, orphan, and test-coverage signals.

  • Inject nearby evidence into supported coding agents when definitions are added or removed.

Maintenance and redundancy

  • Find groups of functions that repeat a call-shape motif.

  • Rank redundancy candidates by similarity, estimated abstraction cost, and likely net value.

  • Run a repository audit for stale indexes, duplicate names, redundancy candidates, and static findings.

Security and static analysis

  • Ingest SARIF reports alongside source records.

  • Search normalized findings by tool, rule, level, baseline state, or path.

  • Fetch diagnostics, code flows, and run metadata without making an agent parse raw SARIF artifacts.

Related MCP server: Graft

How It Works

pci index parses repository files into bounded records, extracts metadata and candidate relationships, and stores snapshots in Postgres/pgvector. Semantic embeddings are optional: lexical search and most structural evidence remain available with --no-embed.

pci mcp exposes the index through a local stdio MCP server. Coding agents use its filter-oriented tools to discover likely-relevant code, then read and verify the live source before acting.

The default local architecture is:

  • Postgres/pgvector: Docker or Podman Compose.

  • Linux embedding services: Podman Quadlet units managed by user systemd.

  • Apple Silicon embeddings: a native MLX service.

  • Agent integration: a stdio MCP server, with optional edit-evidence hooks.

Remote Postgres and OpenAI-compatible embedding endpoints are supported when that tradeoff is intentional.

Quick Start

Install the CLI from a checkout:

uv tool install /path/to/project-code-intelligence
export PATH="$HOME/.local/bin:$PATH"

Start the bundled database and the best available local embedding backend:

pci doctor --start
pci doctor

Index a Git repository:

cd /path/to/repo
pci index .

Install MCP configuration for your coding agent:

pci mcp install --target codex

Supported targets include claude, codex, opencode, pi, vscode, copilot, cline, and zed. See docs/MCP_SETUP.md for client-specific setup, project scoping, and credential handling.

For lexical search without embeddings:

pci doctor --start-db
pci index --no-embed .

Core Agent Tools

Tool

Purpose

code_intel_status

Index freshness, scope, record counts, and query capabilities.

list_code_intel_files

File inventory filtered by language, role, path, or generated/test status.

search_code_intel_text

Exact indexed search for symbols, filenames, keys, and known strings.

search_code_intel_semantic

Concept search when identifiers are unknown.

get_code_intel_record

Fetch complete indexed records and metadata.

related_code_intel

Candidate caller, callee, reference, and related-symbol evidence.

blast_radius

Callers, tests, wiring, entry-point signals, and semantic neighbors for a proposed change.

find_redundancy

Repeated call-shape groups ranked by likely refactoring value.

search_static_findings

Filter normalized SARIF findings.

get_static_finding

Fetch diagnostics, code flows, and static-analysis run details.

Run pci audit for a whole-tree evidence report.

Evidence, Not Verdicts

PCI deliberately distinguishes stronger indexed facts from approximate and heuristic evidence.

  • Candidate relationship edges are not type-checked call-graph facts.

  • Blast radius cannot prove that a change is safe.

  • Redundancy scores cannot decide whether two functions should share an abstraction.

  • Static findings retain the limitations of their originating analyzer.

  • An index can be stale after uncommitted or newly committed changes.

  • Semantic retrieval can miss relevant code or return plausible neighbors.

Verify important callers and findings in live source. Use direct file reads for known paths and small bounded questions; PCI is most useful when the location, name, or impact is not yet known.

Installation

Python CLI

Install for the current user with uv:

uv tool install /path/to/project-code-intelligence

For an editable development install:

cd /path/to/project-code-intelligence
python -m venv .venv
. .venv/bin/activate
python -m pip install -e .

Nix

On NixOS or another Linux host with flakes enabled:

nix build
nix run . -- doctor --skip-db --embedding skip
nix develop

Install persistently into the user profile:

nix profile install .#project-code-intelligence

The Nix closure contains the CLI, MCP server, Python dependencies, and bundled Compose and Quadlet assets. Heavy Linux embedding runtimes remain in Podman containers rather than becoming host-native Nix dependencies.

Local database

Start only the bundled Postgres/pgvector database:

pci doctor --start-db

The installed Compose file is materialized into a user cache. To use a custom copy instead:

export PCI_COMPOSE_FILE=/path/to/docker-compose.yml
pci doctor --start-db

Local embedding service

The CLI includes the service templates; there is no separate PCI embedding package. On Linux, install Podman and ensure systemctl --user works, then run:

pci doctor
pci doctor --start-embedding

PCI detects available hardware, materializes only the selected backend under ~/.config/containers/systemd/, reloads user systemd, and starts it. Stale PCI units for other embedding backends are stopped and removed. Images and default models download on first use.

Choose a backend explicitly when desired:

# 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

Available selectors are auto, fastembed, lemonade, rocm, cuda, and apple. PCI rejects a requested backend when its required hardware or runtime is unavailable. apple runs natively rather than through Quadlet.

To start the database and an explicit backend together:

pci doctor --start --embedding-backend rocm

Containerized backends publish an OpenAI-compatible endpoint at http://127.0.0.1:18081/v1/embeddings by default. Run one local backend at a time because they share this endpoint.

Hardware

Backend

Runtime notes

CPU

FastEmbed

Portable fallback; Podman Quadlet.

Apple Silicon

MLX

Native process using the Apple GPU.

AMD Ryzen AI NPU

Lemonade FLM

Experimental; requires supported XDNA hardware, driver, and firmware.

AMD GPU

llama.cpp ROCm

Podman Quadlet with /dev/kfd and /dev/dri.

NVIDIA GPU

llama.cpp CUDA

Requires the NVIDIA driver, Container Toolkit, and Podman CDI support.

Stop embedding services without touching the database:

pci doctor --stop-embedding

Remove generated local services, caches, and the bundled database volume:

pci doctor --clean

--clean is destructive and prompts before removing data.

Remote embeddings

Start only the database, then configure a trusted OpenAI-compatible provider:

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

Remote endpoints receive source-derived text. Enable them only when that is acceptable for the repositories being indexed.

Indexing Repositories

Index one repository:

pci index /path/to/repo

Index several repositories as a workspace:

cd /path/to/workspace
pci index service-api web-ui shared-lib

PCI infers collection and repository names from the paths. MCP clients filter by these logical names rather than absolute filesystem paths. Indexing is incremental: unchanged files are reused when compatible snapshots exist.

SARIF reports found under indexed repository paths are ingested automatically. Reset and rebuild one repository with:

pci index --reset /path/to/repo

Use pci status to inspect indexing runs and pci index --help for parser, embedding, collection, and database options.

MCP and Agent Hooks

Create project-scoped read-only database credentials and print an MCP config:

pci index --init-db --mcp-config codex .

Install or remove MCP configuration without reindexing:

pci mcp install --target codex
pci mcp install --target codex --uninstall

Generated client configuration contains no database password. Credentials are stored under the user's PCI configuration directory with mode 0600. Pi uses a project-local .pi/extensions/ MCP bridge. Cline requires --config-path because its settings file is user-scoped.

Optional hooks can remind an agent to use the index and inject evidence near edits that add or remove definitions:

pci hook install --target codex

Hook support and installation details vary by client. Hooks are an aid, not an enforcement or correctness mechanism. See docs/MCP_SETUP.md and docs/SYSTEM_PROMPT.md.

Privacy and Security

The local default keeps source-derived records and embeddings on the machine. That does not make every artifact safe to publish.

Do not commit or distribute database dumps, restore artifacts, SARIF output, embedding caches, model files, vector indexes, generated data from private repositories, or local MCP credential files. They can contain source snippets, paths, symbols, findings, metadata, and embeddings derived from source.

Collections organize repositories but are not a security boundary. Use separate databases or database users when repositories require stronger isolation. Project-scoped MCP credentials restrict normal access, but they do not replace host and database security.

When PCI Is a Good Fit

PCI tends to help when:

  • the repository or workspace is large or unfamiliar;

  • identifiers are unknown at the start of a task;

  • generated files make broad reads expensive or noisy;

  • a refactor needs caller, test, and wiring evidence;

  • maintenance work needs repeated-pattern discovery;

  • static findings need to be correlated with source;

  • several repositories must be searched through one interface.

It may add little value for a small familiar repository, a known file and line range, or a question answered by one bounded rg or file read. The goal is not to replace standard developer tools; it is to improve the uncertain discovery and change-planning steps around them.

Token and cost reduction can be a useful side effect, but PCI does not promise it. Measure whether the index improves real sessions using docs/EVALUATING_VALUE.md and the session retrospective prompt.

Development

The MCP server uses stdio; Docker Compose is for the local database, not for hosting the MCP process. Run the full development gate with:

nix develop
make check

For ingest, database, or MCP behavior changes, also run:

docker compose up -d pgvector
make integration-smoke

See CONTRIBUTING.md and AGENTS.md for project conventions and publication safeguards.

Documentation

License

MIT. See LICENSE.

Available Tools

8 tools
code_intel_statusC

Check code intelligence snapshot, file, record, edge, and embedding state.

ParametersJSON Schema
NameRequiredDescriptionDefault
collectionNo
repoNo
snapshot_idNo
include_historicalNo

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
NameRequiredDescriptionDefault
idYes

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
NameRequiredDescriptionDefault
finding_idYes
flow_indexNo

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
NameRequiredDescriptionDefault
idYes

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
NameRequiredDescriptionDefault
queryYes
limitNo
collectionNo
repoNo
record_typeNo
languageNo
file_roleNo
content_classNo
confidence_kindNo
source_pathNo
symbolNo
metadata_keyNo
metadata_valueNo
metadata_containsNo
snapshot_idNo
include_historicalNo

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
NameRequiredDescriptionDefault
queryNo
limitNo
collectionNo
repoNo
record_typeNo
languageNo
file_roleNo
content_classNo
confidence_kindNo
source_pathNo
symbolNo
metadata_keyNo
metadata_valueNo
metadata_containsNo
snapshot_idNo
include_historicalNo

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
NameRequiredDescriptionDefault
limitNo
collectionNo
repoNo
toolNo
rule_idNo
levelNo
baseline_stateNo
source_pathNo
snapshot_idNo
include_historicalNo

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. Dates show when Glama detected each change.

  1. 8 tool updatesv0.1.0
    • First observedcode_intel_status
    • First observedget_code_intel_record
    • First observedget_static_code_flow
    • First observedget_static_finding
    • First observedrelated_code_intel
    • First observedsearch_code_intel_semantic
    • First observedsearch_code_intel_text
    • First observedsearch_static_findings
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
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

ActivityMaintained
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Sverklo

    sverklo
    A
    license
    A
    quality
    A
    maintenance
    Local-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
    448
    78
    MIT

  • Graft

    amaar-mc
    A
    license
    B
    quality
    D
    maintenance
    Local-first codebase context engine that parses code into a ranked dependency graph and serves it to AI tools via MCP for deep structural understanding.
    5
    27
    1
    MIT

  • codebase-memory-mcp

    DeusData
    A
    license
    A
    quality
    A
    maintenance
    High-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.
    15
    42,343
    MIT

  • Context Zero Engine

    Classevelabs
    A
    license
    Not graded
    quality
    B
    maintenance
    A 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.
    Apache 2.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cvandesande/project-code-intelligence'

If you have feedback or need assistance with the MCP directory API, please join our Discord server