Skip to main content
Glama
deenesjakoruzh
ru551n

vhdl-rag-mcp

by ru551n
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

corvidex-mcp

An RTL-centric RAG and indexing MCP.

An MCP (Model Context Protocol) server that gives coding agents high-quality semantic search over an organization's HDL code (VHDL, Verilog, SystemVerilog), HDL-related documentation, and general source code (C/C++, Python, ...) — all cross-referenced, all with exact source attribution.

Runs as an MCP server over stdio (installed from this Git repository with uvx, see Quick start). No external services required: the vector store (SQLite + the sqlite-vec extension) runs embedded and the embedding models run locally (ONNX via FastEmbed). Zero configuration required: point your MCP client at it and it indexes the directory you started your agent in.

Intended use

The main uses are RAG and cross-referencing code against documentation, for coding agents (Claude Code, Maki, or any MCP client) that implement or modify HDL (VHDL, Verilog, or SystemVerilog).

RAG (Retrieval-Augmented Generation). RAG is a technique for keeping a language model grounded in your material instead of only its training data: before (or while) the model generates an answer, it first retrieves relevant chunks from a knowledge base and uses those as context. For a coding agent, that means the context it needs usually lives outside the file it is editing — the company's coding standards, design guides, and reference IP from earlier projects. corvidex-mcp is that retrieval layer: it maintains an up-to-date, semantically searchable index of your repositories and hands the agent the verbatim text (with exact repository, file, line range, and commit) of every match, so the agent grounds its work in what the organization actually wrote instead of hallucinating a plausible pattern.

Cross-referencing code against documentation. This is what makes the search more than three separate indexes: every chunk stores the identifiers it defines or references (symbols), so the agent can bridge the domains — and the HDL languages: a constant shared by a SystemVerilog package, a Verilog module, and a VHDL entity is found once and resolves to all of them. A standard that says "asynchronous resets are named rst_n" can be checked against the VHDL that actually uses rst_n and the C testbench that drives it; a signal renamed in the RTL can be found in every doc section and test function that still references the old name. In practice that means:

  • Docs → code. Follow a convention from the standard to every VHDL construct and test function that implements it.

  • Code → docs. Find the design rationale behind an implementation: given a process or function, which documentation section explains its convention.

  • Consistency. Trace one identifier (e.g. wr_ptr) across standard, RTL, and testbench so a rename or protocol change doesn't leave the domains out of sync.

Both uses rely on the index staying current: repositories are Git synced (branch-tracked or pinned to a tag/SHA) automatically in the background, so the context an agent retrieves reflects the code as it is, not a stale snapshot.

Related MCP server: PAMPA

