engram-global

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: remember saves, recall searches, forget soft-deletes, correct replaces erroneous memories, reinforce boosts relevance, link creates explicit connections, consolidation_candidates and skill_candidates surface different cluster types, mark_consolidated finalizes consolidation, reindex rebuilds the index, and stats reports metrics. Even the superficially similar candidates tools are well-differentiated by their described use cases.
Naming Consistency3/5
Naming uses a mix of simple verbs (remember, recall, forget, reinforce, correct, link, reindex), a noun (stats), and underscore-separated phrases (consolidation_candidates, skill_candidates, mark_consolidated). The convention is not uniform, but names are still readable and descriptive enough to infer their functions.
Tool Count5/5
With 11 tools, the server is well-scoped for a comprehensive memory management system. Each tool addresses a distinct lifecycle phase (creation, retrieval, correction, reinforcement, linking, consolidation, maintenance, and statistics), and none feel redundant or missing.
Completeness4/5
The tool surface covers the core memory lifecycle (create, read, soft-delete, correct, reinforce, link, consolidate, extract skills) plus maintenance and stats. Minor gaps exist, such as no direct update tool for editing a memory's content or a restore-from-trash operation, but these are workaroundable and the provided workflow is intentional.
Average 4.3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
No annotations are provided, so the description carries the behavioral transparency burden. It discloses that the link is explicit and that deep recall can follow it, which is useful. However, it does not mention whether links are directional, if duplicates are allowed, or what happens if a memory ID is invalid. This is only minimum viable.
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 three concise sentences: what, when, and why. Every sentence adds value, and the structure is front-loaded with the primary action. No unnecessary detail.
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?
For a simple link tool with no output schema and no annotations, the description covers the core purpose and usage, but lacks parameter semantics and behavioral edge cases. The tool is basic enough that this is adequate but not complete.
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 input schema has no descriptions for src or dst, and schema coverage is 0%. The description merely says 'two memories' but does not clarify the role of each parameter, the expected format (e.g., memory IDs), or whether direction matters. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create an explicit link between two memories.' This is a specific verb and resource, and it distinguishes the tool from siblings like remember, recall, and forget. The additional explanation that deep recall can follow the link adds a clear purpose.
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 explicit when-to-use guidance: 'Call this when you want to manually connect related memories.' This helps the agent select the tool. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.
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, the description carries the full burden. It reveals that the tool returns counts and events, implying a read-only nature. However, it does not explicitly state that no state is modified, nor does it mention any potential side effects or data freshness. The inclusion of 'and so on' also leaves ambiguity about the full set of statistics returned.
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, with the first clearly stating the tool's purpose and the second providing useful detail. No words are wasted, and the structure is front-loaded with the main action. It is appropriately concise.
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 no output schema and no annotations, the description should fully specify what is returned. It lists several concrete examples but weakens it with 'and so on,' leaving room for ambiguity. For a simple no-parameter tool, this is adequate but not complete enough to be fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects this completely (100% coverage). The description therefore needs no parameter-specific semantics. The baseline for a zero-parameter tool is 4, which is appropriate here since the description adds context about the nature of the output without needing to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return memory statistics' with a specific verb and resource, and then elaborates on the types of statistics (counts by type and tier, access events, links). This distinguishes it from sibling tools like forget or remember, which perform actions rather than reporting information.
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 intended usage is implied: use this tool when you need memory statistics. However, there is no explicit guidance about when to use this tool versus alternatives like consolidation_candidates or skill_candidates, nor any exclusion criteria. The context suggests it for general stats, but the description could be more direct about its role among siblings.
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, the description fully carries the transparency burden. It discloses mode-specific behavior (hot tier, fallback to deep, associative links, exhaustive ranking) and room scoping implications. However, it does not mention the side effect of record_hits (default true) or any potential persistence behavior, which 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded one-sentence purpose, a usage directive, and clear bullet-like mode explanations. It is somewhat lengthy but every sentence contributes value, and the structure aids readability.
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 search tool with multiple modes and no output schema, the description covers the essential context: when to use it, mode behaviors, room cautions, and fallback mechanisms. It is not fully complete because it omits explanation of `type` and `record_hits`, and does not disclose potential side effects, but overall it provides solid contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description must compensate. It does so thoroughly for `mode` and `room`, but leaves `type`, `limit`, and `record_hits` unexplained. `query` and `limit` are self-evident, but `type` and `record_hits` remain ambiguous, leaving the compensation incomplete.
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 'Search for and return memories,' which is a specific verb+resource pairing that clearly distinguishes this from sibling tools like forget or remember. It further elaborates on mode-specific search scope, 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 explicitly instructs to 'Always call this at the start of a task' and provides mode-selection guidance (fast vs. deep vs. exhaustive) with clear 'last resort' and 'only when necessary' language. It doesn't explicitly contrast with alternatives or state when not to use it, but the usage 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.
Behavior5/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 goes beyond the basic 'save' operation by explaining duplicate handling (cosine similarity threshold and reinforcement), automatic room inference from the working directory, and the importance scoring scale. These are non-obvious behaviors that an agent needs to know.
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 paragraph with five sentences, each earning its place. It is front-loaded with the core action, then provides usage guidance, duplicate behavior, and room handling without any redundancy or filler.
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 7 parameters, no annotations, and no output schema, the description should be more thorough. It covers duplicate logic, importance, and room, but leaves the required `type` parameter completely unexplained and does not describe the return format or what the tool returns when a new memory is saved versus a duplicate. This is a significant omission for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning for `importance` ('from 1-10') and `room` (inferred automatically, only pass 'common' for universal memories), which is valuable. However, it does not explain the required `type` parameter or optional parameters like `tags`, `source`, and `related_ids`, leaving significant gaps.
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 'Save a new memory,' which is a specific verb+resource statement that clearly distinguishes this tool from siblings like 'forget' and 'recall'. It also clarifies the intent by stating it is for storing discovered facts, preferences, project status, or events.
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 explicit guidance on when to call the tool: 'Call this whenever you discover something important during a task.' It also gives specific parameter-usage guidance for `room`, explaining when to pass it explicitly and when to omit it. However, it does not explicitly name alternative tools or say when NOT to use this tool.
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?
Since no annotations are provided, the description carries the full burden. It discloses that the operation is a soft delete, moves memory to trash, and can be restored, which is meaningful behavioral context. However, it omits potential side effects (e.g., on links or consolidation status) and what the API returns.
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 three sentences with no filler. The first sentence states the action, the second gives the usage context, and the third provides an alternative. It is well-structured and front-loaded.
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 simplicity (one parameter, no output schema, no annotations), the description covers the key aspects: purpose, usage context, soft-delete behavior, and restoration. It lacks parameter-level guidance and return expectations, but these are less critical for this simple action.
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 has one 'id' parameter with no description (0% coverage). The description never mentions 'id' or clarifies that it is the identifier of the memory to forget, leaving the agent to infer this from the tool name and 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 action ('soft-delete'), the target ('a memory'), and the mechanism ('move it to trash'). It explicitly distinguishes itself from the sibling tool 'correct' by noting when each should be used.
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?
It gives a clear 'when to use' condition: 'when a memory is no longer needed and you want it excluded from search'. It also explicitly warns against using it for corrections and directs the agent to 'correct' instead, providing an alternative.
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, the description carries the burden of behavioral disclosure. It explains the effect on recall ranking, the Hebbian co-occurrence link when passing multiple ids, and the strength range. It omits reversibility and error behavior, but covers the core side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and each sentence adds information. However, the first two sentences are slightly redundant ('Report which memories actually turned out to be useful' vs. 'report the ids of memories that actually helped'), costing it a perfect score.
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 2-parameter tool with no output schema and no annotations, this description covers purpose, usage timing, parameter meanings, and behavioral consequences. It does not mention return values or error conditions, but these are not critical for this tool's use case.
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 coverage is 0%, so the description must explain parameters. It does: 'ids' are memory ids that helped, and 'strength' is given a numeric range (0.1-3.0) and its controlling effect. The multi-id linking behavior adds semantic depth beyond the 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 opens with a specific action and resource: 'Report which memories actually turned out to be useful.' It clearly distinguishes reinforce from sibling tools like recall (retrieval) and remember (encoding) by focusing on post-task feedback and ranking impact.
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 when to use the tool ('When a task finishes') and gives context for multi-id usage (co-occurrence linking). It does not name alternatives or exclusions, but the timing condition is clear and actionable.
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?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral effects: demoting the old memory to superseded and creating a new memory with the reason for correction. It also explains the hypercorrection effect, which adds useful context. However, it does not mention whether the old memory becomes unavailable or any potential side effects, leaving some minor gaps.
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 extremely concise and front-loaded, starting with a clear directive and then explaining the behavioral rationale. Every sentence adds value, with no redundant 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 it has no output schema or annotations, the description adequately covers the core workflow: when to use, what happens to the old and new memory, and why this is beneficial. It could be improved by mentioning how to obtain the 'id' or what 'source' is for, but overall it is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly explains 'corrected_content' and 'reason' through the narrative, and 'id' is inferable as the memory to correct. However, 'source' is never mentioned, and no explicit parameter mapping is given. This provides moderate help 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: to correct a memory that turns out to be wrong, demoting the old memory and creating a new one with the correction. It uses a specific verb ('correct') and contrasts with the sibling tool 'forget', making its unique role unmistakable.
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?
Explicitly tells when to use this tool: 'Use this instead of forget when a memory turns out to be wrong.' This names the alternative (forget) and provides a clear decision rule, giving the agent unambiguous guidance.
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 burden of disclosing behavioral traits. It clearly states side effects: 'The original episodes are demoted to cold (long-term storage) and linked to the new memory via a derived_from link.' This is a meaningful behavioral disclosure. It doesn't mention reversibility or permissions, but for the scope of this tool, the key side effects are covered.
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 slightly longer than ideal but each sentence serves a purpose: stating the main function, the recommended invocation sequence, the side effects, and an additional use case. It is front-loaded with the primary action and structured logically, making it easy to parse. A few words could be trimmed, but overall it is efficient.
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 tool with two parameters, no annotations, and no output schema, the description is fairly complete. It covers the main workflow, side effects, and an alternative usage. The only notable gap is that the skill_candidates scenario implies a second use but does not clarify what new_memory_id should be in that context, leaving a minor ambiguity.
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 does by contextualizing the parameters: episode_ids are the 'original episodes' being demoted, and new_memory_id refers to the memory created via 'remember'. This adds meaning beyond the raw schema (array of strings, string) and helps the agent understand what values to provide.
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 primary function ('Record that a consolidation has been completed') and elaborates on the specific action of demoting original episodes to cold storage and linking to a new memory. It references consolidation_candidates and skill_candidates, which distinguishes it from sibling tools by clarifying its role in the consolidation workflow.
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 explicitly provides when to use this tool: 'Call this after the LLM has summarized a cluster surfaced by consolidation_candidates and created the new memory via remember.' It also mentions an alternative use case with skill_candidates, giving clear context for invocation. This directly guides the agent on the correct sequence.
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?
No annotations are present, so the description carries the full burden. It clarifies that the tool only returns candidates and does not perform the actual consolidation, and it names the follow-up action (mark_consolidated), which adds valuable behavioral context beyond a simple 'return clusters' statement.
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 three concise sentences: purpose, timing, and next-step workflow. Every sentence earns its place with no redundancy or fluff.
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-param tool with no output schema, the description adequately covers purpose, usage, and subsequent actions. It could describe the exact return format in more detail, but the essential context is present and the workflow is clear.
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 schema is trivially complete. The description adds no parameter semantics because none are needed; the baseline for zero-parameter tools is 4.
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 returns clusters of episode memories for consolidation, using a specific verb and resource. It distinguishes itself from sibling tools like mark_consolidated and skill_candidates by focusing on candidate generation for consolidation.
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?
Explicitly instructs to call before ending a session and outlines the workflow with mark_consolidated. This provides clear when-to-use context and distinguishes from alternatives by describing the intended place in the consolidation process.
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?
No annotations are provided, so the description carries the full burden. It discloses the tool rebuilds the index from files and that it is incremental, but does not mention potential side effects or whether it is destructive. Still, the key behavioral traits (source, incremental nature, speed) are covered.
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 sentences with no wasted words. The purpose, usage trigger, and performance characteristic are front-loaded and clear.
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 the tool's simplicity (no parameters, no output schema), the description fully covers the necessary context: what it does, when to call it, and a key performance trait. Nothing important is missing.
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 parameter semantics are irrelevant. Per calibration rules, the baseline is 4 for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Rebuild the DB index from the Markdown files' with a specific verb and resource, clearly distinguishing this from sibling tools like remember, recall, and forget.
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?
Explicitly states when to use: 'Call this after manually editing files, or when you suspect the DB is corrupted.' It also contrasts with a full rebuild by noting only differing memories are re-embedded, implying when this is the right choice.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does this thoroughly: it states that the tool only returns candidates, explicitly instructs to never create/deploy a skill without user approval, and describes the post-decision cleanup steps. This gives the agent a clear understanding of side effects and required 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 concise yet comprehensive, structured in three short paragraphs. The first sentence immediately states the primary purpose, followed by usage context and a clear 'Even when a cluster is found...' caveat. Every sentence adds value, and the length is appropriate for the complexity of the tool.
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 absence of an output schema, the description provides a high-level of what is returned ('clusters of episode memories') but does not detail the exact structure or fields of the returned clusters. However, it covers the full workflow, prerequisites, and the 'three-times rule,' making it complete enough for an agent to decide when to invoke it and what to do next. The lack of return structure detail slightly prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100% (empty schema). Per the baseline for 0 params, a score of 4 is appropriate. The description does not need to explain parameters since none exist, but it also doesn't add any extra nuance beyond schema, hence not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Return clusters of episode memories that are candidates for extraction into a reusable skill.' It clearly distinguishes itself from the sibling tool consolidation_candidates by explicitly stating 'Unlike consolidation_candidates, there is no age filter here.' This makes the purpose unambiguous and differentiated.
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 when-to-use criteria: when 3 or more episodes (the 'three-times rule') form a similar cluster. It also contrasts with the alternative tool, noting the age-filter difference, and outlines the subsequent workflow (propose to user, get approval, record reasoning, clean up episodes). This gives clear guidance for selecting this tool over siblings.
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:

[![engram-global MCP server](https://glama.ai/mcp/servers/ricoaiproject-cmd/engram-global/badges/card.svg)](https://glama.ai/mcp/servers/ricoaiproject-cmd/engram-global)

Score Badge

Copy to your README.md:

[![engram-global MCP server](https://glama.ai/mcp/servers/ricoaiproject-cmd/engram-global/badges/score.svg)](https://glama.ai/mcp/servers/ricoaiproject-cmd/engram-global)

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/ricoaiproject-cmd/engram-global'

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