Skip to main content
Glama
deenesjakoruzh
ru551n

vhdl-rag-mcp

by ru551n
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

vhdl-rag-mcp

Un servidor MCP (Model Context Protocol) que ofrece a los agentes de programación una búsqueda semántica de alta calidad sobre el código VHDL de una organización, la documentación relacionada con VHDL y el código fuente general (C/C++, Python, ...) — todo con referencias cruzadas y con atribución exacta de la fuente.

Se ejecuta como uvx vhdl-rag-mcp por stdio. No se requieren servicios externos: Qdrant se ejecuta embebido y los modelos de embeddings se ejecutan localmente (ONNX mediante FastEmbed).

Capacidades

  • Tres dominios indexados, un único servidor. El código fuente de VHDL, la documentación (Markdown/reST/texto) y el código general (C/C++, Python, ...) residen en tres colecciones de Qdrant, cada una con un vector denso (jina v2) y un vector disperso (BM25) por fragmento.

  • Búsqueda híbrida. Cada consulta ejecuta la búsqueda híbrida nativa de Qdrant (denso + disperso, fusionada con RRF): la similitud semántica y la coincidencia exacta de identificadores en una sola llamada. Pregunta por rst_n y lo obtienes.

  • Segmentación específica de VHDL. Los archivos VHDL se dividen en fragmentos por constructo (entidad, arquitectura, proceso, paquete, función, componente) mediante el servidor de lenguaje vhdl_ls (documentSymbol con rangos de línea exactos), con un escáner estructural de líneas como alternativa para archivos con errores de sintaxis, y un último recurso que indexa el archivo completo para que nunca se pierda código VHDL.

  • Segmentación estructural en el resto de contenidos. La documentación se divide en fragmentos por sección de encabezado; el código general se divide por función/clase de nivel superior mediante tree-sitter (cualquier lenguaje con una gramática), con fragmentos de relleno de ámbito de archivo para el código de nivel superior no cubierto.

  • Referencias cruzadas. La carga de cada fragmento almacena los identificadores que define o a los que referencia (symbols). Las herramientas de búsqueda aceptan un filtro symbols que restringe los resultados a los fragmentos que referencia los identificadores dados — pertencenting un puente entre documentación ↔ VHDL ↔ código de prueba (por ejemplo, encontrar cada proceso VHDL y función en C que toquen fifo_write).

  • Ranking con prioridad. Los repositorios tienen una categoría (golden > approved > project > legacy) o una priority explícita de 0 a 100 que aplica una bonificación acotada a la puntuación fusionada: los repositorios de referencia ganan los empates de relevancia sin ahogar la similitud real.

  • Atribución exacta de la fuente. Cada resultado nombra repositorio, archivo, rango de líneas y commit; get_source devuelve el contenido exacto del archivo actual (o un rango de líneas) desde el árbol de trabajo sincronizado.

  • Índice incremental y que se mantiene solo. Los repositorios se sincronizan desde Git (clone/fetch/diff): solo los archivos modificados se vuelven a fragmentar y se vuelven a generar sus embeddings. Una tarea en segundo plano sincroniza cada sync_interval segundos; las herramientas pueden forzar una sincronización o un reindexado completo en cualquier momento.

  • Degradación controlada. Los fallos se aíslan por repositorio y se registran en el estado; un repositorio roto no bloquea a los demás ni al servidor.

  • Salida estándar limpia de protocolo. Todo el logging va a stderr y a un archivo de registro rotativo, por lo que el servidor se puede ejecutar desde cualquier host MCP.

Related MCP server: PAMPA

Instalación

Requisitos:

  • uv (para uvx), Python ≥ 3.12

  • Git (con tus credenciales normales o configuración SSH para repositorios privados)

  • El binario vhdl_ls (solo necesario en los repositorios que contengan VHDL): instal una release desde https://vhdl-lang.org/ para tener vhdl_ls en tu PATH, o indica en vhdl_ls_path la ruta al binario. El directorio vhdl_libraries que se distribuye junto al binario se detecta automáticamente.

$ uvx vhdl-rag-mcp --help
# (the server speaks MCP over stdio; --help is not a flag — see "Usage")

En el primer arranque el servidor crea su directorio de datos, descarga los modelos de embeddings (jina v2 base-code + base-en, ~decenas de MB cada uno, una sola vez) y realiza la sincronización inicial de todos los repositorios configurados.

Configuración

Archivo de configuración: ~/.config/vhdl-rag/config.toml (se crea con una plantilla comentada en el primer arranque si no existe).

data_dir = "~/.local/share/vhdl-rag"   # all state lives here
sync_interval = 300                    # seconds between periodic syncs
vhdl_ls_path = "vhdl_ls"               # binary on PATH or full path
log_level = "INFO"

[embeddings]
vhdl_model = "jinaai/jina-embeddings-v2-base-code"  # per-collection dense models
docs_model = "jinaai/jina-embeddings-v2-base-en"
code_model = "jinaai/jina-embeddings-v2-base-code"
sparse_model = "Qdrant/bm25"           # one shared sparse model

[qdrant]
mode = "local"                         # embedded (default) — or "server" with url
# url = "http://qdrant:6333"

[[repositories]]
name = "company-standards"             # unique, [A-Za-z0-9._-]
url = "git@github.com:company/vhdl-standards.git"
ref = "main"                           # branch (tracked on every sync),
                                       # tag, or commit SHA (pinned)
