Chilon Recall

Official

by ctrlcakepro

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation4/5
Most tools have clearly distinct purposes: admin operations (backups, status, config, build, clear/restore) are unambiguous, and retrieval tools are specialized by task (general query, QA, comparison, summary, outline). However, rag_query and textbook_qa overlap somewhat as both retrieve evidence for questions, and chapter_summary vs review_outline could be confused.
Naming Consistency3/5
Admin tools follow a consistent rag_ prefix with verb_noun pattern (list_backups, save_config, clear_index), but retrieval tools are mixed: rag_query fits, while textbook_qa, concept_compare, chapter_summary, and review_outline use noun-based names without the prefix. This creates a predictable split between admin and query tools, but the naming style is not uniform.
Tool Count5/5
12 tools is well within the ideal range, covering both index lifecycle management and a variety of retrieval modes. Each tool contributes a distinct function, and none feel redundant or unnecessary for the server's purpose.
Completeness4/5
The tool set covers the core index lifecycle (build, clear, restore, backup, status) and multiple retrieval scenarios (question answering, concept comparison, summaries, outlines). Minor gaps include no explicit backup deletion and no full-document retrieval, but these are not essential for the stated educational RAG use case.
Average 3.6/5 across 12 of 12 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'retrieve evidence' aligns with this read-only behavior, so no contradiction. However, the description adds little beyond the annotations—no details on limitations, return format, or edge cases.
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 a single, clear sentence with no wasted words. It is front-loaded with the core function, though brevity sacrifices necessary detail.
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 five parameters, no output schema, and no parameter descriptions, this one-liner is insufficient. It gives a high-level idea but omits how to specify comparison focus, result limits, or what 'evidence' means in practice.
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 no information about the five parameters (conceptA, conceptB, top, candidates, compareFocus). It does not compensate for the lack of schema descriptions, leaving parameter behavior entirely undocumented.
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 ('retrieve evidence') and identifies the resource ('comparing two concepts'). This distinguishes it from siblings like rag_query or textbook_qa, though the phrase 'across clear dimensions' is vague about what those dimensions are.
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 alternatives such as rag_query or textbook_qa. There are no exclusions, prerequisites, or contextual hints beyond the basic purpose, leaving the agent to infer usage.
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 already declare readOnlyHint=true and destructiveHint=false, and the description's 'retrieve' aligns with that. However, the description adds no additional behavioral information such as rate limits, configuration assumptions, or output characteristics beyond the annotations. With annotations covering the safety profile, the description provides minimal extra value.
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 filler, directly stating the core purpose. It is front-loaded and efficiently sized, earning full marks for conciseness.
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?
The tool has four parameters and no output schema, and the description only covers the basic purpose. It fails to explain return values, parameter semantics, or any operational context needed for correct invocation, making it incomplete for a tool of moderate complexity.
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 descriptions are absent for all four parameters (0% coverage), so the description must compensate. It implicitly references the 'question' parameter via 'learning question' but does not explain the meaning or usage of 'top', 'depth', or 'candidates'. This leaves agents without enough information to set optional parameters correctly.
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: to retrieve evidence for answering learning questions from a configured knowledge base. It uses a specific verb ('retrieve') and resource ('evidence'), and the title 'Source-backed Learning Q&A' reinforces the educational Q&A focus. However, it does not explicitly differentiate itself from similar siblings like rag_query, so it misses 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 provides no guidance on when to use this tool versus alternatives such as rag_query or concept_compare. It only describes the action without any prerequisites, exclusions, or comparative context, making it insufficient for selecting the right tool among siblings.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds only that it retrieves evidence for a structured summary, which is somewhat consistent with the read-only nature. However, it does not disclose return format, how evidence is grounded, or how parameters like 'top' and 'candidates' affect behavior.
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 a single, grammatical sentence with no wasted words, making it very concise. It is front-loaded with the main verb. However, for a tool with four parameters and no schema descriptions, the sentence is arguably under-sized, though this is more a completeness issue than a structural flaw.
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?
The tool has four parameters, no output schema, and no parameter descriptions, yet the description only states 'Retrieve evidence for a structured chapter or topic summary.' It does not explain what the output looks like, how parameters modify behavior, or any prerequisites. This is insufficient for an agent to confidently invoke the tool with correct arguments.
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 implies that 'chapterOrTopic' is the topic to summarize, but provides no meaning for 'top', 'emphasis', or 'candidates'. The description adds minimal value beyond the schema's bare parameter names.
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 states 'Retrieve evidence for a structured chapter or topic summary,' which clearly identifies the action (retrieve evidence) and the resource (a structured summary). It distinguishes from sibling tools like rag_query by focusing on chapter/topic summaries, though it could be more explicit about whether it generates a summary or just returns evidence.
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 such as rag_query or textbook_qa. There is no mention of scenarios, exclusions, or complementary tools, leaving the agent to infer usage from the name alone.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that it 'organizes' evidence, which is useful, but it does not describe the output structure, retrieval scope, or whether the evidence comes from a specific source. There is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, front-loading the core action. It is concise and to the point. However, it sacrifices informativeness, which is more a completeness concern than a conciseness one.
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?
With no output schema, the description must explain what the tool returns, but it only says 'organize it.' It does not mention the outline format, how `reviewMode` changes behavior, or what 'evidence' refers to. This is insufficient for an agent to correctly invoke the tool.
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 does not mention any of the four parameters. It doesn't explain the meaning of `topic`, `top`, `candidates`, or `reviewMode`, leaving the agent to guess from names alone. The description fails to compensate for the low 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 uses specific verbs 'retrieve' and 'organize' and states the purpose 'for focused study or review,' which aligns with the title 'Evidence-backed Review Outline.' It is reasonably distinct from sibling tools like rag_query or textbook_qa, though it does not explicitly say it generates an outline.
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 phrase 'for focused study or review' gives some context about when to use the tool. However, it does not mention alternatives, when not to use it, or how it differs from similar tools like chapter_summary or concept_compare. Usage is implied rather than explicit.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that the tool returns 'source-backed passages' from a 'local index,' but does not explain behavior when the index is not active or built, so it provides some context but not deep behavioral detail.
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 fluff. Every word contributes to stating the tool's purpose, making it highly concise and well-structured.
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?
The tool has 3 parameters and no output schema, but the description omits parameter semantics, usage guidance, and return format details. While annotations cover read-only safety, an agent would not know how to set 'top'/'candidates' or what the response contains, making the description incomplete 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 does not explain the meaning or role of the 'top', 'question', or 'candidates' parameters. It implies a query is needed ('Retrieve source-backed passages') but never maps the query to the 'question' parameter or clarifies the numeric parameters, so the description fails to compensate for the schema's lack of descriptions.
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 'Retrieve' and a precise resource 'source-backed passages from the active local index,' clearly distinguishing it from siblings like rag_list_documents or rag_status. It succinctly states what the tool does without ambiguity.
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 instead of alternatives such as textbook_qa or other rag tools. The description lacks any contextual usage cues, leaving an agent without help in selecting between similar query tools.
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?
Annotations already indicate this is a write (readOnlyHint=false) and non-destructive (destructiveHint=false) operation. The description adds valuable context by emphasizing atomicity and the restriction to 'approved non-secret settings', which helps the agent understand side effects and constraints.
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 a single, tightly worded sentence that avoids redundancy. It is concise and front-loaded, though it could incorporate a bit more detail without losing clarity.
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?
With 19 parameters, no output schema, and no explanation of the configuration file lifecycle, the description is insufficiently complete. It does not explain what happens after an update or how 'approved' settings are determined, leaving significant ambiguities.
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 does not name or explain any of the 19 parameters. The phrase 'approved non-secret settings' is too vague to indicate which parameters are permitted or how they relate to the function.
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 action ('Atomically update') and resource ('the server's fixed configuration file'), with a scope ('approved non-secret settings'). This unambiguously differentiates it from sibling tools like rag_build or rag_query, which serve 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparative scenarios with sibling tools such as rag_restore_index or rag_status.
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?
Annotations already indicate destructive behavior, and the description adds valuable context: the action is recoverable via backup, and execution requires a token. It does not detail what happens to the current index beyond 'move' or how token matching works, but it goes beyond the 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?
Two concise, front-loaded sentences deliver the essential purpose and a safety requirement without any filler. Every word adds value.
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 sufficient for basic invocation but leaves gaps: how to obtain the 'matching token,' what preview outputs, and how restore relates to the backup. Sibling tools imply the restore path, but the description does not explicitly connect them.
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?
Schema description coverage is 0%, so the description must compensate. It explains the action parameter through 'preview or move' and the confirmationToken through 'execution requires a matching token.' It does not explicitly bind these to parameter names or describe token format, but it gives meaningful semantics for both.
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 states a specific operation: moving the active index into a recoverable backup, with preview and execute modes. It is distinguishable from siblings like rag_restore_index and rag_list_backups, though it does not use the word 'clear' explicitly.
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 use when clearing the active index and notes that execution requires a matching token, but it does not explicitly contrast with alternatives or state when not to use the tool. The preview/execute distinction provides some usage context.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable context by specifying that it lists 'text documents' from the 'fixed knowledge-base configuration', clarifying that the list reflects a static configuration rather than dynamic state.
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 wasted words. It directly states the action and scope, making it highly concise and well-structured.
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 simple read-only list tool with strong annotations, the description adequately conveys what is listed. The return format is implied by the verb 'List', and the main gap is the unexplained 'limit' parameter, though this is minor given the tool's simplicity.
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?
The schema defines a single optional 'limit' parameter (1-2000), but the description does not mention it or explain its effect. With 0% schema description coverage, the description should compensate, but it provides no parameter guidance.
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 'List' and identifies the resource 'text documents' with a clear scope ('fixed knowledge-base configuration'). This clearly distinguishes it from siblings like rag_list_backups (which lists backups) and rag_status (which shows status).
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 inspecting the configured knowledge-base documents, but it does not explicitly state when to use this tool versus alternatives like rag_list_backups or rag_status. No exclusions or alternative tool names are mentioned, so guidance is only implied.
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?
The description adds important behavioral context beyond annotations by noting that absolute paths are hidden, which is a security/privacy-relevant trait. The readOnlyHint and destructiveHint annotations already cover safety, and the description complements them without contradicting. It does not detail return format, but for a simple list tool this is sufficient.
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 that states the action, resource, and a meaningful qualifier. Every word earns its place; there is no fluff or 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?
For a zero-parameter list tool with no output schema, the description covers the essential purpose and a notable behavioral nuance. It could optionally mention what fields are returned (e.g., names, timestamps), but the low complexity and good annotations make the description adequately 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 no parameters, so there is nothing for the description to explain beyond what the schema states. Baseline for zero parameters is 4, and the description correctly focuses on behavior rather than redundant 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 uses a specific verb ('List') and resource ('recoverable index backups'), and adds a distinguishing qualifier ('without exposing their absolute paths'), clearly differentiating it from sibling tools like rag_list_documents or rag_status.
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 the tool is for viewing available backups, but does not explicitly state when to use it (e.g., before restoration) or how it compares to alternatives. No exclusions or alternative tool names are provided, so guidance is implicit rather than explicit.
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?
Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds valuable context about the staged build and the unexpired token requirement, which implies a safety gate. It doesn't detail the destructive consequences of execution, but it does add the temporal token constraint beyond 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?
The description is exactly two sentences, front-loaded with the core action, and every sentence adds essential information. There is no redundancy or filler.
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 covers the two-step workflow and token requirement, which is essential. However, there is no output schema and the description does not clarify what the preview returns besides a token, nor what happens to the existing index upon execution. Given the destructive hint, more detail about side effects would make it more 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?
With schema description coverage at 0%, the description carries full responsibility for explaining parameters. It references 'Preview or execute' to map to the action enum and 'token returned by preview' to explain confirmationToken. It gives both parameters meaningful context, though it doesn't explicitly enumerate the enum values.
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 'Preview or execute a staged index build,' using a specific verb and resource, and clearly identifies the two modes of operation. This distinguishes it from siblings like rag_query or rag_list_documents by focusing on the build action.
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 explicitly states the required two-step workflow: 'Execution requires the unexpired token returned by preview.' This tells the agent to run preview first and then use the token for execute. It doesn't mention alternatives or exclusions, but the workflow guidance is 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'without changing data.' It adds behavioral detail by naming the three aspects it inspects (source coverage, provider readiness, active index), which is useful beyond annotation hints.
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 that conveys the verb, the scope, and the non-destructive nature. Every word contributes meaning, with no redundancy or irrelevance.
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 simple zero-parameter status tool, the description adequately names the key output dimensions (source coverage, provider readiness, active index) despite lacking an output schema. It does not fully describe return formatting, but the essence is clear and consistent with annotations.
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 the baseline is 4. The description appropriately focuses on what the tool inspects rather than parameter details, which are unnecessary.
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 'Inspect' with distinct resources: 'source coverage, provider readiness, and the active index.' It clearly distinguishes this from sibling tools like rag_list_documents and rag_list_backups, and from mutating tools like rag_build and rag_clear_index.
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 'without changing data' provides clear context that this is a non-mutating status check, aligning with the read-only annotations. It does not explicitly mention alternatives or when not to use, but the sibling tool list makes the usage context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the destructiveHint annotation by disclosing that it 'backs up the current index first' and that execution requires a matching token. This is valuable safety-related behavior that would not be known from the schema or annotations alone, enhancing the agent's ability to assess risk.
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 sentences long and front-loads the core purpose. It avoids fluff and introduces important caveats (token, backup-first) in an efficient second sentence. Every word earns its place.
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 restore tool with no output schema, the description covers the key aspects: the backup identifier, the preview/execute modes, the token requirement, and the safety backup of the current index. It is complete enough for an agent to understand the tool's behavior and likely outcomes without further documentation.
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?
With zero schema description coverage, the description compensates by referencing 'named backup' (backupId), 'matching token' (confirmationToken), and 'Preview or restore' (action). These implicit mappings clarify the purpose of each parameter, though it does not explicitly enumerate the parameters or their formats.
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 function: 'Preview or restore a named backup.' The verb 'restore' with resource 'index backup' is specific, and the preview/execute distinction is immediately clear. It differentiates from sibling tools like rag_clear_index by focusing on restoring from a backup rather than clearing.
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 context on how to use the tool: a preview mode exists, execution requires a matching token, and the current index is backed up first. While it doesn't explicitly state when to use this tool versus alternatives, the destructive nature and prerequisite of a token are conveyed, giving enough guidance for most usage scenarios.
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:

[![chilon-recall MCP server](https://glama.ai/mcp/servers/ctrlcakepro/chilon-recall/badges/card.svg)](https://glama.ai/mcp/servers/ctrlcakepro/chilon-recall)

Score Badge

Copy to your README.md:

[![chilon-recall MCP server](https://glama.ai/mcp/servers/ctrlcakepro/chilon-recall/badges/score.svg)](https://glama.ai/mcp/servers/ctrlcakepro/chilon-recall)

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/ctrlcakepro/chilon-recall'

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