MCP RAG

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clear, distinct purpose: querying with/without filters, learning from files or text, and various statistics and maintenance operations. There is no functional overlap.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern in snake_case, e.g., ask_rag, learn_document, get_knowledge_base_stats. The only deviation is 'clear_embedding_cache_tool' which includes an unnecessary 'tool' suffix.
Tool Count5/5
With 10 tools covering querying, learning, statistics, and maintenance, the set is well-scoped for a RAG knowledge base server. No tool is redundant, and the number is appropriate for the domain.
Completeness3/5
The tools cover essential operations (add, query, manage, maintain), but lack delete or list/update for documents, which are common for a full lifecycle. The gaps are minor but notable.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool returns detailed statistics, it doesn't specify whether this is a read-only operation, what permissions might be required, potential rate limits, or how the statistics are formatted. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 well-structured with clear sections: purpose statement, usage scenarios, and return information. It's appropriately sized for a zero-parameter tool. The only minor issue is some redundancy between the purpose statement and return section, but overall it's efficient and front-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?
Given that the tool has an output schema (which handles return value documentation) and zero parameters, the description provides adequate context about purpose and usage scenarios. However, with no annotations and multiple sibling statistics tools, it could benefit from more differentiation and behavioral details to be fully complete.
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 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters, which is appropriate. It correctly focuses on what the tool does rather than parameter details, earning a high score for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool '获取向量数据库的详细统计信息' (gets detailed statistics of the vector database), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_knowledge_base_stats' or 'get_embedding_cache_stats', leaving ambiguity about what distinguishes these statistics tools. The purpose is understandable but lacks sibling differentiation.
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 includes a '使用场景' (usage scenarios) section listing four specific contexts: checking database status, analyzing document distribution, diagnosing performance issues, and planning optimization. This provides clear guidance on when to use the tool. However, it doesn't explicitly state when NOT to use it or mention alternatives among siblings, which prevents a perfect score.
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 it states the tool queries a RAG knowledge base and returns answers, it doesn't describe important behavioral aspects like: what types of answers are returned (structured/unstructured), whether there are rate limits, authentication requirements, response formats, or error conditions. For a query tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 well-structured with a clear purpose statement followed by usage scenarios and parameter documentation. It's appropriately sized for a single-parameter tool. The only minor inefficiency is the repetition of similar concepts in the usage scenarios (e.g., '询问特定主题或概念' and '请求解释或定义' could potentially be combined).
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?
Given that there's an output schema (which handles return values), the description doesn't need to explain outputs. However, for a query tool with no annotations, the description should provide more behavioral context about how the tool operates, what it expects from the knowledge base, and potential limitations. The usage scenarios help, but more operational transparency would improve completeness.
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 description explicitly documents the single parameter: 'query: 要向知识库提出的问题或查询' (query: the question or query to ask the knowledge base). With 0% schema description coverage and only one parameter, this provides complete parameter semantics beyond what the bare schema offers. The description fully compensates for the lack of schema documentation.
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 tool's purpose: '向 RAG 知识库提问，并根据存储的信息返回答案' (Ask the RAG knowledge base questions and return answers based on stored information). This specifies the verb (ask/query) and resource (RAG knowledge base). However, it doesn't explicitly differentiate from its sibling 'ask_rag_filtered', which appears to be a similar querying tool with filtering capabilities.
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 provides four clear usage scenarios (asking about topics/concepts, requesting explanations/definitions, getting information from processed documents, obtaining answers based on learned text/documents). This gives good context about when to use the tool. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'ask_rag_filtered' despite having that sibling tool available.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the tool optimizes for performance, it doesn't describe what the optimization actually does (reindexing? compression? cache management?), whether it requires downtime, how long it takes, what permissions are needed, or potential risks. The return statement is vague ('有关优化过程的信息' - information about the optimization process).
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 appropriately concise with a clear purpose statement followed by bulleted usage scenarios and a return statement. Each section earns its place, though the return statement could be more specific. The structure is logical and front-loaded with the main purpose.
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?
Given that the tool has no parameters, an output schema exists, and annotations are absent, the description provides adequate basic information about purpose and usage scenarios. However, for a performance optimization tool that likely involves significant system changes, the description lacks important behavioral details about what the optimization entails, its impact, and safety considerations.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, earning a baseline 4 for not creating confusion about non-existent 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 clearly states the tool's purpose as '优化向量数据库以提高搜索性能' (optimize vector database to improve search performance), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'reindex_vector_database' or 'clear_embedding_cache_tool', which might serve related performance 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 description provides three clear usage scenarios (slow search, many new documents added, wanting overall performance improvement), giving good context about when to use this tool. However, it doesn't specify when NOT to use it or mention alternatives among the sibling tools, which would be needed for a perfect score.
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 it mentions the tool adds text to a knowledge base for future reference, it lacks critical details such as whether this operation is idempotent, what permissions are required, how the text is processed (e.g., embedding generation), or potential side effects like storage limits. This is a significant gap for a mutation tool with zero annotation coverage.
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 well-structured and front-loaded with the core purpose, followed by usage scenarios and parameter explanations. Every sentence adds value without redundancy, and it efficiently conveys necessary information in a compact format, making it easy for an agent to parse.
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?
Given the tool's complexity (mutation with 2 parameters), no annotations, and an output schema (which reduces the need to describe return values), the description is moderately complete. It covers purpose, usage, and parameters but lacks behavioral details like error handling or processing behavior. This is adequate but has clear gaps for a tool that modifies a knowledge base.
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 description adds meaningful context for both parameters beyond the input schema, which has 0% description coverage. It explains that 'text' is the content to learn and store, and 'source_name' is a descriptive name for the source with examples like 'user_notes' or 'research_paper'. This compensates well for the schema's lack of descriptions, though it could provide more detail on format constraints.
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 tool's purpose with specific verb ('添加'/'add') and resource ('RAG 知识库'/'RAG knowledge base'), and distinguishes it from siblings like ask_rag (querying) and clear_embedding_cache_tool (maintenance). It explicitly defines the action as adding new text for future reference, making the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage scenarios (e.g., adding facts, storing conversation info, saving research notes), which helps the agent understand when to use this tool. However, it does not explicitly state when NOT to use it or mention alternatives like ask_rag for retrieval, leaving room for improvement in distinguishing from sibling tools.
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 clearly indicates this is a read-only operation (获取/获取) and describes what kind of information will be returned. However, it doesn't mention potential limitations like whether this requires specific permissions, if there are rate limits, or how frequently the statistics are updated. The description adds useful context about the types of metrics available but doesn't fully cover behavioral aspects.
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 well-structured with a clear purpose statement followed by specific usage scenarios and a brief return statement. Each sentence earns its place by providing distinct value. It could be slightly more concise by combining the purpose and return statements, but overall it's efficiently organized.
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?
Given that the tool has 0 parameters, an output schema exists, and the description provides clear purpose and usage guidance, this is reasonably complete. The description doesn't need to explain return values since an output schema exists, and it adequately covers when and why to use this tool. The main gap is the lack of behavioral details that would be helpful for a monitoring tool.
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 0 parameters with 100% schema description coverage, so the baseline would be 3. However, the description explicitly states '使用场景' (usage scenarios) that help the agent understand when to invoke this parameterless tool, adding meaningful context beyond the empty schema. This elevates the score above baseline.
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 tool's purpose as '获取有关嵌入缓存性能的详细统计信息' (get detailed statistics about embedding cache performance), which is a specific verb+resource combination. It distinguishes itself from siblings like 'get_knowledge_base_stats' and 'get_vector_database_stats' by focusing specifically on cache performance. However, it doesn't explicitly contrast with 'clear_embedding_cache_tool' beyond the obvious read vs. write difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios in a bulleted list: checking cache hit rates, monitoring memory usage, understanding reuse frequency, and debugging performance issues. These give clear guidance on when to use this tool versus alternatives like 'get_vector_database_stats' for broader system monitoring or 'clear_embedding_cache_tool' for cache management.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'detailed statistical information' and implies read-only behavior by focusing on analysis. However, it lacks details on potential side effects (e.g., if it triggers background processing), performance characteristics (e.g., latency for large knowledge bases), or error conditions. The description adds some context but doesn't fully cover behavioral traits beyond basic functionality.
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 well-structured with a purpose statement, usage scenarios in bullet points, and an output note. Each sentence earns its place by clarifying different aspects (what it does, when to use it, what it returns). It could be slightly more concise by integrating the output note into the purpose, but overall it's efficient and front-loaded with key information.
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?
Given the tool's low complexity (0 parameters) and the presence of an output schema, the description is reasonably complete. It covers purpose, usage, and output at a high level, which is sufficient for a stats-retrieval tool. However, without annotations, it could benefit from more behavioral details (e.g., idempotency, rate limits), but the output schema likely handles return values, reducing the need for extensive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description correctly omits parameter details, focusing instead on usage and output. This aligns with the baseline of 4 for zero parameters, as it avoids redundancy and adds value through context rather than repeating schema information.
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 tool's purpose: '获取有关知识库的综合统计信息' (Get comprehensive statistics about the knowledge base). It specifies the types of statistics (document types, processing methods, structural information) and distinguishes itself from siblings like 'get_embedding_cache_stats' or 'get_vector_database_stats' by focusing on knowledge base content rather than caching or database metrics. However, it doesn't explicitly contrast with all siblings (e.g., 'ask_rag' is for querying, not statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios in a bulleted list: checking document count, understanding file type distribution, viewing processing methods, and analyzing structural complexity. This clearly indicates when to use this tool—for statistical analysis of knowledge base content—and implicitly distinguishes it from alternatives like querying tools ('ask_rag') or maintenance tools ('reindex_vector_database'). No exclusions are stated, but the context is well-defined.
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 full burden. It indicates this is a reindexing operation (implies mutation/write), mentions performance optimization, and describes the 'auto' profile option. However, it doesn't disclose important behavioral aspects like whether this operation is destructive, requires downtime, has rate limits, or specific permission requirements for a database 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?
The description is well-structured and appropriately sized. It begins with the core purpose, then provides usage scenarios in bullet points, followed by parameter details, and finally return information. Every section adds value with no redundant information. The Chinese text is concise and clear.
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?
Given this is a database mutation tool with no annotations but with an output schema, the description does well. It explains the purpose, when to use it, parameter details, and mentions what the return contains. The output schema existence means the description doesn't need to detail return values. However, for a potentially destructive database operation, more behavioral context would be helpful.
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 description adds significant value beyond the schema. The input schema has 0% description coverage and only shows 'profile' as a string parameter. The description explains the parameter meaning ('配置文件' - configuration file), lists the four possible values ('small', 'medium', 'large', 'auto'), and explains what 'auto' does ('会自动检测最佳配置文件' - automatically detects the best configuration file). This fully compensates for the poor schema coverage.
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 tool's purpose: '使用优化配置重新索引向量数据库' (Reindex vector database using optimized configuration). It specifies the verb ('重新索引' - reindex) and resource ('向量数据库' - vector database). However, it doesn't explicitly differentiate from sibling tools like 'optimize_vector_database' - both seem related to vector database optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent usage guidelines with a dedicated '使用场景' (Usage scenarios) section listing four specific situations when to use this tool: after configuration changes, when search is very slow, for database size optimization, and for persistent performance issues. This gives clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes advanced processing steps: REAL semantic chunking, structure preservation, denoising, metadata extraction, fallback system, and saving a copy for verification. No annotations, so description carries full burden; it discloses key behaviors without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat long but well-structured with bullet points for supported types, features, and examples. Front-loaded with purpose; each section adds value without redundancy.
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?
Covers input, processing behavior, and outcome (stored in knowledge base with metadata, copy saved). Output schema exists, so return values not needed. Could mention idempotency but overall complete.
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?
Single parameter file_path is explained as 'absolute or relative path' in the description, adding meaning beyond the schema's type string. Schema coverage is 0%, so description compensates well.
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?
Clearly states the tool reads and processes document files using advanced semantic chunking and adds to knowledge base. Distinguishes from sibling learn_text by specifying document file types and advanced features.
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?
Provides context on when to use (train AI on document files) and lists specific use cases. Does not explicitly exclude alternatives, but implied by focus on structured documents.
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?
No annotations are provided, so the description carries the full burden. It describes the tool's filtering behavior well with specific examples, but doesn't mention other behavioral aspects like response format, error handling, rate limits, or authentication requirements. The description adds value by explaining filtering logic but lacks comprehensive behavioral disclosure.
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 well-structured and appropriately sized. It starts with a clear purpose statement, provides usage scenarios with bullet points, then lists parameters with explanations. Every sentence earns its place, and there's no redundant information. The bilingual nature (Chinese with English examples) is efficient for the intended context.
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?
Given the tool's complexity (5 parameters, filtering logic) and the presence of an output schema (which handles return values), the description is mostly complete. It explains the purpose, usage, and parameters thoroughly. The main gap is lack of behavioral context beyond filtering (e.g., performance characteristics, limitations), but the output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter explanations. Each parameter is clearly explained with examples: 'query: 要向知识库提出的问题或查询' (the question or query to ask the knowledge base), 'file_type: 按文件类型过滤（例如 ".pdf", ".docx", ".txt"）' (filter by file type, e.g., ".pdf", ".docx", ".txt"), etc. The description adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '向 RAG 知识库提问，并使用特定过滤器聚焦搜索' (Ask the RAG knowledge base and use specific filters to focus the search). It specifies the verb ('提问' - ask/query) and resource ('RAG 知识库' - RAG knowledge base), and distinguishes it from the sibling 'ask_rag' by explicitly mentioning filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios with concrete examples: '仅搜索 PDF 文档：file_type=".pdf"', '查找包含表格的文档：min_tables=1', etc. It clearly indicates when to use this tool (for filtered searches) versus the sibling 'ask_rag' (presumably for unfiltered queries), making the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 clearly states this is a destructive operation that clears cache to free resources, and mentions it returns a confirmation message. However, it doesn't specify potential side effects like performance impact during clearing or whether this requires special permissions.
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 efficiently structured with a clear purpose statement followed by specific usage scenarios in bullet points and a brief note about return values. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple, parameterless tool with an output schema (confirmed by context signals), the description provides complete context: clear purpose, specific usage guidelines, behavioral information about the destructive nature, and mention of return confirmation. No additional information is needed.
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on usage scenarios and behavioral context.
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 specific action ('清除嵌入缓存' - clear embedding cache) and the purpose ('以释放内存和磁盘空间' - to free memory and disk space). It distinguishes this tool from sibling tools like 'get_embedding_cache_stats' (which reads cache stats) and 'optimize_vector_database' (which optimizes rather than clears).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios in a bulleted list: when system memory is low, after changing embedding models, to remove old/unneeded cache embeddings, and for troubleshooting cache-related issues. This gives clear guidance on when to use this tool versus alternatives like 'get_embedding_cache_stats' for inspection only.
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:

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

Score Badge

Copy to your README.md:

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

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/kalicyh/mcp-rag'

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