Skip to main content
Glama
deenesjakoruzh
ru551n

vhdl-rag-mcp

by ru551n
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

vhdl-rag-mcp

一个 MCP（Model Context Protocol）服务器，为编码智能体提供对组织内 VHDL 代码、VHDL 相关文档以及通用源代码（C/C++、Python 等）的高质量语义搜索——全部相互交叉引用，且具备精确的源码归属。

通过 stdio 以 uvx vhdl-rag-mcp 方式运行。无需任何外部服务：Qdrant 以嵌入式方式运行，嵌入模型在本地运行（通过 FastEmbed 使用 ONNX）。

功能

  • 三个索引域，一个服务器。 VHDL 源代码、文档（Markdown/reST/text）和通用代码（C/C++、Python 等）存放在三个 Qdrant 集合中，每个 chunk 均包含一个稠密向量（jina v2）和一个稀疏向量（BM25）。

  • 混合搜索。 每次查询都运行 Qdrant 原生混合查询（稠密 + 稀疏，RRF 融合）：一次调用同时执行语义相似度匹配与精确标识符匹配。你只输入 rst_n 即可查到。

  • VHDL 感知分块。 VHDL 文件按结构体（entity、architecture、process、package、function、component）分块，使用 vhdl_ls 语言服务器（documentSymbol 提供准确行号范围）；对于含语法错误的文件，则回退到结构化行扫描器；若仍失败则使用整个文件作为最后兜底，确保没有任何 VHDL 被遗漏。

  • 其它内容同样是结构感知分块。 文档按标题区块分块；通用代码按顶层函数/类用 tree-sitter 分块（支持任何带文法的语言），并为未覆盖的顶层代码提供文件作用域 gap chunks。

  • 交叉引用。 每个 chunk 的载荷都会存储其定义或引用的标识符（symbols）。搜索工具接受 symbols 过滤器，匹配任何引用给定标识符的 chunk——在文档 ↔ VHDL ↔ 测试代码之间建立连接（例如，找出所有含 fifo_write 的 VHDL process 和 C 函数）。

  • 优先级感知排序。 存储仓库可带有 category（golden > approved > project > legacy，或显式设置 priority 0–100），对融合得分应用一个有界的加成：参考仓库在出现并列时获胜，但不会掩盖真正的相似度。

  • 精确的源码归属。 每条结果都会带出仓库、文件、行号区间和提交；get_source 能返回同步工作树上的精确当前文件内容（或某个区间）。

  • 渐进式、自维护索引。 仓库通过 Git（clone/fetch/diff）同步；只对发生变化的文件重新分块和重新嵌入。后台任务会每 sync_interval 秒同步一次；这些工具也可随时强制执行同步或完整重建索引。

  • 优雅地降级。 错误按仓库隔离，并记录在状态中；某个仓库出现问题不会阻塞其它仓库或服务器。

  • stdout 完全对协议纯净。 所有日志都输出到 stderr 和轮转日志文件，因此该服务器可安全地从任何 MCP 宿主运行。

Related MCP server: PAMPA

安装

要求：

  • uv（用于 uvx）、Python 3.12 或更高版本

  • Git（对私有仓库，需配置好你的常规凭据/SSH）

  • vhdl_ls 二进制（仅当仓库中包含 VHDL 时才需要）：请从 https://vhdl-lang.org/ 安装 release，让 vhdl_ls 在你的 PATH 中可用， 或将 data_dir 配置的 vhdl_ls_path 指向该二进制。随二进制一同分发的 vhdl_libraries 目录会被自动识别。

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

首次启动时，服务器会创建数据目录，下载嵌入模型（jina v2 base-code + base-en，每个约几十 MB，只需一次），并对所有已配置的仓库执行首轮同步。

配置

配置文件：~/.config/vhdl-rag/config.toml（若不存在，首次运行时会生成带注释的模板）。

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

说明：

  • ref：分支名会在每次卡扣同步时被比对并跟踪更新；标签或提交 SHA 会将仓库固定（完整的 40 位十六进制 SHA 会完全跳卡口网络拉取）。

  • 每仓库的 domains/excludes：只索引该仓库应贡献的范围——例如纯 IP 仓库用 domains = ["vhdl"]，跳过仿真相关文件用 exclude = ["模拟"]。

  • 改变嵌入模型会改变稠密向量的维度；服务器会大声报错并提供可操作的提示，而不是破坏索引（此时需要删除 collection 或 data_dir 再重新索引）。

使用方法

运行服务器

$ uvx vhdl-rag-mcp

它通过 stdio 持续提供 MCP 服务，直到宿主关闭连接；后台任务每隔 sync_interval 秒同步一次所有仓库。单实例锁（data_dir/server.lock）可防止两个服务器共用一个数据目录。

向 MCP 客户端注册

Claude Code：

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

Maki（TOML 配置——请严格按照你的 Maki 版本文档核对确切的表名）：

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

工具

Tool

说明

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

对 VHDL 源码（entity、architecture、process、package、package）进行混合搜索。

search_docs(...)

对文档 section 进行同样的操作，到了 3。

search_code(...)

对通用代码单元（函数 / class）进行相同的搜索。

search_knowledge(query, limit, ...)

一次同时搜索三个 domain，通过 RRF 融合。

get_source(repository, file, start_line, end_line)

返回精确的当前文件内容（或一个切片），并包含提交归属。

repository_status()

每个仓库：category、ref、domains、最后索引提交、最后同步、最后错误。

sync_repositories(repositories?)

增量同步（默认范围搜索：全部）。每个仓库的错误得到隔离。

reindex_repository(repository)

删除并重建某个仓库的索引。

所有搜索工具都支持可选的 repository（名称）和 category （golden/approved/project/legacy）过滤，此外还有 symbols: list[str]—— 只返回引用了这些给定标识符的 chunk。结果以 Markdown 渲染，携带源码归属、得分及 被引用的标识符，并按 domain 进行内容分块。

示例智能体流程：

  1. search_knowledge("asynchronous reset conventions") → 返回一个文档片段及 描述等你实现 VHDL processes。

  2. search_vhdl("reset", symbols=["rst_n"]) → 返回所有触碰 rst_n 的 VHDL chunk。

  3. get_source("company-standards", "rtl/reset_ctrl.vhd", 12, 40) → 返回需要复制 的确切行。

运维

  • 数据目录（data_dir）：Qdrant 集合、每个仓库的 Git 工作树（<name>/）、同步 状态（state/.json）、日志文件（logs/vhdl-rag-mcp.log）和锁文件。删除 它将重置索引。

  • 状态与重试：indexed_commit 只在仓库索引完全成功后才推进；失败的同步会保留 上一次提交，下一次同步会重试相同的 diff。last_sync_error 通过 repository_status 可见。

  • 从配置中移除仓库：下次启动时，服务器检测后会自动删除该仓库的 所有分块和状态。

  • 日志：stderr + logs/repositories.qdrant（轮转 3×5 MB）。log_level = "DEBUG" 可 记录 LSP / git / 嵌入的详细信息。

开发

$ 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

测试套件完全模拟离线运行：本地 file:// Git remote、模拟 LSP 服务端脚本，以及模拟 嵌入提供器（只有一项真实二进制测试由 VHDL_LS_TEST_BIN 环境变量立即）。

布局：

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