Skip to main content
Glama
deenesjakoruzh
saitarrun

semantic-code-intelligence

by saitarrun
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Semantic Code Intelligence

Local-first semantic search and cited code walkthroughs for software repositories.

Semantic Code Intelligence parses a repository into symbol-aware chunks, indexes those chunks with FAISS and BM25, fuses both result sets, and reranks the strongest candidates with a cross-encoder. Results include exact file paths and line ranges. Everything runs locally; no cloud API key is required.

What it provides:

  • Hybrid semantic and lexical code search

  • Exact symbol, path, and contextual-term boosting

  • Search reliability labels based on retrieval agreement

  • Python AST parsing and structural parsing for common programming languages

  • Exact citations such as src/auth.py:L42-L67

  • Browser dashboard and REST API

  • CLI, MCP, and LSP interfaces

  • Local Ollama-powered code walkthroughs with a deterministic evidence fallback

  • FAISS, BM25, and SQLite index persistence

  • Incremental filesystem watching

  • Symbol and dependency graphs

  • Reproducible indexing and retrieval benchmarks

Related MCP server: Qurio MCP Server

Requirements

  • macOS or Linux

  • Python 3.10 or newer

  • Git

  • Approximately 2–4 GB of free disk space for Python dependencies and local model caches

  • Optional: uv for faster environment management

  • Optional: Ollama for generated code walkthroughs

The first indexing and reranking operations require internet access to download Hugging Face model weights. After the models are cached, retrieval works offline.

Quick start from a clean machine

1. Clone the repository

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

2. Create an environment and install the application

Using uv:

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

Using standard Python tooling:

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

Windows is not currently a tested target, but the equivalent activation command is .venv\Scripts\activate.

3. Download the retrieval models and create an index

Model downloads are deliberately disabled by default so normal application requests never trigger unexpected network traffic. Explicitly enable downloads during the first index and query:

export CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1

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

unset CODE_INTEL_ALLOW_MODEL_DOWNLOADS

This prepares:

  • sentence-transformers/all-MiniLM-L6-v2 for dense embeddings

  • cross-encoder/ms-marco-MiniLM-L-6-v2 for reranking

The repository index is stored in .code_intel_index/. The directory contains the FAISS index, BM25 data, and SQLite metadata and should not be committed.

4. Start the web application

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

Open http://127.0.0.1:8000.

The dashboard includes:

  • Semantic Search

  • Code Walkthrough

  • Dependency Map

  • Diff and LSP tools

  • Repository selection and reindexing controls

  • Per-stage latency and retrieval-reliability indicators

Index another repository

Index data is stored inside the target repository by default:

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

Search that repository:

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

Use a separate index directory when the source repository should remain untouched:

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

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

Force a clean rebuild after changing parser or embedding behavior:

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

Semantic search

Hybrid mode is recommended. It combines natural-language similarity with exact identifier matching:

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

Exact symbol search:

code-intel query "Where is serve_ui implemented?"

Return more results:

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

Show citations without printing code:

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

Select an individual retrieval strategy for diagnostics:

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

Disable cross-encoder reranking when lower latency matters more than precision:

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

How ranking works

The default hybrid pipeline performs these stages:

  1. Expand common developer intents with deterministic code-domain terms.

  2. Retrieve up to 50 dense FAISS candidates.

  3. Retrieve up to 50 lexical BM25 candidates.

  4. Fuse up to 60 unique candidates with Reciprocal Rank Fusion.

  5. Rerank up to 40 candidates with a local cross-encoder.

  6. Boost exact symbols, paths, and contextual term matches.

  7. Remove duplicate citations and limit repetitive same-file results.

  8. Return a reliability label with the evidence behind it.

Reliability is not an LLM confidence score. It reports observable retrieval signals such as dense/lexical agreement, exact symbol matches, path overlap, and semantic similarity.

Code walkthroughs

Deterministic evidence mode

This mode does not require Ollama. It returns retrieved symbols, scopes, dependencies, source blocks, and citations without inventing behavior:

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

Generated local walkthroughs with Ollama

Install and start Ollama, then download the default model:

ollama pull qwen2.5-coder:7b

Run a cited walkthrough:

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

Use another local model or Ollama server:

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