Capabilities

  • Three indexed domains, one server. HDL source (VHDL, Verilog, and SystemVerilog in one hdl collection, each chunk tagged with its language), documentation (Markdown/reST/text), and general code (C/C++, Python, ...) live in three SQLite collections (a vec0 vector table + an FTS5 full-text table each). Every query runs a hybrid (dense + full-text, RRF-fused) search: semantic similarity and exact identifier matching in one call. Ask about rst_n and you get it.

  • Query expansion and reranking. Queries are expanded with a static RTL/HDL synonym lexicon before search (clock also matches clk, generic also matches parameter, ...), and the fused candidates are reranked by a cross-encoder for higher precision than RRF fusion alone — both on by default and both degrade gracefully (a reranker that isn't provisioned yet falls back to the unreranked ranking rather than failing the search).

  • HDL-aware chunking. VHDL files are chunked per construct (entity, architecture, process, package, function, component) using the vhdl_ls language server (documentSymbol with exact line ranges); Verilog and SystemVerilog are chunked by Veridian (module/program/interface, package, inner functions and tasks, normalized to the same cross-language model — module → design_unit, always_ff → process — with the server-native kind kept as native_symbol_kind). Both have a structural line-scanner fallback for files with syntax errors, and a whole-file last resort so no HDL is ever lost.

  • Structure-aware chunking elsewhere. Documentation is chunked per heading section; general code is chunked per top-level function/class by tree-sitter (any language with a grammar), with file-scope gap chunks for uncovered top-level code.

  • Cross-referencing. Every chunk payload stores the identifiers it defines or references (symbols). Search tools accept a symbols filter that matches chunks referencing the given identifiers — bridging docs ↔ HDL ↔ test code (e.g. find every construct that touches fifo_write), and across HDL languages (e.g. FIFO_DEPTH in a VHDL generic, a Verilog localparam, and an SV package constant).

  • Optional HDL analyzers, graceful degradation. vhdl_ls and Veridian are external binaries that are not bundled or installed by this server: each is located via its config path or on PATH, and when one is missing its files simply fall back to structural/generic parsing. repository_status reports each analyzer's availability, version, and mode (lsp or fallback).

  • Exact source attribution. Every result names repository, file, line range, and commit; get_source returns the exact current file (or a line range) from the synced working tree.

  • Incremental, self-maintaining index. Repositories are synced from Git (clone/fetch/diff): only changed files are re-chunked and re-embedded. A background task keeps everything up to date; the tools can force a sync or a full reindex at any time.

  • Graceful degradation. Failures are contained per repository and recorded in state; a broken repository never blocks the others or the server. A missing language-server binary degrades that analyzer to structural parsing (see above) instead of failing.

  • Stdout is protocol-clean. All logging goes to stderr and a rotating log file, so the server is safe to run from any MCP host.

Quick start

Requirements: uv (for uvx), Python ≥ 3.12, and Git. vhdl_ls/Veridian are optional (VHDL/Verilog files fall back to structural parsing without them). See docs/configuration.md for the full platform matrix and air-gapped installs.

Register the server with your MCP client — no config file needed.

Claude Code:

$ claude mcp add corvidex-mcp -- uvx --from git+ssh://git@github.com/ru551n/corvidex-mcp.git corvidex-mcp

Maki (TOML config — verify the exact table names against your Maki version's docs):

[mcp_servers.corvidex_mcp]
command = "uvx"
args = ["--from", "git+ssh://git@github.com/ru551n/corvidex-mcp.git", "corvidex-mcp"]

That's it: the server indexes the directory it is started in. Since your MCP client normally spawns it with your project as the working directory, starting your agent inside your repository is enough — a Git checkout is indexed as its working tree (HEAD plus uncommitted and untracked changes), a plain directory as a bag of files. Confirm what got indexed with the repository_status tool.

Don't want that? Disable it with --no-index-cwd on the command line, or index_cwd = false in the config file, and run with an empty index until you configure [[repositories]] explicitly. Need more than the current directory — multiple repositories, a remote Git URL, a coding-standards file, tuned embedding settings? See docs/configuration.md; add a config file at ~/.config/corvidex/config.toml (or point --config/ CORVIDEX_MCP_CONFIG elsewhere) and any [[repositories]] you configure there take over from the zero-config default.

Usage

Tools

Tool

What it does

search_hdl(query, limit, repository, symbols, language, mode)

Search over HDL source (VHDL, Verilog, SystemVerilog): design units (entities/modules), architectures, processes/always blocks, packages, functions, tasks. language filters by HDL language.

search_vhdl(query, limit, repository, symbols)

search_hdl restricted to VHDL (back-compat name).

search_docs(...)

Same over documentation sections.

search_code(...)

Same over general code units (functions/classes).

search_knowledge(query, limit, ...)

All three domains at once, RRF-fused.

get_source(repository, file, start_line, end_line)

Exact current file content (or a slice) with commit attribution.

repository_status()

Per repository: ref, priority, domains, last indexed commit, last sync, last error — plus the HDL analyzer status (vhdl_ls, Veridian: available, version, lsp/fallback mode) and the per-collection embedding-model state.

sync_repositories(repositories?)

Incremental sync (default: all). Failures contained per repository.

reindex_repository(repository)

Drop and rebuild one repository's index.

All search tools take an optional repository (name) filter plus symbols: list[str] — restrict results to chunks referencing any of the given identifiers. search_hdl/search_knowledge additionally accept language (e.g. "verilog") to restrict results by language. Every search tool also takes mode: hybrid (default; semantic + full-text, RRF-fused), semantic (embedding similarity only), or lexical (full-text match only; no embedding involved). Results are rendered as markdown with source attribution, score, language, and referenced identifiers; HDL content is fenced by language.

Example agent flow:

  1. search_knowledge("asynchronous reset conventions") → a docs section plus VHDL and Verilog constructs that implement resets.

  2. search_hdl("reset", symbols=["rst_n"]) → every HDL chunk touching rst_n, in every HDL language.

  3. search_hdl("fifo", language="systemverilog") → only SystemVerilog.

  4. get_source("company-standards", "rtl/reset_ctrl.vhd", 12, 40) → the exact lines to copy.

Still indexing?

The server starts serving immediately; it does not wait for the initial sync to finish (that can take a while for a large repository — files need to be parsed, chunked, and embedded). While a repository hasn't completed its first sync yet, or is being (re)synced right now, search results start with a line like:

Note: currently syncing: my-repo. Results may be thin or incomplete; try again shortly.

Treat it as a cue to wait a few seconds and retry, not as "nothing exists". Use repository_status to check indexing progress (and whether a sync is failing outright rather than just running).

Configuration

Zero configuration is required (see Quick start). Once you need more — multiple repositories, a remote Git URL, a coding-standards file, embedding-model tuning, air-gapped installs — see docs/configuration.md for the full config file reference.

Development

$ uv sync
$ uv run ruff format -q . && uv run ruff check .   # format + lint
$ uv run mypy src                                   # strict types
$ uv run pytest -q                                  # offline test suite

The test suite runs fully offline: local file:// git remotes, fake LSP server scripts (vhdl_ls and Veridian), and fake embedding providers (real-binary tests are gated on the VHDL_LS_TEST_BIN and VERIDIAN_TEST_BIN environment variables).

CI (.github/workflows/ci.yml) runs on every push to main and on pull requests: ruff format --check, ruff check, mypy (strict), and the full test suite on Ubuntu and Windows (Python 3.12/3.13/3.14) and macOS (CPython 3.14: uv's standalone 3.12/3.13 macOS interpreters lack SQLite loadable-extension support, so the store-dependent tests would skip wholesale there), plus RHEL 9 and RHEL 10 container jobs (official UBI images; UBI 9's glibc 2.34 is the strictest floor in the dependency wheel set).

Layout:

src/corvidex_mcp/
  config.py        typed config (pydantic) + default template
  state.py         atomic repository sync state (schema-versioned)
  git_manager.py   async clone/fetch/checkout + incremental SyncPlan
  routing.py       extension -> domain classification (+domains/excludes)
  lsp/             LSP transport (server-agnostic) + vhdl_ls and Veridian
                   adapters + analyzer discovery/status
  embeddings/      FastEmbed dense providers (per-collection, lazy)
  vector_store.py  sqlite-vec wrapper: hybrid (dense + FTS5) RRF query,
                   row filters
  indexing/        vhdl (vhdl_ls), verilog (Veridian), docs (sections),
                   code (tree-sitter), pipeline (incremental sync driver)
  retrieval.py     search service: fusion, language filter, source access
  server.py        FastMCP tools + startup + periodic sync + lock

Available Tools

8 tools
get_sourceA
Read-only

Read the exact current content of an indexed file (or a line range) from the synced repository, with commit attribution. file is the repository-relative path from any search result's source line.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYes
end_lineNo
repositoryYes
start_lineNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

The annotation `readOnlyHint=true` already signals a safe read operation. The description goes beyond this by noting that it returns exact current content and includes commit attribution, which tells the agent more about what to expect without repeating the annotation.

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 two focused sentences with no fluff. The primary action and subject are front-loaded, and the value add about `file` is kept brief.

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

Completeness4/5

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

With `readOnlyHint` set, an existing output schema, and a fairly simple parameter shape, the description gives most of what an agent needs to use the tool after a search. The remaining gaps are the exact form of `repository` and line-range boundary behavior, which are useful but not crippling.

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 0%, so the description partially compensates: it clearly explains `file` as the repository-relative path from a search result and introduces the concept of line ranges. However, `repository` is left only with its name, and start/end line semantics are not fully specified.

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 names a specific verb ('Read') and resource ('indexed file' with optional line range), and places it cleanly in the repository/search context. It is clearly distinguishable from sibling search and repository-maintenance tools.

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?

The description gives concrete usage context by explaining that `file` comes from a search result's source line, and that the tool reads from a synced repository. It does not explicitly list alternative tools or when not to use it, but the intended workflow is evident.

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

reindex_repositoryB

Fully reindex one repository (drops and rebuilds all of its chunks). Use after config changes or to repair a drifted index.

ParametersJSON Schema
NameRequiredDescriptionDefault
repositoryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior1/5

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

The description says the tool 'drops and rebuilds all of its chunks', which is destructive behavior, but the annotations set destructiveHint=false. This contradicts the annotation and leaves the agent with conflicting signals about whether the tool is safe or destructive.

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

Conciseness5/5

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

The description is a single front-loaded sentence: it starts with 'Fully reindex one repository', adds an essential parenthetical about destructiveness, and then a concrete use case. Every phrase contributes value with no waste.

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?

An output schema exists so return values need no explanation, and the single repository parameter is simple. However, the clash between the description's 'drops' language and the destructiveHint false annotation undermines the tool's overall safety context, and the parameter format remains underspecified.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explicitly explain how the 'repository' parameter should be identified, whether it is a name, ID, or path. It only repeats that 'one repository' is reindexed, so it does not compensate for the lack of parameter documentation.

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, 'reindex', a resource, 'repository', and the precise scope: 'fully', 'drops and rebuilds all of its chunks'. It also names concrete use cases, making it clearly distinguishable from the sibling search/status/sync tools.

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?

It explicitly says when to use the tool: 'after config changes or to repair a drifted index'. However, it does not explicitly mention when not to use it or direct the user to a sibling alternative, but the use case is clear enough.

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

repository_statusA
Read-only

Show every configured repository: category, ref, enabled domains, last indexed commit, last sync time, and any sync error.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

The readOnlyHint annotation already provides the key safety trait. The description adds that the tool lists all configured repositories and includes sync error state, which is useful context, but does not address more specific behaviors like pagination or result size limits. No contradiction with annotations.

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?

One clear, front-loaded sentence that states the action first, then lists the output fields. Every word earns its place and there is no filler.

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 zero-parameter, read-only listing tool with a readOnlyHint annotation and an output schema, this description fully communicates what the tool does and what the agent should expect. No critical gaps remain.

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 tool has zero parameters and the schema is empty, so there is no parameter burden on the description. Baseline of 4 is appropriate for a no-parameter tool; nothing further is needed.

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?

Description starts with a clear verb ('Show') and identifies the resource ('every configured repository'), then enumerates the exact fields returned. It is easy to distinguish from sibling tools that search, sync, or reindex.

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

Usage Guidelines3/5

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

The description implies that this tool is for inspecting repository state, but it does not explicitly say when to use it instead of sync_repositories or reindex_repository. The read-only status context is clear but no alternatives or exclusion conditions are stated.

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

search_codeA
Read-only

Search general source code (C/C++, Python, ...): one result per function/class. symbols matches identifiers referenced in the unit (cross-reference to VHDL signal/port names, etc.).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
symbolsNo
categoryNo
repositoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

The readOnlyHint annotation already covers the read-only nature. The description adds meaning beyond that by clary specifying the result granularity ('one result per function/class') and the special behavior of 'symbols' (matches identifiers referenced in the unit). This gives useful behavioral details not present in the annotations concurrently.

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

Conciseness5/5

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

The description is a concise two-sentence block. The first sentence says what the tool does and states its granularity, while the second explains the non-obvious 'symbols' parameter behavior. Every sentence carries functional value and the core purpose is frontal-loaded.

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?

The tool has five parameters but only one is required and their semantics are mostly absent; the description explains only one optional parameter. The tool has an output schema, so return exploitation is not needed, but the optional `category', 'repository', and 'limit' parameters remain unclear, leaving a evaluable operational gap.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It only clarifies 'symbols'; the meaning of 'query', 'limit', 'category', and 'repository' remains undocumented. Given five parameters and zero schema descriptions, this is insufficient for an agent to use all capabilities with confidence.

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 action ('Search general source code') and specifies the resource (C/C++, Python) and a distinctive granularity ('one result per function/class'). It is also differentiates from siblings like search_docs, search_vhdl, and search_knowledge by being the general code search.

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?

The description implies when to use this tool: for general source-code search rather than docs, VHDL, or knowledge searches. It does not explicit name alternatives or provide exclusion rules, but the resource scope and the symbol matching note give adequate context for most agent decisions.

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

search_docsB
Read-only

Search VHDL-related documentation: coding standards, design guides, conventions (one result per section). symbols matches identifiers referenced in the section's code snippets.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
symbolsNo
categoryNo
repositoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, so the risk profile is covered. The description adds some behavioral context, notably one-result-per-section behavior and how the symbols parameter matches code snippet identifiers, but it does not describe pagination, output structure, or any special matching behavior for the regular query.

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?

Two succinct sentences convey the tool's domain, content scope, result granularity, and a special parameter behavior. Every clause earns its place and there is no fluff or resuppLI.

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?

The description is usable for a read-only documentation search, but context is incomplete: the category and repository parameters are undefined, there is no guidance about how the tool relates to the sibling search tools, and the meaning of 'one result per section' is not expanded enough to set why that limitation matters.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only explains the symbols parameter; query, limit, category, and repository receive no semantic explanation beyond their raw names and defaults. This leaves a significant gap for an agent choosing how to populate the parameters.

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 uses a specific verb 'Search' and identifies a domain/resource, 'VHDL-related documentation', while enumerating content types: coding standards, design guides, conventions. It is clear, though it does not explicitly differentiate itself from the sibling tool search_vhdl.

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

Usage Guidelines2/5

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

The description communicates a search scope but does not indicate when to use this tool versus alternatives like search_code, search_knowledge, or the similarly named search_vhdl. There are no explicit conditions or exclusion criteria provided.

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

search_knowledgeA
Read-only

Search ALL domains (VHDL, documentation, code) at once, fused with RRF so the domains interleave fairly. Use when the question may span domains (e.g. a design requirement in the docs implemented in VHDL and tested in C).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
symbolsNo
categoryNo
repositoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description supplements this with useful behavioral detail: all domains are searched at once and results are fused via RRF for fair interleaving. This goes beyond the structured annotation without contradicting it.

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 two tight sentences: the first states the core behavior, and the second gives a usage criterion and concrete example. There is no filler, fluff, or repetition of schema/annotation details.

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?

It is adequately complete for tool selection: it says what the tool searches, how it combines results, and when to use it. However, the shape has 5 undocumented parameters and an output schema, so an agent still lacks detail on what symbols/category/repository constrain and what an RRF fusion result looks like

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

Parameters2/5

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

Schema parameter description coverage is 0%, so the description carries the burden of documenting parameters, but it never mentions limit, symbols, category, or repository. Only 'query' behavior is implied through 'Search ALL domains...', leaving agents to guess what the optional filters do.

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 a specific verb and clear scope: 'Search ALL domains (VHDL, documentation, code) at once'. It also names a concrete behavior, RRF fusion, which distinguishes this tool from domain-specific siblings like search_docs and search_code.

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?

The description gives explicit guidance: 'Use when the question may span domains' and provides a realistic cross-domain example. It does not explicitly name the domain-specific alternatives or say when not to use this tool, but the intended use case is conveyed clearly enough.

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

search_vhdlA
Read-only

Search VHDL source: entities, architectures, processes, packages, functions — semantic + exact-identifier hybrid search. symbols restricts to chunks referencing the given identifiers (e.g. ["fifo_write", "rst_n"]). category: golden/approved/ project/legacy. repository restricts to one repository name.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
symbolsNo
categoryNo
repositoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already mark this as read-only, and the description adds valuable behavioral details: the search is hybrid semantic/exact, symbols restrict to chunks referencing identifiers, and category/repository narrow results. It does not describe index-freshness limitations, but output schema and read-only promise reduce that burden.

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 front-loaded with purpose, then dives into parameter semantics with backtick highlighting and a concrete `symbols` example. Every sentence contributes value, though the combination of hybrid-search jargon and parameter explanations makes it dense rather than simple.

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

Completeness4/5

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

For a read-only search tool, the description covers the core behavior and all non-obvious filters. The presence of an output schema means the return-value structure is already handled externally. A brief note on indexed-repository freshness or when to prefer search_code would improve completeness, but this is enough for correct invocation.

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?

Given the input schema has 0% description coverage, the description compensates for `symbols`, `category`, and `repository` with concrete semantics and a useful example. `query` is naturally explained by the search purpose, and `limit` has an obvious default and title, leaving no major ambiguous parameters.

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 a clear action and resource: 'Search VHDL source: entities, architectures, processes, packages, functions'. It also distinguishes the tool from generic search siblings by confining it to VHDL and promising a hybrid semantic/exact-identifier behavior.

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?

The VHDL-specific phrase immediately signals when to use the tool—when searching VHDL source constructs—but no alternative tools or exclusions are named. This is clear context, yet lacks the explicit sibling routing that would earn a 5.

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

sync_repositoriesA

Incrementally sync repositories (default: all): fetch the ref, chunk changed files, update the index. Safe to call any time; failures are contained per repository and reported.

ParametersJSON Schema
NameRequiredDescriptionDefault
repositoriesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description does not contradict them. It adds useful behavioral detail beyond the annotations: the sync updates the index, explicitly signals reusability ('safe to call any time'), and discloses containment of failures per repository.

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 short, immediately front-loads the core action, and each clause adds a distinct piece of information: scope, mechanism, safety, and failure containment. There is no fluff or repeated schema content.

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 simple one-parameter operation with an output schema present, the description covers the core behavior, the optional input semantics, and failure behavior. Nothing critical is missing for an agent to decide whether and how to invoke it.

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 0% and no property descriptions are present. The description clarifies the important default behavior ('default: all') and implies that the optional 'repositories' list filters which ones are synced, but it does not add detail about the expected string format or how omitted values behave beyond the default. It partially compensates for the schema gap.

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

Purpose5/5

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

The description clearly states the verb ('sync'), the resource ('repositories'), and the mechanism ('fetch the ref, chunk changed files, update the index'). The word 'incrementally' meaningfully distinguishes it from a full rebuild and brings out the tool's intended scope.

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?

It gives clear usage context: callable any time, defaults to all repositories, and supports an optional subset list. It does not explicitly name alternatives or state when not to use it, but 'incremental' and 'safe to call any time' provide enough orientation for an agent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv0.1.0
    • First observedget_source
    • First observedreindex_repository
    • First observedrepository_status
    • First observedsearch_code
    • First observedsearch_docs
    • First observedsearch_knowledge
    • First observedsearch_vhdl
    • First observedsync_repositories
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool has a clearly distinct role: domain-scoped searches (docs, VHDL, code) are separated from a fused all-domain search, and source retrieval plus sync/reindex operations are unambiguous. The descriptions reinforce the boundaries, so an agent should rarely misselect.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern: search_docs, search_vhdl, search_code, search_knowledge, get_source, sync_repositories, and reindex_repository. repository_status breaks the pattern by using a noun phrase, but the overall naming is still predictable and readable.

Tool Count5/5

Eight tools is well-scoped for a RAG/search MCP server: domain-specific searches, a combined search, source retrieval, status, and index maintenance each earn their place. There is no obvious bloat or redundancy.

Completeness5/5

The server covers the full expected surface for VHDL RAG: searching documentation, VHDL source, general code, and all domains together, plus retrieving exact source content and managing repository indexing state. The sync and reindex tools close the otherwise common operational gap.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • MCP Indexer

    gkatechis
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables semantic code search across multiple repositories using natural language queries. Provides intelligent code discovery, symbol lookups, and cross-repo dependency analysis for AI coding agents.
    MIT

  • PAMPA

    tecnomanu
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides semantic code search and retrieval capabilities for AI agents, enabling them to query codebases using natural language with automatic learning, hybrid search, and intelligent chunking of functions and classes.
    16
    29
    ISC

  • 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
    -

  • codesearch

    shahpnmlab
    F
    license
    Not graded
    quality
    C
    maintenance
    Semantic search over local source repositories and forum archives, exposing tools to list sources, search code, read code, and search forum discussions.
    -

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ru551n/corvidex-mcp'

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