Skip to main content
Glama

knot

License: MIT Rust knot MCP server

knot is a high-performance codebase indexer that extracts structural and semantic information from source code, enabling AI agents to understand, analyze, and navigate large code repositories. Currently supports Java, Kotlin (v0.7.4+), TypeScript, JavaScript/Node.js, Rust (v0.8.x), Python (v0.9.3), Groovy (v0.10.3), C/C++ (v1.0.0), HTML, and CSS/SCSS, plus Build Systems (Maven pom.xml, Gradle build.gradle, Jenkins pipeline, Cargo.toml — v1.2.0), Configuration Files (YAML, JSON, .properties — v1.2.0), and Kubernetes + Helm (v1.2.0) with full cross-language linking.

The indexer automatically builds:

  • Vector Search Database (Qdrant) — semantic understanding via embeddings

  • Graph Database (Neo4j) — architectural relationships via call graphs

This dual-database approach powers both:

  • MCP (Model Context Protocol) Server — Exposes three tools to any LLM client (Claude, Gemini, ChatGPT, Cursor, etc.)

  • CLI Tool (v0.10.1) — Standalone knot command for terminal and scripting environments


✨ Key Features

🔍 Code Intelligence Tools

  • search_hybrid_context: Semantic + structural search. Find code by meaning, class name, method signature, docstrings, or comments. Returns full context including dependencies.

  • find_callers: Reverse dependency lookup. Identify dead code, perform impact analysis, or understand the full call chain of any function/method. When multiple entities share the same name (e.g., find_nearest_entity_by_line in different files), results are automatically grouped by target showing which specific entity each caller references.

  • explore_file: File anatomy inspection. Quickly see all classes, interfaces, methods, and functions in a file with signatures and documentation.