If Ollama cannot be reached, the application clearly labels the response extractive-fallback and returns deterministic source evidence.

Interactive CLI

Start a continuous search session:

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

Inspect index statistics:

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

Display all commands:

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

REST API

Start the server:

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

Health check:

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

Index a repository:

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

Run hybrid search:

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

Generate a walkthrough:

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

Important endpoints:

Method

Endpoint

Purpose

GET

/api/health

Service and index status

GET

/api/stats

Files, lines, chunks, and index manifest

GET

/api/index/stream

SSE indexing progress

POST

/api/index

Synchronous repository indexing

POST

/api/search

Dense, sparse, or hybrid search

POST

/api/synthesize

Cited code answer

POST

/api/synthesize/stream

Streaming cited answer

GET

/api/graph

Symbol and dependency graph

POST

/api/watcher/toggle

Start or stop incremental watching

GET

/api/lsp/inspect

Definitions, references, and hover data

POST

/api/patch/generate

Generate a proposed unified diff

POST

/api/patch/apply

Apply a unified diff to the selected repository

Bind to 127.0.0.1 unless remote access is intentionally required. Patch and file-opening endpoints operate on the local filesystem and should not be exposed to untrusted networks.

MCP integration

The MCP server lets VS Code, Cursor, Claude Code, and other compatible coding agents search the indexed codebase and retrieve exact source ranges. Install and index the project first:

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

Use the absolute executable path printed by which code-intel in the examples below.

VS Code

Create .vscode/mcp.json in the project you want the agent to search:

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

Run MCP: List Servers from the Command Palette, start semanticCodeIntelligence, and approve its tools. If its old tool list is cached, run MCP: Reset Cached Tools.

Cursor

Create .cursor/mcp.json in the target project:

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

Claude Code

Register the local stdio server from the project you want to search:

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

For another MCP-compatible agent, configure the same executable as a local stdio server with arguments mcp --dir /absolute/path/to/your/project. The server writes only JSON-RPC messages to stdout, as required by stdio clients.

Available MCP tools:

  • code_intel_search: hybrid, dense, or sparse retrieval with exact lines and reliability metadata

  • code_intel_symbol_graph: dependency and call-graph data for a repository or symbol

  • code_intel_index: build or refresh an index from the coding agent

  • code_intel_read_file: safely read up to 400 lines within the configured repository

The target project must be indexed before search requests. By default, its index is stored at <project>/.code_intel_index; pass --index-dir /path/to/index to the MCP command when using a separate index directory. Model downloads remain opt-in: set CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1 if the embedding or reranker model is not already cached.

LSP and filesystem watcher

Start the stdio LSP bridge:

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

Start the incremental watcher:

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

The watcher observes supported source files and refreshes index state after changes. Use Ctrl+C to stop either process.

Configuration

Environment variables:

Variable

Default

Description

CODE_INTEL_ALLOW_MODEL_DOWNLOADS

0

Set to 1 to permit Hugging Face model downloads

CODE_INTEL_OLLAMA_MODEL

qwen2.5-coder:7b

Ollama model used for generated walkthroughs

OLLAMA_BASE_URL

http://127.0.0.1:11434

Ollama API base URL

CODE_INTEL_CORS_ORIGINS

Localhost origins

Comma-separated browser origins allowed by the API

CODE_INTEL_PIPELINE_CACHE_SIZE

4

Maximum number of repository pipelines cached by the API

Programmatic configuration:

from pathlib import Path

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

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

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

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

print(response.reliability, response.reliability_reasons)

Supported files

The default scanner includes:

  • Python

  • JavaScript and TypeScript

  • Go

  • Rust

  • Java

  • C and C++

  • C#

  • Ruby

  • PHP

  • Swift

  • Kotlin and Scala

  • Shell scripts

  • SQL

  • HTML and CSS

  • JSON, YAML, TOML, and Markdown

Common generated directories, virtual environments, dependency folders, lock files, binaries, minified assets, .git, .code_intel_index, and oss_evaluation are excluded by default. See ParserConfig in semantic_code_intel/config.py to customize extensions and ignore patterns.

Architecture

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

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

Core modules:

Package

Responsibility

parser

Repository scanning and structural code chunking

indexing

Embeddings, FAISS, BM25, SQLite, and watching