category = "golden"                    # golden | approved | project | legacy
priority = 100                         # optional 0-100 (defaults by category:
                                       # golden=100, approved=90, project=70, legacy=20)
# domains = ["vhdl", "docs", "code"]   # which domains to index (default: all)
# exclude = ["sim", "build/*", "*.log"]# glob path excludes ('*' crosses '/');
                                       # wildcard-free patterns exclude the subtree

Notas:

  • ref: se obtiene y se mantiene el seguimiento de una rama en cada sincronización. Una etiqueta o un SHA de commit fija el repositorio (un SHA hexadecimal completo de 40 caracteres evita por completo la operación de red).

  • Dominios/exclusiones por repositorio: indexa solo lo que un repositorio debería aportar; por ejemplo, domains = ["vhdl"] for a pure IP repository and exclude = ["sim"] para omitir archivos solo de simulación.

  • Cambiar los modelos de embeddings cambia the dimension of the vector denso; el servidor falla de forma evidente y con un mensaje accionable en lugar de corromper el índice (elimina la colección o data_dir y vuelve a indexar).

Uso

Ejecutar el servidor

$ uvx vhdl-rag-mcp

El servidor sirve MCP por stdio hasta que el host cierra la conexión; una tarea en segundo plano sincroniza todos los repositorios cada sync_interval segundos. Un candado de instancia única (data_dir/server.lock) evita que dos servidores compartan el mismo directorio de datos.

Registrar en un cliente MCP

Claude Code:

$ claude mcp add vhdl-rag-mcp -- uvx vhdl-rag-mcp

Maki (configuración TOML: verifica los nombres exactos de las tablas en la documentación de tu versión de Maki):

[mcp_servers.vhdl_rag_mcp]
command = "uvx"
args = ["vhdl-rag-mcp"]

Herramientas

Herramienta

Descripción

search_vhdl(query, limit, repository, category, symbols)

Búsqueda híbrida en el código fuente de VHDL (entidades, arquitecturas, procesos, paquetes, funciones).

search_docs(...)

Igual sobre las secciones de documentación.

search_code(...)

Igual sobre las unidades de código general (funciones/clases).

search_knowledge(query, limit, ...)

Los tres dominios a la vez, fusionados con RRF.

get_source(repository, file, start_line, end_line)

Contenido exacto del archivo actual (o de un rango de líneas) con atribución del commit.

repository_status()

Por repositorio: categoría, ref, dominios, último commit indexado, última sincronización, último error.

sync_repositories(repositories?)

Sincronización incremental (default: todos). Los fallos quedan aislados por repositorio.

reindex_repository(repository)

Elimina y reconstruye el índice de un repositorio.

Todas las herramientas de búsqueda aceptan los filtros opción repository (nombre), category (golden/approved/project/legacy) y symbols: list[str], que restringe los resultados a los fragmentos que referencien cualquiera de los identificadores indicados. Los resultados se muestran en Markdown with attribution of the source, score e identificadores referenciados; the content goes separated by domain.

Example of agent flow:

  1. search_knowledge("asynchronous reset conventions") → una sección de documentación y los procesos VHDL que implementan resets.

  2. search_vhdl("reset", symbols=["rst_n"]) → todos los fragmentos VHDL que hagan referencia rst_n.

  3. get_source("company-standards", "rtl/reset_ctrl.vhd", 12, 40) → the exact borders of the copy.

Operations

  • Directorio de datos (data_dir): colecciones de Qdrant, árboles de trabajo Git de cada repositorio (<name>/), estado de sincronización (state/repositories.json), archivo de registro (logs/vhdl-rag-mcp.log) y candado. Eliminarlo restablece el índice.

  • Estado y reintentos: el indexed_commit de un repositorio solo avanza cuando la actualización de su índice finaliza correctamente; una sincronización fallida conserva el commit anterior y la siguiente sincronización vuelve a intentar el mismo diff. last_sync_error es visible mediante repository_status.

  • Eliminar un repositorio de la configuración: en el siguiente arranque el servidor lo detecta en el archivo de estado y elimina automáticamente todos sus fragmentos y su estado.

  • Registro: stderr + logs/vhdl-rag-mcp.log (rotatorio, 3×5 MB). Ajusta log_level = "DEBUG" para ver el detalle de LSP/git/embeddings.

Desarrollo

$ 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

La suite de pruebas se ejecuta completamente sin conexión: remotos Git locales con file://, un servidor LSP simulado y proveedores de embeddings simulados (una prueba con binario real se sutorna mediante la variable de entorno VHDL_LS_TEST_BIN). The "Layout:" section:

Structure:

src/vhdl_rag_mcp/
  config.py        typed config (pydantic) + default template
  state.py         atomic repository sync state
  git_manager.py   async clone/fetch/checkout + incremental SyncPlan
  routing.py       extension -> domain classification (+domains/excludes)
  lsp/client.py    vhdl_ls LSP client (handshake, quiet-wait, symbols)
  embeddings/      FastEmbed dense/sparse providers (per-collection + shared)
  vector_store.py  Qdrant wrapper: hybrid RRF query, payload filters
  indexing/        vhdl (LSP-primary), docs (sections), code (tree-sitter),
                   pipeline (incremental sync driver)
  retrieval.py     search service: fusion, priority bonus, 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