🏗️ Multi-Language Support

  • Java: Full AST extraction with package awareness

  • Kotlin (v0.7.4+): Complete support for Kotlin codebases with classes, interfaces, objects, companion objects, functions, methods, and properties. Fully compatible with tree-sitter-kotlin-ng grammar.

  • TypeScript/TSX/CTS: Complete support for modern JavaScript/TypeScript codebases, including CommonJS TypeScript files

  • JavaScript/Node.js (v0.7.4+): Vanilla JS, Node.js, and module systems (.js, .mjs, .cjs, .jsx)

  • Hybrid Web Ecosystem (v0.6.5): Cross-language linking between JavaScript, HTML, and CSS for full-stack SPA analysis

  • HTML (v0.6.3+): Custom elements (Web Components, Angular), id and class attribute indexing for cross-language CSS search

  • JSX/TSX Attributes (v0.6.3+): Extracts id and className from React components for unified HTML/CSS discovery

  • CSS/SCSS (v0.6.4+): Stylesheet indexing with class/ID selector extraction and variable tracking (CSS/SCSS variables, mixins, functions)

  • Rust (v0.8.11): Struct, enum, union, trait, function, method, module extraction with trait implementation tracking (IMPLEMENTS relationships) and macro invocation references. NEW in v0.8.6: Type alias, constant, static, and macro definition extraction with full docstring and signature support. NEW in v0.8.7: Enhanced type reference detection inside macros (vec![], println!(), assert!(), etc.) with intelligent string literal filtering and comprehensive edge case handling. NEW in v0.8.11: O(N) nested macro traversal optimization for large Rust codebases with deeply nested token_tree nodes.

  • Python (v0.9.3): Full Python extraction with class, function, method support, constants, module-level imports, ValueReference tracking for keyword arguments, class inheritance (EXTENDS), decorator extraction (@property, @staticmethod, @route(...), @dataclass), generic type hints (List[str], Optional[Dict], *args/**kwargs), Py2/Py3 exception syntax compatibility, and self.method() resolution with inherited method walking. Captures class_definition, function_definition (including async via optional async modifier), lambda assignments, and distinguishes methods from functions via parent context detection.

  • Groovy (v0.10.3): Full Groovy language support via hybrid tree-sitter + ad-hoc lexical parser. Extracts classes, interfaces, traits, enums, typed/def/quoted methods (incl. Spock specs), constructors, closures, script-level variables, fields/properties with visibility modifiers, nested classes, and decorators. Tracks package FQN and enclosing class relationships. NEW in v0.10.3: Multi-line signatures (closure default params), assignment-vs-declaration disambiguation, innermost assignment for nested closures, UUID collision fix for duplicate method names, find_callers accurately tracks private methods including those in anonymous new AnAction closures.

  • Build Systems (v0.10.0): Maven pom.xml (dependencies + plugins via roxmltree), Gradle build.gradle (deps + plugins + tasks), and Jenkinsfile pipeline (stages + steps) extraction.

  • Cargo.toml (v1.2.0): Rust package manager support with package metadata, features, workspace members, and multi-format dependency parsing (simple, table, git, path).

  • Configuration Files (v1.2.0): YAML (.yml/.yaml), JSON (.json), and Java Properties (.properties) with leaf-key granularity. Special handling for package.json (npm dependencies as BuildDependency, scripts as ConfigProperty).

  • Kubernetes + Helm (v1.2.0): K8s manifest parsing (Deployment, Service, ConfigMap, Secret, Ingress, Namespace) with label/annotation tracking and cross-resource references. Helm chart indexing (Chart.yaml metadata, values.yaml key-value pairs, template variable extraction via {{ .Values.X }}).

  • C/C++ (v1.0.0): Complete C/C++ support with namespace-aware FQN resolution (Engine::MyClass::start), class/struct extraction, function/method tracking, macro definition and usage detection (uppercase identifier heuristic), type reference tracking (declarations, new expressions), and full call graph analysis. Supports .c, .h, .cpp, .hpp, .cc, .cxx, .hh, .hxx extensions via tree-sitter-c and tree-sitter-cpp parsers. Includes intelligent auto-detection for .h headers to parse them correctly as C or C++ based on their contents.

📚 Rich Comment Extraction

  • Captures docstrings (JavaDoc, JSDoc) preceding declarations

  • Extracts inline comments within method/function bodies

  • Respects nesting boundaries (class comments don't capture method comments)

  • Intelligently aggregates comment blocks

📊 Dual-Database Architecture

  • Qdrant: Vector search for semantic code understanding

  • Neo4j: Graph relationships for structural navigation

🚀 High Performance

  • Parallel Streaming Pipeline: Overlaps CPU-bound embedding with I/O-bound ingestion via MPSC channels (v0.5.0+)

  • Incremental Indexing: Uses SHA-256 hashes to skip unchanged files

  • Real-time Watch Mode: Automatically re-indexes changed files in seconds via --watch

  • CPU Parallelism: AST extraction via Rayon

  • Scalable: Configurable batch processing and constant memory footprint (~2GB) regardless of repository size

  • Performance Benchmarking (v1.1.0+): Three-level validation framework

    • Unit benchmarks: Criterion-based benchmarks for parse, embed, and graph write throughput (benches/)

    • E2E benchmarks: Full pipeline metrics capture with per-stage timing (tests/benchmark_e2e.sh)

    • CI regression tracking: Automated baseline comparison against tolerance thresholds (scripts/compare_perf_metrics.sh)


Related MCP server: MCP-RAG

🛠️ Installation

Prerequisites

Component

Version

Notes

Docker

20.10+

For running Qdrant and Neo4j

qdrant

1.x

Vector database (docker)

neo4j

5.x

Graph database (docker)

Option A: Pre-compiled Binaries (macOS & Modern Linux)

Go to the Releases page and download the native executable for your platform.

Install knot binaries (CLI, MCP server, and indexer):

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/raultov/knot/releases/latest/download/knot-installer.sh | sh

Download agent-skills guides separately (optional):

curl -sO https://raw.githubusercontent.com/raultov/knot/master/.knot-agent.md && curl -fsSL https://raw.githubusercontent.com/raultov/knot/master/.knot-agent-skills.tar.gz | tar -xz

The first command installs the knot binary to your PATH. The second (optional) downloads the agent skill index (.knot-agent.md) and extracts comprehensive guides for using knot CLI with AI agents and code analysis tools.

Linux Requirements:

  • Full install (knot-indexer + CLI + MCP): glibc 2.38+

    • Ubuntu 24.04 LTS or later

    • Debian 13 (Trixie) or later

    • Fedora 39+ / RHEL 10+

    • Arch Linux (rolling release)

  • Lightweight clients-only (knot CLI + MCP server, no indexing): glibc 2.35+ (even older systems like Debian 12 Bookworm work fine)

For older Linux distributions or Windows, see the Lightweight Clients section below or use Docker (Option B).

Option B: Docker (Universal Compatibility)

Docker images provide universal compatibility for any Linux distribution and Windows.

Full Install (All Binaries: knot-indexer, knot CLI, knot-mcp)

Build the image:

docker build -t knot:latest . --network=host

Run the indexer:

# Use --network host to connect to databases running on your host machine
docker run --rm \
  -v /path/to/your/repo:/workspace \
  -e KNOT_REPO_PATH=/workspace \
  -e KNOT_NEO4J_PASSWORD=your-password \
  --network host \
  knot:latest \
  knot-indexer

Run the CLI tool:

docker run --rm \
  -v /path/to/your/repo:/workspace \
  -e KNOT_REPO_PATH=/workspace \
  -e KNOT_NEO4J_PASSWORD=your-password \
  --network host \
  knot:latest \
  knot search "user login flow"

Run the MCP server:

docker run --rm \
  -e KNOT_REPO_PATH=/workspace \
  -e KNOT_NEO4J_PASSWORD=your-password \
  --network host \
  knot:latest \
  knot-mcp

Note: Uses Debian Trixie (glibc 2.38+) and includes ONNX Runtime for full functionality.


Lightweight Clients (Only knot CLI + knot-mcp, No Indexer)

For older systems (Debian 12 Bookworm, Ubuntu 22.04) or production deployments that only need to query existing indexes without indexing new code:

Build the lightweight image:

docker build -t knot:clients -f Dockerfile.clients . --network=host

Image size: ~100MB (vs ~160MB for full install)

Run the CLI tool (query existing index):

docker run --rm \
  --network host \
  knot:clients \
  knot callers "MyClass"

Run the MCP server:

docker run --rm \
  --network host \
  knot:clients \
  knot-mcp

Available tools in lightweight mode:

  • ✅ knot search (structural only, no semantic search)

  • ✅ knot callers (reverse dependency lookup)

  • ✅ knot explore (file structure inspection)

  • ❌ Semantic search requires the full install

Note: Uses Debian Bookworm (glibc 2.35+) and excludes ONNX Runtime, making it compatible with older Linux distributions.

Option C: Install via Cargo

cargo install --git https://github.com/raultov/knot

Option D: Build from Source

Full Install (All Binaries):

1. Start infrastructure with Docker:

docker compose up -d

2. Clone and build:

git clone https://github.com/raultov/knot
cd knot
cargo build --release

3. Configure:

cp .env.example .env
$EDITOR .env  # Set KNOT_REPO_PATH and Neo4j credentials

4. Index a codebase:

./target/release/knot-indexer

5. Query via CLI:

./target/release/knot search "your query"

Option E: Lightweight Clients (No Indexing)

For older Linux distributions (e.g. Debian 12 Bookworm, Ubuntu 22.04) or production deployments where you only need the CLI and MCP server (not the indexer), compile without the embedding dependencies:

Build lightweight clients:

cargo build --release --no-default-features --features only-clients

This produces only knot and knot-mcp binaries (~8-10 MB each), excluding the 30+ MB of ONNX Runtime dependencies.

Available tools in lightweight mode:

  • ✅ find_callers: Reverse dependency lookup (graph search). Automatically groups results by target when multiple entities share the same name.

  • ✅ explore_file: File structure inspection

  • ❌ search_hybrid_context: Semantic search (requires embeddings, not available in this mode)

Use case: Query an existing Qdrant + Neo4j index that was built elsewhere, without needing the indexer on your machine.

Docker alternative (for lightweight mode):

docker build -t knot:clients-only -f Dockerfile -f - . << 'EOF'
FROM rust:1.90-slim-bookworm AS builder
WORKDIR /build
COPY . .
RUN cargo build --release --no-default-features --features only-clients
FROM debian:bookworm-slim
COPY --from=builder /build/target/release/knot* /usr/local/bin/
CMD ["knot-mcp"]
EOF

6. Start the MCP server:

./target/release/knot-mcp

📖 Usage

📥 Quick Downloads

Download knot binaries (CLI + MCP server):

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/raultov/knot/releases/latest/download/knot-installer.sh | sh

Download agent-skills documentation (index + all guides):

curl -sO https://raw.githubusercontent.com/raultov/knot/master/.knot-agent.md && curl -fsSL https://raw.githubusercontent.com/raultov/knot/master/.knot-agent-skills.tar.gz | tar -xz

📖 Agent-Skills Guides

Comprehensive documentation for using knot tools. The download above extracts:

  • search.md — Semantic code discovery guide with examples

  • callers.md — Reverse dependency lookup with critical usage rules

  • explore.md — File anatomy inspection guide

  • workflows.md — Common patterns and best practices

For quick reference without downloading, see .knot-agent.md.


Using the CLI (v0.8.0+)

The knot CLI provides the same capabilities as the MCP server via command-line commands, making it ideal for:

  • Terminal-only environments

  • Bash scripting and automation

  • CI/CD pipelines

  • Direct integration with other tools

Three main commands:

knot search "user authentication" --max-results 10 --repo my-app

Find code entities by meaning, class names, docstrings, or comments.

knot callers — Reverse Dependency Lookup

knot callers "LoginService" --repo my-app

Find all code that references a specific entity (dead code detection, impact analysis, call chains). When multiple entities share the same name in different files, results are automatically grouped by target with file locations and signatures.

knot explore — File Structure Inspection

knot explore "src/services/auth.ts" --repo my-app

List all classes, methods, functions in a file with signatures and documentation.

For detailed CLI usage guide, see .knot-agent.md — a machine-readable skill that teaches LLMs how to use knot CLI for autonomous code analysis.

Indexing a Codebase

Incremental Indexing (Default, v0.4.3+)

# First run: indexes all files
knot-indexer --repo-path /path/to/your/repo --neo4j-password secret

# Subsequent runs: only re-indexes changed files (fast!)
knot-indexer --repo-path /path/to/your/repo --neo4j-password secret

# NEW: Real-time Watch mode (v0.5.2+)
knot-indexer --watch --repo-path /path/to/your/repo --neo4j-password secret

How it works:

  • Tracks file content via SHA-256 hashes in .knot/index_state.json

  • Automatically detects: modified, added, and deleted files

  • Only re-parses and re-embeds changed files

  • Preserves graph relationships to unchanged files

  • Processes entities in memory-efficient 512-entity chunks

Performance:

  • Initial index (3800 files): ~60 minutes on standard hardware

  • Incremental update (3 files changed): ~5-10 seconds

  • Memory usage: Constant ~2GB regardless of repository size

Full Re-Index (Clean Mode)

# Force complete re-index (deletes all existing data)
knot-indexer --clean --repo-path /path/to/your/repo --neo4j-password secret

Use --clean when:

  • You want to rebuild the entire index from scratch

  • You've changed Tree-sitter queries or embedding models

  • Troubleshooting indexing issues

Running E2E Integration Tests

To ensure indexer stability, run the E2E integration test suite:

# Run all language E2E tests (Java, TS, JS, HTML, CSS, Kotlin, Rust)
./tests/run_e2e.sh

# Run only Kotlin E2E tests
./tests/run_kotlin_e2e.sh

# Run only Rust E2E tests
./tests/run_rust_e2e.sh

See tests/KOTLIN_E2E_TESTS.md for detailed coverage and troubleshooting.

Using the MCP Server

The MCP server exposes three tools to any compatible AI client:

Tool 1: search_hybrid_context

Find code by meaning or keywords

Query: "How is user authentication implemented?"
Result: All auth-related code, signatures, docstrings, and dependencies

Capabilities:

  • Semantic search by functionality

  • Class/method/function name lookup

  • Docstring and inline comment search

  • Architectural pattern discovery

  • Full dependency context

Tool 2: find_callers

Find who calls a specific function

Query: "Find callers of getCurrentTimeInSeconds"
Result: All code that invokes this function + file locations

Advanced: Search by Signature (NEW in v0.7.4)

# Find by full signature (Java)
echo '{"method":"tools/call","params":{"name":"find_callers","arguments":{"entity_name":"registerUser(String"}}}' | knot-mcp

# Find by parameter type (Kotlin)
echo '{"method":"tools/call","params":{"name":"find_callers","arguments":{"entity_name":"findById(Int"}}}' | knot-mcp

# Find by type annotation (TypeScript)
echo '{"method":"tools/call","params":{"name":"find_callers","arguments":{"entity_name":"(EventData"}}}' | knot-mcp

Use Cases:

  • Dead Code Detection: Zero callers = unused code

  • Impact Analysis: "What breaks if I modify this?"

  • Refactoring Safety: Find all references before removing

Tool 3: explore_file

Understand file structure

Query: "What's in BrowserService.ts?"
Result: All classes, methods, and functions with signatures and docs

Use Cases:

  • Quick file navigation

  • Module structure overview

  • Finding all methods in a class without reading line-by-line


🔗 MCP Client Configuration

Supported Clients

knot works with any MCP-compatible AI client:

  • ✅ Claude Desktop (Anthropic)

  • ✅ Gemini CLI (Google)

  • ✅ ChatGPT CLI / GPT (OpenAI)

  • ✅ Cursor (AI IDE)

  • ✅ Any standard MCP client

Configuration Examples

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "knot": {
      "command": "/absolute/path/to/knot/target/release/knot-mcp",
      "env": {
        "KNOT_REPO_PATH": "/path/to/indexed/repo",
        "KNOT_QDRANT_URL": "http://localhost:6334",
        "KNOT_NEO4J_URI": "bolt://localhost:7687",
        "KNOT_NEO4J_USER": "neo4j",
        "KNOT_NEO4J_PASSWORD": "your-password"
      }
    }
  }
}

Gemini CLI

{
  "mcpServers": {
    "knot": {
      "command": "/absolute/path/to/knot/target/release/knot-mcp",
      "env": {
        "KNOT_REPO_PATH": "/path/to/indexed/repo",
        "KNOT_QDRANT_URL": "http://localhost:6334",
        "KNOT_NEO4J_URI": "bolt://localhost:7687",
        "KNOT_NEO4J_USER": "neo4j",
        "KNOT_NEO4J_PASSWORD": "your-password"
      }
    }
  }
}

ChatGPT / GPT CLI

Similar JSON configuration in your client's MCP configuration file.


⚙️ Configuration Reference

All options can be set via environment variables (.env) or CLI flags. Environment variables take precedence.

.env Variable

CLI Flag

Default

Description

KNOT_REPO_PATH

--repo-path

(required)

Root directory of the repository to index

KNOT_REPO_NAME

--repo-name

(auto-detected)

Repository name for multi-repo isolation (auto-detected from last path component)

KNOT_QDRANT_URL

--qdrant-url

http://localhost:6334

Qdrant server URL

KNOT_QDRANT_COLLECTION

--qdrant-collection

knot_entities

Qdrant collection name

KNOT_NEO4J_URI

--neo4j-uri

bolt://localhost:7687

Neo4j Bolt URI

KNOT_NEO4J_USER

--neo4j-user

neo4j

Neo4j username

KNOT_NEO4J_PASSWORD

--neo4j-password

(required)

Neo4j password

KNOT_EMBED_DIM

--embed-dim

384

Embedding vector dimension

KNOT_BATCH_SIZE

--batch-size

64

Entities per batch

KNOT_CLEAN

--clean

false

Force full re-index (delete all existing data)

KNOT_CUSTOM_CA_CERTS

--custom-ca-certs

(none)

Path to CA certificate bundle for corporate SSL proxies

RUST_LOG

(env only)

info

Log level: trace, debug, info, warn, error


🎨 Custom Tree-sitter Queries

The built-in extraction queries (queries/java.scm, queries/typescript.scm) can be overridden without recompiling:

KNOT_CUSTOM_QUERIES_PATH=/path/to/my/queries ./target/release/knot-indexer

Place java.scm and/or typescript.scm in your custom directory. Missing files fall back to built-in defaults.


🔐 Corporate SSL / CA Certificates

In restricted corporate environments with SSL-inspecting proxies, you may need to provide a custom CA certificate bundle so that knot can download the embedding model from HuggingFace.

Via environment variable:

export KNOT_CUSTOM_CA_CERTS=/etc/ssl/certs/corporate-bundle.pem
./target/release/knot-indexer --repo-path /path/to/repo --neo4j-password secret

Via CLI flag:

./target/release/knot-indexer \
  --custom-ca-certs /etc/ssl/certs/corporate-bundle.pem \
  --repo-path /path/to/repo \
  --neo4j-password secret

Via .env file:

echo "KNOT_CUSTOM_CA_CERTS=/etc/ssl/certs/corporate-bundle.pem" >> .env
./target/release/knot-indexer

This works for all three binaries: knot-indexer, knot-mcp, and knot.


🔄 Workflow Example

Step 1: Index a Java project

./target/release/knot-indexer --repo-path /home/user/my-java-app --neo4j-password secret

Step 2: Query via CLI (Instant search)

./target/release/knot search "authentication logic"
./target/release/knot callers "UserService.login"

Step 3: Start MCP server (For AI Agents)

./target/release/knot-mcp

Step 4: Use with Claude Desktop

  • Claude will list the three tools in its Tools menu

  • Ask: "Search for all authentication logic"

  • Ask: "Find who calls the login method"

  • Ask: "Explore the structure of UserService.java"

🤖 Auto-Configuring AI Agents

knot includes a universal .prompt file in its root directory that automatically configures modern AI coding agents (Cursor, Cline, opencode, Claude, etc.) to use the knot-mcp tools correctly.

The directive explicitly instructs AI agents to prioritize:

  • search_hybrid_context — for semantic code discovery (instead of grep)

  • find_callers — for reverse dependency analysis (instead of finding references manually)

  • explore_file — for file structure inspection (instead of reading line-by-line)

This ensures that when you ask an AI agent to analyze, refactor, or understand your code, it leverages the full power of the vector and graph databases rather than falling back to context-blind regex searches. The .prompt file is universal and tool-agnostic, working with any LLM client that reads codebase directives.


🤝 Contributing

Contributions are welcome! Please ensure:

  • All code passes cargo clippy

  • Code is formatted with cargo fmt

  • Changes are compatible with Rust 2024 edition

  • All new functionality includes unit tests

  • Performance regressions are validated with the benchmark framework before submitting PRs

Performance Benchmarking

The project includes a three-level benchmarking framework to validate optimizations and detect regressions:

Level 1 — Unit Benchmarks (Criterion):

cargo bench --bench pipeline_bench          # Parse + prepare throughput per language
cargo bench --bench graph_upsert_bench     # Neo4j UNWIND batching speedup (needs Neo4j)
cargo bench --bench channel_backpressure_bench  # Bounded channel overhead

Level 2 — E2E Integration Benchmarks:

# Full pipeline metrics with memory and per-stage timing
./tests/benchmark_e2e.sh --focus rust_e2e --output-dir /tmp/perf_results

# Compare against baseline (fails CI if tolerance exceeded)
scripts/compare_perf_metrics.sh /tmp/perf_results .perf_metrics/baseline.json

Baseline files: .perf_metrics/baseline.json stores the last known good metrics (committed, updated on main/master merges). Tolerance thresholds in .perf_metrics/threshold_tolerances.json control regression gates (±5% time, ±10% memory by default).

CI Integration: The test-performance job in .github/workflows/ci.yml runs after all E2E correctness tests pass, comparing results against baseline and fails the build on regression.


📜 License

This project is licensed under the MIT License. See LICENSE for details.


🚀 Roadmap

Next Release (v1.1.0 — Performance Optimization) ✅

  • ✅ Neo4j UNWIND Batching (Phase 1-2): Replaced N individual MERGE queries with single UNWIND $entities batch queries — 10-50x speedup on entity/relationship writes

  • ✅ Bounded Channels (Phase 3): Parse/embed/res channels bounded with backpressure — peak memory <400MB (was 500MB unbounded)

  • ✅ Concurrent Ingestion (Phase 4): JoinSet + Semaphore for parallel Neo4j/Qdrant writes — 2-3x ingestion throughput

  • ✅ Rayon Thread Pool Config (Phase 5): Configurable KNOT_RAYON_THREADS env var (default N-1 cores)

  • ✅ Parallel Relationship Resolution (Phase 6): par_iter_mut() for O(N/num_cpus) resolution

  • ✅ Three-Level Benchmarking Framework (Section 9):

    • Criterion unit benchmarks: pipeline_bench, graph_upsert_bench, channel_backpressure_bench

    • E2E benchmark script: tests/benchmark_e2e.sh with metrics capture

    • CI regression tracking: scripts/compare_perf_metrics.sh + test-performance job

  • ✅ Memory targets: ~300-400MB peak (well below 2GB nice-to-have, far from 5GB hard limit)

  • ✅ Criterion benchmarks at benches/ | Baseline metrics at .perf_metrics/baseline.json

  • ✅ cargo fmt clean | cargo clippy clean | 521 unit tests passing

Current Release (v1.2.0 — Cargo.toml, Config Files, Kubernetes + Helm) ✅

  • ✅ Phase 12A — Cargo.toml Parser: Package metadata, dependencies (simple/table/git/path), features, workspace members via toml = "0.8"

  • ✅ Phase 12B — Configuration Files: YAML (.yml/.yaml), JSON (.json), Java Properties (.properties) with recursive walk, depth limit 10, leaf-key granularity, lock file exclusions, 500KB file size limit. package.json special handling: npm deps as BuildDependency, scripts as ConfigProperty, ProjectIdentity emission

  • ✅ Phase 12C — Kubernetes + Helm: 10 new EntityKind variants (K8sDeployment, K8sService, K8sConfigMap, K8sSecret, K8sIngress, K8sNamespace, K8sResource, HelmChart, HelmValue, HelmTemplateVar). K8s manifest parsing with label/annotation/reference extraction, Helm Chart.yaml/values.yaml/templates support with {{ .Values.X }} variable tracking

  • ✅ 74+ new unit tests across 6 parser modules + 29 E2E tests (6 Cargo + 6 Config + 9 K8s/Helm)

  • ✅ 10/10 E2E test suites pass: JS/TS/Java, Kotlin, Rust, Python, Build Systems (extended), Config Files, K8s/Helm, Groovy, Cross-Language Ref, C/C++

  • ✅ cargo fmt clean | cargo clippy clean | 520 unit tests passing

Previous Release (v0.10.3 — Groovy Private Methods, Nested Closures & UUID Collision Fix) ✅

  • ✅ UUID Collision Fix: ParsedEntity identity now includes start_line

  • ✅ Multi-line Method Extraction: try_extract_typed_method_multiline handles closure default params

  • ✅ Innermost Assignment: method calls in nested closures go to the innermost method

  • ✅ 10 E2E test cases: typed/def/no-paren callers, multi-line closures, innermost assignment

  • ✅ 441 unit tests | clippy clean | fmt applied

Previous Release (v0.8.7 — Enhanced Rust Type Reference Detection in Macros) ✅

  • ✅ Macro Type Reference Extraction: Type references inside macro invocations (vec![], println!(), assert!(), format!(), etc.) are now correctly captured

  • ✅ Intelligent String Filtering: Filters out false positives from string literals using quote-counting heuristics

  • ✅ Comprehensive Edge Case Handling: Validates identifiers, handles nested macros, supports macro_rules! definitions

  • ✅ Improved Accuracy: EntityKind references increased by +95.7% (46→90 references), now captures test function usage

  • ✅ Enhanced Test Coverage: Added 4 new tests for token_tree extraction covering various macro types and edge cases

Previous Release (v0.8.6 — Rust Type Aliases, Constants, and Docstrings) ✅

  • ✅ Rust Type Alias Extraction: Extracts type alias declarations with full signature (e.g., type Callback = fn(u32) -> u32)

  • ✅ Rust Constant/Static Extraction: Captures const and static mut declarations with type signatures

  • ✅ Rust Docstring Support: Full doc comment extraction for Rust entities (handles nested doc_comment nodes in tree-sitter-rust)

  • ✅ Rich Vector Embeddings: Type signatures and documentation are now included in embeddings for better semantic search

  • ✅ Improved Search Ranking: Rust entities like Callback now rank in top 5 search results when querying by name

Previous Release (v0.8.5 — Rust Module Refactoring & Clippy Fixes) ✅

  • ✅ Rust Module Refactoring: Extracted Rust parsing logic into dedicated src/pipeline/parser/languages/rust.rs for better maintainability and mirroring existing language module architecture.

  • ✅ Clippy Compliance: Fixed unused import (uuid::Uuid) and unnecessary mut warning in Rust module tests.

  • ✅ Rust Support Complete: Phase 8 implementation fully integrated with 17 unit tests and 22 E2E test cases passing.

Previous Release (v0.8.4 — Agent-Skills Documentation Installer & Lightweight Clients) ✅

  • ✅ Dry-Run Mode: MCP server can run in offline mode for quality checks on deployment platforms.

  • ✅ Platform-Agnostic: Removed all platform-specific references; compatible with any deployment platform.

  • ✅ Enhanced Reliability: Graceful handling of missing database connections for validation scenarios.

Previous Release (v0.10.0 — Build Systems & CI/CD Support) ✅

  • ✅ Build Systems Support (Phase 9): Maven pom.xml (dependencies + plugins via roxmltree), Gradle build.gradle (deps + plugins + tasks), and Jenkinsfile pipeline (stages + steps) extraction

  • ✅ 22 unit tests + 8 E2E tests (Maven search, pom.xml explore, Gradle dep/task search, Jenkins stage/step search)

  • ✅ BuildDependency, BuildPlugin, BuildTask, PipelineStage, PipelineStep entity kinds with explore_file formatting

Previous Release (v0.9.3 — Python Search Stability & CI Fixes) ✅

  • ✅ Fixed CLI explore & search queries that queried the default collection instead of test collection by appending -r "$REPO_NAME"

  • ✅ Python CLI search bug handled; resolved knot search queries failing in specific collection bounds

  • ✅ Replaced unreliable nc -z network checks with Neo4j-specific Docker health checks (docker inspect)

  • ✅ 426 unit tests | 23 Python E2E | 22 Rust E2E | 10 Kotlin E2E

Earlier Release (v0.8.2 — Quality & Doc Refactor) ✅

  • ✅ MCP Quality: Enhanced tool descriptions for better agent discovery and usage safety.

  • ✅ Token-Efficient Docs: Modularized agent skill guide into docs/agent-skills/ for on-demand loading.

  • ✅ Rust Phase 1: Infrastructure prepared for Rust 2024 integration.

  • ✅ Rust Phase 2-5: Complete Rust language support including entity extraction, macro tracking, and comprehensive E2E testing (v0.8.x).

Earlier Release (v0.8.1 — CLI UX & Docker Integration) ✅

  • ✅ Silenced CLI Logs: Default log level set to error for knot CLI (cleaner Markdown output).

  • ✅ 100% E2E Dual-Testing: All 35 integration tests simultaneously verify both MCP and CLI.

  • ✅ Docker CLI Support: Official Docker image now includes the knot binary.

  • ✅ Agent Guidance: Enhanced .knot-agent.md with signature-based search warnings.

Phase 7 (v0.8.10 — CLI UX & Corporate Network Support) ✅

  • ✅ Human-friendly output formatting: Colorized table output as default with per-entity-kind ANSI colors

  • ✅ Interactive result navigation: Pager support via less -R -e with auto-exit at end of content

  • ✅ Configurable output formats: --output flag supports table (default), json, and markdown

  • ✅ Custom CA Certificates: --custom-ca-certs / KNOT_CUSTOM_CA_CERTS for corporate SSL-inspecting proxies

  • ✅ O(N) Macro Traversal Optimization (v0.8.11): Substring skipping for deeply nested token_tree nodes

Phase 8 (v0.8.11 — Rust Support) ✅

  • ✅ Support .rs files with tree-sitter-rust parser

  • ✅ Struct, enum, union, trait, and impl block extraction

  • ✅ Function, method, macro definition and invocation tracking

  • ✅ Type alias, constant, static, and module extraction with signatures

  • ✅ Docstring extraction for all Rust entity types

  • ✅ O(N) nested macro traversal optimization for large Rust codebases

  • ✅ 17 unit tests for Rust entity and reference extraction

  • ✅ 22 end-to-end integration tests covering all Rust language constructs

Phase 11 (v1.0.0 — C/C++ Support) ✅

  • ✅ Support .c, .cpp, .cc, .cxx, .h, .hpp, .hh, .hxx files via tree-sitter-c and tree-sitter-cpp

  • ✅ Intelligent auto-detection of .h files to parse them as C++ if they contain classes, namespaces, or templates

  • ✅ Namespace-aware FQN resolution (Engine::MyClass::start)

  • ✅ Class, struct, function, and method extraction with full signatures

  • ✅ Macro definition and usage tracking (uppercase identifier heuristic)

  • ✅ Type reference tracking (declarations, new expressions, qualified types)

  • ✅ Call graph analysis including method calls, field access (obj->method()), and scope resolution (std::vector::size())

  • ✅ 3 unit tests for C++ entity and reference extraction

  • ✅ 4 end-to-end integration tests covering FQN, call graphs, macro usage, and type references

Upcoming (v1.3.x)

Phase D: Cross-Repo Dependency Linking

  • Automatic inter-repository call resolution via :Repository graph model with DEPENDS_ON edges

  • ProjectIdentity marker entity from build files (Maven GAV, Cargo package, npm name)

  • knot deps CLI subcommand + list_repo_dependencies MCP tool for dependency graph visualization

  • Retroactive linking for out-of-order indexing

Long-Term Vision

  • Reestructure E2E test suites to gain velocity by sharing binaries with unit tests and avoid Docker overhead

  • Markdown documentation indexing

  • Go support

  • C# support

  • IDE plugins (VS Code, IntelliJ, Vim)

  • Web UI for graph visualization

  • Language Server Protocol (LSP) integration

  • Automated Code Review tool (MCP-based)


💬 Questions?

For issues, feature requests, or discussions, please open a GitHub issue.

Available Tools

6 tools
explore_fileExplore file anatomyA
Read-onlyIdempotent

Read-only file anatomy inspection. Use this to list all classes, methods, and properties within a specific source file without reading its entire contents. Provides a structural bird's-eye view of a file, showing entity signatures and docstrings to quickly grasp a module's layout.

Usage: Use AFTER identifying an interesting file via 'search_hybrid_context' to understand its available methods, or before modifying a file. Do NOT use this for searching across multiple files.

Behaviour & Return: Read-only operation. Returns a Markdown-formatted outline of the file's entities, grouped by type (Classes, Methods, Interfaces, Constants, etc.), including line numbers for direct editor navigation. Attribute-usage markup references (html_class, html_id) are summarized in a separate section by default to avoid inflating code lists; set include_markup to true to list them in full. No side effects.

Path handling: file_path should be a repo-relative path (e.g. 'src/services/user.ts'). Absolute paths under your local checkout are also accepted; the tool strips the known local root automatically. The returned file_path is normalized to the same repo-relative form regardless of how it was queried. If the query is ambiguous across multiple repositories, the answer includes an 'ambiguous_path_candidates' list — retry with a longer path or pass repo_name.

Parameter guidance: 'file_path' must be a relative or absolute path to a valid source file. Include 'repo_name' if the file path might be ambiguous across multiple indexed repositories. Set 'include_markup' to true to expand attribute-usage markup tokens.

Supports Java, Kotlin, C#, and TypeScript codebases.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the source file to explore. PREFERRED: a repo-relative path (e.g. 'src/services/user.ts'). ALSO ACCEPTED: an absolute path under the repository's local checkout (the tool strips KNOT_REPO_PATH / CWD automatically).
repo_nameNoOptional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories.
include_markupNoOptional: set to true to list all attribute-usage markup tokens (html_class, html_id) in full rather than in a compact summary. Defaults to false.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description adds that it returns a Markdown-formatted outline grouped by type with line numbers, summarizes markup tokens by default, and normalizes paths. It also discloses ambiguity handling via 'ambiguous_path_candidates'. These details go well beyond the annotations.

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 structured with clear paragraphs and front-loads the core purpose in the first sentence. Each section addresses a distinct concern (usage, return, path handling, params, languages), so the length is justified despite minor redundancy with the schema.

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

Completeness5/5

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

The tool is complex (path handling, ambiguity, markup control) and the description covers all of it: when to use, what it returns, how paths are normalized, what the markup flag does, and which languages are supported. The absence of an output schema is compensated by the explicit return-format description.

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

Parameters4/5

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

The schema already documents all three parameters thoroughly (100% coverage). The description's parameter guidance largely reiterates the schema, but it adds extra value by explaining path normalization, the 'ambiguous_path_candidates' retry hint, and the supported languages (Java, Kotlin, C#, TypeScript), which helps interpret valid file_path values.

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 opens with 'Read-only file anatomy inspection' and explicitly says it lists all classes, methods, and properties within a specific source file without reading its entire contents. This states a specific verb and resource and differentiates it from file-listing and search siblings.

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

Usage Guidelines5/5

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

The description explicitly directs use AFTER search_hybrid_context and before modifying a file, and warns 'Do NOT use this for searching across multiple files.' It names the alternative and the condition.

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

find_callersFind callers (reverse dependencies)A
Read-onlyIdempotent

Read-only reverse dependency lookup. Use this to find all code that references, calls, extends, or implements a specific entity. Answers 'who uses this code?' by querying the graph database. Differs from search tools by providing exact dependency tracking.

Usage: Use for impact analysis before refactoring or to detect dead code. Do NOT use this for semantic feature discovery—use 'search_hybrid_context' instead.

Matching is precedence-based: exact FQN (containing '.' or '::') → FQN suffix (Type.member) → exact name → signature prefix (accept(List) → name prefix (queries under 4 characters) → fuzzy substring (queries of 4+ characters). The first tier that matches wins, so an exact name never returns fuzzy noise. Queries shorter than 4 characters resolve by anchored name prefix instead of substring, avoiding substring noise on short strings. Pass a qualified name (Namespace.Type.Member) to disambiguate homonyms. Responses state which tier matched and flag fuzzy results explicitly.

Behaviour & Return: Read-only graph traversal with no side effects. Returns Markdown grouped by relationship type (Calls, Extends, Implements, References, Overridden by, Overrides, Dispatched calls) with exact file paths and line numbers. Each caller entry and each resolved target states its repository as (repo: name), so rows are attributable when multiple repositories are in scope. For JVM code (Java/Kotlin/Groovy) and C#, 'Overridden by' lists method implementations/overrides in subtypes and 'Overrides' lists the supertype methods a method implements/overrides. 'Dispatched calls' lists callers bound to an override or to a supertype method of the target (dynamic dispatch), each under the method it is statically bound to, so an interface method called only through its implementation is never reported as unused. When the query resolves to more than one entity with that name (homonyms, e.g., 'find_nearest_entity_by_line' in orphans.rs vs rust.rs), results are grouped by target entity showing which specific target each caller references — even when only one of the homonyms has callers. Each caller entry includes: name, kind, file_path:line_number, and signature. When multiple targets exist, each group shows the target's location and signature.

Entity-kind scope: target resolution is code-only by default — documentation, configuration, build-system and Kubernetes/Helm metadata (markdown_section, config_property, build_dependency, cargo_package, project_identity, k8s_*, helm_*, …) can never be presented as resolved targets. When the filter removed matches, the response says so ('Non-code matches hidden — N entities …'), never silently. Pass kinds='all' (or '*') to disable the filter, or a comma-separated allow-list of exact kinds/aliases ('callable', 'config', 'docs', 'rust_function', 'build_dependency', …) to scope resolution explicitly. The response's resolution.kind_filter field states which scope applied ('code_default', 'any', 'explicit').

Relationship coverage: the buckets cover every edge type the pipeline produces — Calls, Extends, Implements, References, Macro calls (MACRO_CALLS), DOM references (JS → HTML id), CSS class usage (JS → CSS class), script/stylesheet imports, and the VCL edges (uses backend/probe/acl, includes, imports vmod, declared-unused) — plus Overridden by / Overrides / Dispatched calls.

Truncation & completeness: the queried name is first resolved to concrete targets (capped at 25 by default). When more targets match than fit the cap, the response states 'Truncated — N targets matched; showing the first M by FQN' and 'Counts below are partial — they cover only the M of N targets shown', so bucket counts are never mistaken for the complete impact set. Raise 'max_targets' (up to 500) to retrieve more targets when the notice reports truncation.

Parameter guidance: 'entity_name' supports exact names or signature fragments (e.g., 'handleRequest' or 'handle(Request'). Include 'repo_name' to filter results to the specific codebase being analyzed.

Supports Java, Kotlin, C#, Rust, and TypeScript codebases.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindsNoOptional entity-kind scope for target resolution. Omit for the default code-only scope (docs/config/build metadata are hidden from the target list and the response discloses them). Use 'all' (or '*') to disable filtering, or a comma-separated allow-list of exact kinds or aliases ('callable', 'class', 'config', 'docs', 'rust_function', 'build_dependency', ...).
repo_nameNoOptional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories.
entity_nameYesThe name of the function, method, or class to find callers for
max_targetsNoMaximum number of resolved targets to include (default: 25, max: 500). Raise this when the response reports a truncated target list and you need the complete impact set.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent safety profile, yet the description adds substantial non-obvious behavior: precedence-ordered match tiers, resolution notices naming the matched tier, fuzzy-result flagging, 25-target default cap with explicit truncation wording, and repo attribution per row. Dynamic-dispatch handling ('Dispatched calls') is a genuinely important disclosure that prevents false 'unused code' conclusions.

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?

Purpose and usage are front-loaded and every section is labeled, which suits a tool this behaviorally complex. It is long, though, and some points are stated twice — the sub-4-character prefix behavior appears twice, and the kind-filter/truncation guidance partly repeats the schema's own parameter descriptions.

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

Completeness5/5

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

No output schema exists, and the description fully compensates: it describes the Markdown grouping by relationship bucket, per-row fields (name, kind, file:line, signature), homonym grouping, and the resolution.kind_filter field. Truncation semantics and supported languages are also covered, leaving no material gap for correct invocation.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds meaning the schema lacks: the exact matching precedence ladder for entity_name (FQN → suffix → exact name → signature prefix → name prefix → fuzzy), the 4-character threshold that switches prefix to substring matching, and the advice to pass a qualified name to disambiguate homonyms. It also explains the practical payoff of max_targets and kinds rather than restating them.

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?

Opens with a specific verb+resource+scope: 'Read-only reverse dependency lookup' and frames the question it answers ('who uses this code?'). It explicitly contrasts itself with search tools ('Differs from search tools by providing exact dependency tracking'), so an agent can place it among the siblings without reading the schema.

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

Usage Guidelines5/5

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

Gives concrete when-to-use cases ('impact analysis before refactoring or to detect dead code') and an explicit exclusion with a named alternative: 'Do NOT use this for semantic feature discovery—use search_hybrid_context instead.' That is the strongest form of routing guidance.

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

list_filesList indexed repository filesA
Read-onlyIdempotent

Read-only listing of the files an indexed repository carries, with entity counts and deterministic order. Answers 'list every file under src/hooks' or 'which files live in src/api/**' without prior path knowledge.

Usage: Use this BEFORE 'search_hybrid_context' when you do not know the codebase layout; then pass the same prefix to the search's optional 'path' parameter to scope results to those files. Do NOT use this to enumerate entities — use 'explore_file' on a file from this listing for its anatomy.

Behaviour & Return: Read-only query with no side effects. Returns a Markdown table with columns: REPOSITORY, FILE, ENTITIES, ordered by (repository, path). When output exceeds 2000 files, the table displays the first 2000 matches alongside a truncation notice stating the exact total when known, or an explicit lower bound when the scan stopped early. When nothing matches the prefix, returns 'No indexed files matched the given path'.

Parameter guidance: 'path' is optional. PREFERRED: a repo-relative directory prefix (e.g. 'src/api') matched on a path boundary, or a glob ('src/**/*_test.rs'). Prefixes and globs page all indexed files in pages with per-page boundary filtering without dropping candidates. Absolute paths under the local checkout are accepted and normalized like 'explore_file'. Omit to list every indexed file (capped; the reply notes truncation).

Parameter guidance: 'repo_name' scopes the listing. Accepts a single repository name or a comma-separated list; include it when several indexed repositories may share path shapes.

Supports all languages indexed by knot.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoOptional repo-relative directory prefix (e.g. 'src/api', matched on a path boundary) or glob pattern (segments: `*` segment wildcard, `**` any depth, `?` one char). Absolute paths under the local checkout are accepted and normalized like 'explore_file'. Omit to list every indexed file.
repo_nameNoOptional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. Include it when several indexed repositories may share path shapes.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark readOnly/idempotent/non-destructive, but the description adds behavioral details beyond hints: deterministic ordering by (repository, path), a 2000-file cap with a truncation notice showing exact or lower-bound totals, and the exact empty-result string. There is no contradiction with the annotations.

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 long but deliberately sectioned (Usage, Behaviour & Return, Parameter guidance) and front-loaded with its core purpose. Some prose repeats annotation facts and schema descriptions, so it is not maximally tight, but the structure keeps the extra length navigable and each section earns its place.

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

Completeness5/5

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

For a two-parameter read-only listing tool, the description covers intended use, chaining with siblings, exact return columns and order, truncation behavior, empty-match response, and both parameter semantics. Since there is no output schema, explicitly documenting the return format and edge cases is valuable and fully handled.

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

Parameters5/5

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

Schema coverage is 100% so the baseline is 3, but the description goes well beyond schema text: it explains path-boundary prefix matching, glob semantics, paging behavior ('per-page boundary filtering without dropping candidates'), absolute-path normalization, and when repo_name is needed (shared path shapes across repositories). This materially improves call construction.

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 first sentence states a specific verb ('listing'), a specific resource ('files an indexed repository carries'), and two distinguishing outputs (entity counts, deterministic order). It explicitly distinguishes its contribution from search_hybrid_context and explore_file, so it cannot be confused with siblings.

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

Usage Guidelines5/5

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

The 'Usage' section states concretely when to use it ('BEFORE search_hybrid_context when you do not know the codebase layout'), how to chain it with that sibling, and an explicit negative instruction ('Do NOT use this to enumerate entities — use explore_file'). This is explicit, actionable routing.

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

list_repo_dependenciesList cross-repository dependenciesA
Read-onlyIdempotent

Read-only cross-repository dependency graph lookup. Shows which repositories depend on each other via build system declarations (Maven, Gradle, Cargo, npm, NuGet). Answers 'which repos does this repo depend on?' and 'which repos depend on this repo?'.

Usage: Use BEFORE cross-repo analysis to discover which other indexed repos are available for call tracing. Use reverse mode for impact analysis before making breaking changes in shared libraries.

Behaviour & Return: Read-only graph traversal with no side effects. Returns a JSON array of repository names. Empty results mean no DEPENDS_ON relationships exist for that repo. Empty lookups are explained in the response text with a three-way classification: declares-but-resolves-without-edge (stale graph, re-index hint), declares-but-nothing-resolves (not indexed), or nothing declared; the reverse direction names consumers that declare the repo without an edge yet.

Parameter guidance: 'repo_name' is required and must match the name used during indexing. 'max_depth' defaults to 3 (1 = direct only) and applies to both directions — in reverse mode it follows dependents transitively. 'reverse' toggles between forward and reverse dependency lookup.

Supports all build systems indexed by knot: Maven, Gradle, Cargo, npm, NuGet (.csproj + Central Package Management via Directory.Packages.props). C# repos that previously reported build_system: "none" now report "nuget" on re-index; knot-indexer --clean is recommended for immediate effect.

ParametersJSON Schema
NameRequiredDescriptionDefault
reverseNoIf true, show repositories that depend ON this repo (reverse lookup). If false (default), show repositories this repo depends ON. Use reverse for impact analysis before breaking changes.
max_depthNoMaximum depth for transitive dependency traversal (default: 3, max: 10). Use 1 for direct dependencies only. Requests above 10 are clamped to 10 (and below 1 to 1). Applies to both directions: with reverse=true it follows dependents transitively.
repo_nameYesRepository name to show dependencies for. Must match the name used during indexing (e.g., 'my-java-repo', 'auth-service'). This is REQUIRED — there is no default.

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the readOnly/idempotent annotations by disclosing that it is a side-effect-free graph traversal, specifying the JSON array return type, and explaining empty result semantics with a three-way classification including stale-graph and not-indexed cases. This is rich, actionable behavioral detail.

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 long but exceptionally well structured with labeled paragraphs for usage, behavior, return values, parameter guidance, and supported build systems. Every sentence carries actionable information and is front-loaded with the core purpose before caveats.

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

Completeness5/5

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

Given there is no output schema, the description fully compensates by explaining return shape, empty-result semantics, direction behavior, depth semantics, and supported build systems. For a 3-parameter tool with rich annotations, nothing essential is missing.

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 the baseline is 3. The description mostly restates the schema's parameter guidance (repo_name required, max_depth default/applies to both directions, reverse toggling) rather than adding entirely new meaning, though it does usefully summarize the key constraints in one place.

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 states a specific verb ('lookup') and precise resource ('cross-repository dependency graph'), and explicitly frames the two questions it answers: which repos does this repo depend on and which depend on it. This clearly distinguishes it from sibling tools like list_repositories and find_callers.

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

Usage Guidelines4/5

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

Explicit usage guidance is provided: use before cross-repo analysis for call tracing, and use reverse mode for impact analysis before breaking changes. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the context is clear enough for an agent to select it appropriately.

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

list_repositoriesList indexed repositoriesA
Read-onlyIdempotent

Read-only listing of all indexed repositories with optional name filtering. Shows repository metadata including entity count, file count, build system, and primary language. Answers 'what codebases have I indexed?' and 'which repositories match this name?'.

Usage: Use this tool FIRST to discover available codebases before searching or exploring. Once you know the repository name, switch to 'search_hybrid_context' for semantic search, 'find_callers' for reverse dependency lookup, 'explore_file' for file anatomy, or 'list_repo_dependencies' for cross-repo dependency graphs. Do NOT use this tool to search for code entities — use 'search_hybrid_context' instead.

Behaviour & Return: Read-only query with no side effects. Returns a Markdown table with columns: REPO, BUILD SYSTEM, LANGUAGE, FILES, ENTITIES. When no repositories match the filter, returns 'No repositories found.'

Parameter guidance: 'filter' is optional. When provided, only repositories whose name contains the filter string are returned (case-insensitive substring match). Omit to list all indexed repositories.

Supports all languages and build systems indexed by knot.

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNoOptional filter to narrow down repositories by name (case-insensitive substring match). When provided, only repositories whose name contains this string are returned. Examples: 'auth' matches 'auth-service' and 'Auth-Lib', 'api' matches 'my-api'. Omit to list all indexed repositories.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: the return is a Markdown table with named columns, and the no-match case returns 'No repositories found.' That extra disclosure is valuable since there is no output schema, though permission/indexing prerequisites are not addressed.

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?

Front-loaded with purpose, then clearly sectioned into Usage, Behaviour & Return, and Parameter guidance. Slightly longer than necessary because the filter semantics and read-only nature repeat structured fields, but every section is scannable and earns its place.

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

Completeness5/5

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

With no output schema, the description supplies the return shape and empty-result behavior; with four sibling tools, it routes the agent to the correct alternative; with one fully-documented param, nothing else is needed. Complete for a low-complexity read tool.

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% and the single 'filter' param is fully documented in the schema (substring, case-insensitive, examples, optional). The description restates the same semantics rather than adding new meaning, so the baseline 3 is appropriate.

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?

States a specific verb+resource ('Read-only listing of all indexed repositories') plus the metadata surfaced and the questions it answers. An agent can distinguish it from search_hybrid_context, find_callers, explore_file, and list_repo_dependencies without opening any schema.

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

Usage Guidelines5/5

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

Explicitly says to use this tool FIRST to discover codebases, names the exact sibling to switch to for each follow-up intent, and includes an explicit 'Do NOT use this tool to search for code entities' exclusion. Full when/when-not/alternatives coverage.

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

search_hybrid_contextHybrid semantic + structural searchA
Read-onlyIdempotent

Read-only semantic and structural code search combining vector embeddings with graph analysis. Use this for initial codebase discovery to find features by their meaning (e.g., 'user authentication'). Locates code based on natural language descriptions instead of exact keywords, returning relevant files, signatures, and documentation.

⚠️ PREREQUISITE: This tool requires an active knot-mcp server with vector database (Qdrant) and graph database (Neo4j) initialized.

Behavior & Return: Performs a read-only dual query against vector DB (for semantic similarity) and graph DB (for architectural relationships). Returns Markdown-formatted results with file paths, line numbers, code snippets, and cross-repository dependencies. No side effects.

Usage: Use as your FIRST step when exploring unfamiliar code or discovering architectural patterns. Do NOT use this to find all usages of a specific function—use the 'find_callers' tool for that instead.

Ranking contract: results are kind-aware — function/method/class/struct definitions outrank markdown docs, test files, config properties and build-dependency entities for natural-language queries; callers and helpers appear as context attached to a definition, never as substitutes. The shared entry point of the highest-ranked helpers outranks those helpers a loose paraphrase surfaces.

Generic-verb guard: an entity merely named after a generic verb or noun (find/get/create/build/acquire/borrow/current/…) does not win on that name alone; the full name boost is paid only when the entity's container context (FQN) corroborates a second query token.

Recall contract: entity embeds carry identifier tokens and the tokenized call names of the entity's body, so a paraphrase of what a definition does (even one with no doc comment) still surfaces it. Entities whose identifier shares a word with the query enter the candidate pool by token match alone.

Result bound: 'max_results' is 1-100 (default 5) and is enforced — a larger request is clamped to 100 and the reply says so. There is no pagination: when the bound is not enough, narrow the scope with 'kinds' / 'path' / 'repo_name' or refine the query rather than raising the limit.

Parameter guidance: 'query' should be 2-5 words describing functionality. Increase 'max_results' to 10-20 for broad discovery, keep at 5 for focused search. Include 'repo_name' in your first query to avoid cross-repository pollution.

Supports Java, Kotlin, C#, and TypeScript codebases.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoOptional path filter. A repo-relative directory prefix ('src/api', matched on a path boundary so 'src/api-notes.md' never matches) or a glob ('src/**/*_test.rs'). Use 'list_files' first when you do not know the layout. Omit to search every file.
kindsNoOptional entity-kind filter. Accepts exact wire-format kinds (`'rust_function'`, `'markdown_section'`, `'kotlin_class'`, …) or aliases: `'definition'` (all functions/methods/types), `'callable'`/`'function'`/`'method'` (all callable kinds), `'class'`/`'type'`/`'struct'` (all type kinds). Comma-separate for multiple values. Omit to search all kinds.
queryYesSearch query describing what you're looking for (e.g., 'user authentication', 'API error handling')
repo_nameNoOptional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories.
max_resultsNoMaximum number of results to return (default: 5, max: 100). Requests above 100 are clamped to 100 and the reply says so — there is no cursor or pagination; to look past the bound, narrow the search with 'kinds' / 'path' / 'repo_name' or refine the query.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, but the description adds substantial context: no side effects, clamping behavior on max_results, absence of pagination, ranking kind-awareness, recall contract, and the prerequisite server/database setup. This goes far beyond what annotations convey and is consistent with them.

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 comprehensive but quite lengthy, with many distinct sections (prerequisite, behavior, usage, ranking contract, recall contract, result bound, parameter guidance, supported languages). While each section earns its place for a complex tool, the overall length dilutes focus. It is well-structured with headers and emoji but could be tightened without losing critical information.

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

Completeness5/5

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

For a hybrid search tool with no output schema, the description covers prerequisites, return format, ranking, recall, result bounds, parameter tuning, and language support. The agent has everything needed to invoke it correctly and interpret results, including explicit exclusions (no pagination, clamp behavior).

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

Parameters4/5

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

Schema coverage is 100% so baseline is 3, but the description adds practical guidance beyond the schema: recommends 2-5 word queries, suggests max_results ranges for broad vs focused discovery, and explains path boundary matching and glob usage. This meaningfully supplements the schema.

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 it is a read-only semantic and structural code search combining vector embeddings with graph analysis, and explicitly contrasts itself with find_callers for usage-of-a-function. The verb+resource+method is specific and unambiguous.

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

Usage Guidelines5/5

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

Explicitly tells the agent to use this as the first step for unfamiliar code or architectural discovery, and gives a concrete 'do NOT use' with the alternative tool (find_callers). Also includes parameter guidance (query length, max_results values, repo_name) and a ranking contract that governs result interpretation.

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. 1 tool updatev1.11.1
    • Changedexplore_file1 field changed
      • addedInput schema / properties / include_markup
        Added value: +{
        +  "description": "Optional: set to true to list all attribute-usage markup tokens (html_class, html_id) in full rather than in a compact summary. Defaults to false.",
        +  "type": [
        +    "boolean",
        +    "null"
        +  ]
        +}
  2. 4 tool updatesv1.9.6
    • Changedfind_callers2 fields changed
      • addedInput schema / properties / kinds
        Added value: +{
        +  "description": "Optional entity-kind scope for target resolution. Omit for the default code-only scope (docs/config/build metadata are hidden from the target list and the response discloses them). Use 'all' (or '*') to disable filtering, or a comma-separated allow-list of exact kinds or aliases ('callable', 'class', 'config', 'docs', 'rust_function', 'build_dependency', ...).",
        +  "maxLength": 1024,
        +  "minLength": 1,
        +  "type": [
        +    "string",
        +    "null"
        +  ]
        +}
      • addedInput schema / properties / max_targets
        Added value: +{
        +  "default": 25,
        +  "description": "Maximum number of resolved targets to include (default: 25, max: 500). Raise this when the response reports a truncated target list and you need the complete impact set.",
        +  "maximum": 500,
        +  "minimum": 1,
        +  "type": [
        +    "integer",
        +    "null"
        +  ]
        +}
    • Addedlist_files
    • Changedlist_repo_dependencies1 field changed
      • changedInput schema / properties / max_depth / description
        Previous value: -"Maximum depth for transitive dependency traversal (default: 3). Use 1 for direct dependencies only. Higher values follow chains deeper. Must be between 1 and 10."New value: +"Maximum depth for transitive dependency traversal (default: 3, max: 10). Use 1 for direct dependencies only. Requests above 10 are clamped to 10 (and below 1 to 1). Applies to both directions: with reverse=true it follows dependents transitively."
    • Changedsearch_hybrid_context4 fields changed
      • addedInput schema / properties / kinds
        Added value: +{
        +  "description": "Optional entity-kind filter. Accepts exact wire-format kinds (`'rust_function'`, `'markdown_section'`, `'kotlin_class'`, …) or aliases: `'definition'` (all functions/methods/types), `'callable'`/`'function'`/`'method'` (all callable kinds), `'class'`/`'type'`/`'struct'` (all type kinds). Comma-separate for multiple values. Omit to search all kinds.",
        +  "maxLength": 255,
        +  "minLength": 1,
        +  "type": [
        +    "string",
        +    "null"
        +  ]
        +}
      • changedInput schema / properties / max_results / description
        Previous value: -"Maximum number of results to return (default: 5)"New value: +"Maximum number of results to return (default: 5, max: 100). Requests above 100 are clamped to 100 and the reply says so — there is no cursor or pagination; to look past the bound, narrow the search with 'kinds' / 'path' / 'repo_name' or refine the query."
      • changedInput schema / properties / max_results / maximum
        Previous value: -20New value: +100
      • addedInput schema / properties / path
        Added value: +{
        +  "description": "Optional path filter. A repo-relative directory prefix ('src/api', matched on a path boundary so 'src/api-notes.md' never matches) or a glob ('src/**/*_test.rs'). Use 'list_files' first when you do not know the layout. Omit to search every file.",
        +  "maxLength": 500,
        +  "minLength": 1,
        +  "type": [
        +    "string",
        +    "null"
        +  ]
        +}
  3. 5 tool updatesv1.9.4
    • Changedexplore_file1 field changed
      • changedInput schema / properties / repo_name / type
        Previous value: -"string"New value: +[
        +  "string",
        +  "null"
        +]
    • Changedfind_callers1 field changed
      • changedInput schema / properties / repo_name / type
        Previous value: -"string"New value: +[
        +  "string",
        +  "null"
        +]
    • Changedlist_repo_dependencies2 fields changed
      • changedInput schema / properties / max_depth / type
        Previous value: -"integer"New value: +[
        +  "integer",
        +  "null"
        +]
      • changedInput schema / properties / reverse / type
        Previous value: -"boolean"New value: +[
        +  "boolean",
        +  "null"
        +]
    • Changedlist_repositories1 field changed
      • changedInput schema / properties / filter / type
        Previous value: -"string"New value: +[
        +  "string",
        +  "null"
        +]
    • Changedsearch_hybrid_context2 fields changed
      • changedInput schema / properties / max_results / type
        Previous value: -"integer"New value: +[
        +  "integer",
        +  "null"
        +]
      • changedInput schema / properties / repo_name / type
        Previous value: -"string"New value: +[
        +  "string",
        +  "null"
        +]
  4. 3 tool updatesv1.8.1
    • Changedexplore_file1 field changed
      • changedInput schema / properties / repo_name / description
        Previous value: -"Optional but HIGHLY RECOMMENDED: repository name to filter results to a specific codebase (e.g., 'my-java-repo'). If you know the repository you are working on, include this in your FIRST query to avoid mixed results from other indexed projects. Omit only to search across all repositories."New value: +"Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories."
    • Changedfind_callers1 field changed
      • changedInput schema / properties / repo_name / description
        Previous value: -"Optional but HIGHLY RECOMMENDED: repository name to filter results to a specific codebase (e.g., 'my-java-repo'). If you know the repository you are working on, include this in your FIRST query to avoid mixed results from other indexed projects. Omit only to search across all repositories."New value: +"Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories."
    • Changedsearch_hybrid_context1 field changed
      • changedInput schema / properties / repo_name / description
        Previous value: -"Optional but HIGHLY RECOMMENDED: repository name to filter results to a specific codebase (e.g., 'my-java-repo'). If you know the repository you are working on, include this in your FIRST query to avoid mixed results from other indexed projects. Omit only to search across all repositories."New value: +"Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories."
  5. 1 tool updatev1.5.1
    • Changedexplore_file1 field changed
      • changedInput schema / properties / file_path / description
        Previous value: -"Absolute path to the source file to explore"New value: +"Path to the source file to explore. PREFERRED: a repo-relative path (e.g. 'src/services/user.ts'). ALSO ACCEPTED: an absolute path under the repository's local checkout (the tool strips KNOT_REPO_PATH / CWD automatically)."
  6. 1 tool updatev1.4.11
    • Addedlist_repositories
  7. 4 tool updatesv1.4.0
    • Addedexplore_file
    • Addedfind_callers
    • Addedlist_repo_dependencies
    • Addedsearch_hybrid_context
  8. 4 tool updatesv1.3.8
    • Removedexplore_file
    • Removedfind_callers
    • Removedlist_repo_dependencies
    • Removedsearch_hybrid_context

TDQS

A4.6/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct stage of codebase exploration: repository discovery, file listing, file anatomy, semantic search, reverse call lookup, and cross-repository dependency inspection. The descriptions explicitly define boundaries and warn against using one tool for another's job, leaving little room for misselection.

Naming Consistency4/5

All tools use snake_case and mostly follow a verb_noun pattern such as list_files, find_callers, and explore_file. Minor deviations exist: list_repositories and list_repo_dependencies use different forms of 'repository', and search_hybrid_context is verb_adjective_noun rather than strictly verb_noun.

Tool Count5/5

Six tools is well-scoped for a read-only code intelligence server. Each tool has a clear, non-redundant role in discovery, inspection, search, or dependency analysis.

Completeness4/5

The surface covers repository discovery, file listing, file anatomy, semantic search, reverse callers, and cross-repo build dependencies. Some useful gaps remain, such as forward callee lookup, exact symbol search, or direct source/entity retrieval, though agents can partially work around these via search_hybrid_context and explore_file.

Maintenance

ActivityActive
ResponsivenessWithin a week

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    A complete MCP server for Retrieval-Augmented Generation with file management and vector memory for agents. Supports multiple document formats (PDF, DOCX, TXT, MD, CSV, JSON) with semantic search using Hugging Face embeddings and ChromaDB for efficient vector storage.
    11
    5 npm
    1
    MIT
  • A
    license
    Not graded
    quality
    Not graded
    maintenance
    Turns Claude Desktop into a personal document question-answering system using local vector search. Index PDF, TXT, and Markdown documents into collections and get answers based strictly on your documents with zero hallucination.
    5 npm
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    A graph-powered code intelligence engine that indexes codebases into a structural knowledge graph to provide AI agents with deep context on function calls, types, and execution flows. It offers local, zero-dependency tools for hybrid search, impact analysis, and dead code detection across Python, JavaScript, and TypeScript projects.
    814
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A minimalist indexing tool that provides AI agents with semantic search and structural AST parsing for deep codebase understanding. It enables autonomous agents to navigate large codebases predictably using vector embeddings and native language server capabilities like definition and reference tracking.
    -