retrieval

Query expansion, fusion, reranking, reliability, and citations

generation

Grounded prompts, Ollama synthesis, and deterministic fallback

api

FastAPI endpoints and browser dashboard

cli

Command-line interfaces

graph

Symbol and dependency graphs

mcp

Model Context Protocol server

lsp

Language Server Protocol bridge

benchmark

Synthetic repository generation and retrieval evaluation

Testing

Run the complete test suite:

uv run pytest -q

Or with an activated environment:

pytest -q

The suite covers parsers, FAISS, BM25, query expansion, exact-match boosting, fusion, citations, API endpoints, local synthesis behavior, MCP, LSP, patching, watching, and benchmark generation.

Benchmarking

Run a reproducible synthetic benchmark:

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

The runner writes benchmark_report.json containing:

  • Dataset and index sizes

  • Indexing throughput

  • Dense, sparse, reranker, and end-to-end latency percentiles

  • Hit rate and mean reciprocal rank

  • Executed query records

  • Python, platform, hardware, package, and model metadata

Benchmark results depend on hardware, model cache state, repository composition, and query set. Treat historical figures as measurements, not guarantees.

Troubleshooting

Model is not available locally

Run the failed operation once with downloads enabled:

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

Index not found

The --dir and --index-dir values used for querying must match those used for indexing.

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

Walkthrough says Ollama is unavailable

Verify the local server and installed models:

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

You can always use deterministic evidence mode:

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

Search results are weak

  • Use the exact class, function, method, endpoint, or configuration name when known.

  • Prefer hybrid mode for normal use.

  • Increase --top-k when the answer spans multiple files.

  • Reindex with --force after changing parser or embedding configuration.

  • Check the reliability label; low reliability means the retrieval signals do not strongly agree.

Server port is already in use

Choose another port:

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

Project status

This project is under active development. Review generated patches before applying them, keep the API bound to localhost for normal use, and validate benchmark claims on your own target repositories.

License

No open-source license has been added yet. Public access to the repository does not by itself grant permission to copy, modify, or redistribute the code.

Available Tools

4 tools
code_intel_indexC

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

ParametersJSON Schema
NameRequiredDescriptionDefault
forceNo
index_dirNoOptional index storage directory.
repo_pathNoRepository root; defaults to the server --dir.

TDQS

C2.9/5.0
Behavior2/5

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

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

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

Conciseness5/5

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

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

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

Completeness2/5

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

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

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

Parameters3/5

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

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

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

Purpose4/5

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

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

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

Usage Guidelines2/5

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

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

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

code_intel_read_fileB

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

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesRepository-relative or absolute file path.
end_lineNoInclusive; at most 400 lines are returned.
repo_pathNoRepository root; defaults to the server --dir.
start_lineNo

TDQS

B3.3/5.0
Behavior3/5

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

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

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

Conciseness5/5

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

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

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

Completeness3/5

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

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

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

Parameters3/5

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

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

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

Purpose4/5

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

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

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

Usage Guidelines2/5

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

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

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

code_intel_symbol_graphC

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

ParametersJSON Schema
NameRequiredDescriptionDefault
symbolNoOptional function, class, or symbol name.
index_dirNoOptional index storage directory.
repo_pathNoRepository root; defaults to the server --dir.

TDQS

C2.9/5.0
Behavior2/5

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

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

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

Conciseness4/5

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

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

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

Completeness3/5

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

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

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

Parameters3/5

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

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

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

Purpose4/5

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

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

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

Usage Guidelines2/5

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

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

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

Tool Schema Changelog

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

  1. 4 tool updatesv0.1.0
    • First observedcode_intel_index
    • First observedcode_intel_read_file
    • First observedcode_intel_search
    • First observedcode_intel_symbol_graph
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 4 tools

Disambiguation5/5

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

Naming Consistency4/5

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

Tool Count5/5

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

Completeness4/5

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

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Qurio MCP Server

    irahardianto
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI coding assistants to search and retrieve information from a locally ingested knowledge base using hybrid search, grounded in user-curated documentation.
    17
    MIT

  • codebase-analyser

    akshith120
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents and IDEs to ingest and search code repositories using hybrid retrieval (dense + sparse) with exact line-level citations for precise code analysis.
    1
    -