opencode-document-rag-mcp

by humbertolvarona

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: listing documents, ingesting a single document, ingesting all documents, searching, reading a section, and checking index status. The only potential overlap (ingest_document vs. ingest_all_documents) is clearly resolved by singular vs. plural scope, leaving no ambiguity for an agent.
Naming Consistency4/5
Most tools follow a verb_noun pattern (list_, ingest_, search_, read_), but 'index_status' deviates by starting with a noun. Despite this minor inconsistency, all names are lowercase, underscore-separated, and self-descriptive, so the pattern remains predictable.
Tool Count5/5
With only 6 tools, the server is well-scoped for a document RAG system. Each tool addresses a distinct step in the workflow—discovery, ingestion (single and bulk), retrieval, reading, and status monitoring—without redundancy or excess.
Completeness4/5
The surface covers the core lifecycle: listing available documents, ingesting new ones (single or all), searching indexed content, reading specific sections, and checking index status. Missing delete/update operations are minor gaps since the server focuses on additive indexing and retrieval, which is acceptable for its purpose.
Average 3.3/5 across 6 of 6 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only mentions the mdDB exclusion, but omits side effects (e.g., whether it modifies existing documents, idempotency, or the effect of the force parameter). 'Synchronize' implies mutation but does not clarify reversibility or safety.
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?
Description is a single sentence with zero fluff. The key action and exclusion are front-loaded, and every word contributes meaning. Perfectly concise for its scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no annotations, the description is insufficient. It explains the core action but leaves the force parameter unexplained and provides no usage context. The presence of an output schema does not compensate for missing parameter semantics and usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'force' (boolean, optional, default false), is not mentioned in the description. Since schema description coverage is 0%, the description must compensate but fails to explain what 'force' does (e.g., force re-ingestion). This is a significant gap.
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?
Description states a specific verb ('Synchronize') and resource ('supported DOCS documents') and adds a meaningful exclusion (mdDB output directory). It is clear enough to distinguish from the singular ingest_document by implying bulk action, though it doesn't explicitly say 'all'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like ingest_document (per-document) or search_documents. The description does not mention any conditions or alternatives, leaving the decision entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state that the tool returns 'complete Markdown sections', which informs the agent about the output nature. However, it omits any details about side effects (probably none since it's a search), error behavior, pagination, or limitations. Since it's a search tool, the read-only behavior is obvious but not explicitly stated. The disclosure is minimal but not misleading.
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 with no redundant words. It immediately states the action and the output. This is ideal conciseness – every word earns its place. Nothing is fluff, and it is structured to be read quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three parameters, with an output schema existing), the description is incomplete. It fails to cover parameter semantics, usage scenarios, and behavioral expectations beyond the basic output type. While the presence of an output schema may document the return structure, the description does not help the agent understand when to use the tool or how to fill in the parameters. It is adequate only for recognizing the tool's existence, not for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero information about the three parameters (query, top_k, document_name). It does not explain what the query should contain, how top_k affects results, or what document_name filters. The agent must rely solely on the schema definitions (which have types and defaults but no semantic meaning). The description adds no value beyond what the schema already provides.
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 clearly states a specific action ('Search ChromaDB') and a specific output ('complete Markdown sections containing nearby tables and LaTeX equations'). This distinguishes it from sibling tools like list_documents or ingest_document, as it focuses on retrieval of content sections rather than listing or ingesting. However, it could be more precise about the semantic nature of the search and what 'nearby' implies, so not a 5.
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 offers no guidance on when to use this tool versus its siblings. It does not mention alternatives, prerequisites, or scenarios where this tool is preferred. While the purpose implies it's the tool for searching documents, there is no explicit direction such as 'use this to find relevant sections' or 'use list_documents to browse available documents'. This leaves the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Read' implying a read‑only operation, but it does not explicitly confirm that no modifications occur, nor does it describe error behavior, return format (though an output schema exists), or any side effects. For a tool with no safety annotations, this is a significant transparency gap.
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 with no filler. It states the primary action first and conveys the essential selection criterion without any extraneous words. This is an exemplar of concise, efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simple nature, the description omits critical details: the format of the breadcrumb path, how to handle missing documents or sections, and what the output contains. With no schema descriptions and no annotations, the agent lacks sufficient context to reliably construct correct arguments and interpret results. The existence of an output schema does not compensate for the missing operational guidance.
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 for unrecognized parameters. It mentions 'breadcrumb path' which gives a hint about section_path, but it fails to explain the expected format (e.g., delimiters, hierarchy) or how document_name should be specified. Both parameters are undocumented in the schema and only minimally addressed by the description, leaving the agent to guess.
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 uses a specific verb ('Read') and identifies the resource ('one complete section from the stored Markdown') and the selection mechanism ('breadcrumb path'). This clearly differentiates it from siblings like list_documents (listing), ingest_document (creating), and search_documents (searching). An agent can immediately grasp the tool's function without needing additional context.
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 when to use the tool (when you need a specific section by breadcrumb path) but does not explicitly state when not to use it or mention alternatives. It lacks the explicit routing seen in better descriptions, such as naming search_documents for fuzzy or keyword-based lookups. The guidance is present but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Show' implies a read-only operation, the description does not explicitly confirm non-destructive behavior or any side effects. It also doesn't mention anything about data freshness, caching, or potential errors. For a status tool, this is a notable gap.
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 sentence with no wasted words. It is front-loaded with the action and the key information. Every word contributes to understanding the tool's output. Excellent terseness.
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 zero-parameter read-only status tool, the description is largely sufficient. It outlines the output fields (documents, paths, chunk counts), and the presence of an output schema likely details the structure further. There is no mention of prerequites or potential pitfalls, but given the simple nature, this is acceptable.
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, so per calibration the baseline is 4. The description does not need to explain parameter details. The absence of parameters is fully supported by the schema, and the description adds nothing extra but doesn't need to.
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 clearly states the action ('Show') and the specific resource ('indexed documents, Markdown paths, and chunk counts'). This distinguishes it from siblings like ingest_document or search_documents, though it might overlap with list_documents. However, it specifies the exact output dimensions, making its purpose clear.
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 usage for checking indexing status, but it does not explicitly state when to use this tool versus alternatives like list_documents. There is no mention of exclusions or alternative routing, leaving some ambiguity. The tool name 'index_status' suggests its purpose, but the description alone doesn't provide definitive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It states it converts and indexes but does not disclose side effects such as whether the original document is modified, how indexing affects existing chunks, or the meaning of the 'force' parameter. No mention of reversibility, permissions, or what happens on re-ingestion. This is a significant gap for a mutation tool.
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 concise sentence that front-loads the core action and key differentiator ('Convert one DOCS document'). No wasted words; efficient and immediately comprehensible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values are covered, but the description lacks detail on the 'force' parameter, prerequisites (e.g., document existence), and the practical implications of indexing. The description is too minimal to fully guide correct invocation, especially for a tool with multiple steps and a boolean option.
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 explain parameters. It implicitly identifies document_name as the document to convert, but it omits any explanation of the 'force' parameter. The description does not clarify what forcing does (e.g., overwrite existing index, skip cache), leaving an undocumented required-optional parameter.
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 a specific action (convert to Markdown) on a specific resource (one DOCS document), with additional detail (using Marker, indexing structural chunks). It clearly distinguishes from siblings like list_documents, ingest_all_documents (multiple), and search_documents or read_markdown_section, which have different purposes.
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 phrase 'one DOCS document' implicitly signals this tool is for single-document ingestion, contrasting with 'ingest_all_documents.' However, it does not explicitly name alternatives or exclude other use cases, leaving some guidance to inference. Clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It reveals that the tool is read-only in nature (a list operation) and scopes results to DOCS while excluding DOCS/mdDB, but it does not explicitly state that it causes no side effects or describe other behaviors such as sorting, pagination, or error conditions. The exclusion is useful context, but the description remains thin on overall behavioral cues.
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, tightly packed sentence that immediately states the action, scope, and exclusion. There is no filler, and the most important information (the exclusion) is included without excess. This is an exemplary concise and well-structured description.
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?
The tool is low complexity with no parameters and an existing output schema, so the description does not need to explain return values. The only potential gap is the meaning of 'supported documents,' but for a simple listing tool, this is minimally ambiguous and likely inferable from context or the output schema. Overall, the description is sufficiently complete for an agent to call the tool correctly.
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 takes zero parameters, and the schema coverage is 100% (vacuously). Per rubric, a tool with no parameters gets a baseline score of 4 since there are no parameter meanings to clarify; the description correctly avoids irrelevant parameter details.
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 ('List') and a precise resource scope ('supported documents under DOCS') and adds an explicit exclusion ('excluding DOCS/mdDB'). This clearly differentiates it from sibling tools that ingest, search, or read documents, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_documents or read_markdown_section. It does not mention any context or conditions that would direct the agent away from other tools, leaving the decision entirely to inference from the tool's name and basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![opencode-document-rag-mcp MCP server](https://glama.ai/mcp/servers/humbertolvarona/opencode-document-rag-mcp/badges/card.svg)](https://glama.ai/mcp/servers/humbertolvarona/opencode-document-rag-mcp)

Score Badge

Copy to your README.md:

[![opencode-document-rag-mcp MCP server](https://glama.ai/mcp/servers/humbertolvarona/opencode-document-rag-mcp/badges/score.svg)](https://glama.ai/mcp/servers/humbertolvarona/opencode-document-rag-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/humbertolvarona/opencode-document-rag-mcp'

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