memsem

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation4/5
Most tools have clearly distinct purposes (add vs candidate_add vs episode_add, search vs list vs themes), and descriptions clarify boundaries. However, pairings like memory_add/memory_add_many and memory_forget/memory_purge could cause initial confusion, though the descriptions resolve it.
Naming Consistency3/5
All tools share the memory_ prefix, but the suffix pattern is mixed: verbs (add, search, list, verify, score, forget, purge) coexist with nouns (themes, stats, audit, index) and compound actions (candidate_add, episode_search). This inconsistency reduces predictability.
Tool Count4/5
At 18 tools, the server is slightly above the ideal 3-15 range but each tool addresses a specific aspect of memory management, from candidate review to episode tracking to scoring. The count feels justified by the domain's complexity rather than redundant.
Completeness5/5
The tool set covers the full memory lifecycle: write (add, add_many), review (candidate_*), retrieval (search, list, episode_search), maintenance (verify, score, unsuppress), and deletion (forget, purge), plus auxiliary views (themes, stats, audit, index). No obvious gaps for a semantic memory system.
Average 3.8/5 across 18 of 18 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on August 4, 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?
The description discloses meaningful side-effects: approval publishes evidence, rejection blocks reintroduction via the write gate. However, with no annotations, it omits crucial details like reversibility, permission requirements, or behavior for already-reviewed candidates.
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?
A single, well-structured sentence packs the core action and consequences. No wasted words, and the approve/reject branches are clearly front-loaded.
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?
While the two outcomes are clear, the description lacks important context: what qualifies as a candidate, how to interpret 'évidence' and 'write gate', and what conditions must be met before calling. The 0% schema coverage and absent annotations make this incomplete for reliable 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 any parameter semantics. 'id' and 'reason' are left undefined; only 'decision' is implied through the approve/reject wording. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's dual function: approving a candidate (publishing its evidence) or rejecting it (blocking reintroduction). This specific verb+resource+effect structure distinguishes it from sibling tools like memory_candidate_add or memory_add.
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 given on when to use this tool versus alternatives. It does not mention preconditions (e.g., candidate must be pending) or exclude other tools, leaving the agent to infer context from the name and siblings only.
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 full burden and does well: it discloses permanent deletion, required confirmation, and that audit only keeps a redacted trace. It does not mention reversibility (though 'définitivement' implies irreversible) or potential side effects on related memories, but the key destructive behaviors 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 concise sentences, front-loaded with the main action and then key behavioral constraints. No wasted words; every phrase contributes.
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 destructive tool with no annotations and no output schema, the description covers core aspects (permanence, confirm, audit). However, it omits how id selects the target, the purpose/format of reason, and any return/error behavior. It is adequate but has clear gaps.
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 only 33%, and the description only adds meaning for 'confirm' ('confirmation explicite de la suppression irréversible' is already in schema). The 'id' parameter is implied but not explained, and 'reason' is entirely absent. The description insufficiently compensates 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 clearly states a specific action ('Supprime définitivement le contenu d'une mémoire et ses historiques') with scope, and the title 'Purger une mémoire' reinforces the purpose. It does not explicitly contrast with siblings like memory_forget, though the emphasis on 'définitivement' and audit redaction implies a distinction.
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 mentions a requirement ('Requiert confirm=true') but provides no guidance on when to choose this tool over alternatives such as memory_forget or memory_unsuppress. There are no exclusions or context for appropriate use.
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?
The description discloses that the operation is audited and that evidence is replaced or added, which are important behavioral traits. However, it does not mention permissions, failure modes, or consequences for inactive memories, leaving some transparency gaps given the absence of 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 two short sentences, front-loaded with the primary action and accompanied by a concise audit note. There is no fluff or redundancy, making it highly efficient.
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 annotations or output schema, the description is not complete enough. It lacks context about when to use the tool, the purpose of the reason parameter, and what constitutes an 'active' memory, leaving an AI agent with insufficient guidance for correct invocation.
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 only describes one parameter (evidence), and the description adds no meaningful detail about the required 'id' or optional 'reason'. The phrase 'preuve courte' only reinforces the existing schema description, so parameter semantics are minimally enhanced.
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: marks an active memory as verified and replaces or adds its evidence. This distinguishes it from other memory tools like memory_add or memory_score, and avoids tautology.
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 gives no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It only implies usage for verifying memories, which is not enough direction for an AI agent.
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 discloses that the tool writes and that rejected values are blocked at write time, which is valuable context beyond the schema. However, it omits details about the 'reinforce' behavior (e.g., what happens on duplicate facts), idempotency, or error handling.
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 deliver the core action and a critical constraint without excess. The description is front-loaded with the primary verb and resource, then provides the rejection caveat. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, the description lacks connection to the surrounding workflow (memory_candidate_add, memory_verify, etc.). The rejection behavior hints at a review process but does not explain when to use this tool versus alternatives. With no output schema, more contextual guidance was needed.
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 100%, so the baseline is 3. The description groups optional confidence, evidence, and validity period but does not add new meaning beyond the schema's parameter descriptions. No compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'writes or reinforces' as a specific verb and identifies the atomic fact (subject→predicate→object) as the resource. It also mentions the rejection-by-human-review behavior, which subtly distinguishes it from candidate/review workflows and aligns with the tool's purpose.
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 explicit when-to-use or when-not-to-use guidance is provided. The description implies it is for persisting a fact but never mentions alternatives like memory_candidate_add (for review) or memory_add_many (for batch), leaving the agent to infer context from sibling tool names.
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 of behavioral disclosure. It usefully discloses that purged content is not re-exposed, which is a meaningful safety guarantee. However, it does not explicitly state that the operation is read-only, nor does it mention permissions, response format, or pagination behavior, leaving some 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 a single, front-loaded sentence that conveys the return type, scope, and a key exclusion without wasted words. Every phrase earns its place.
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 read-only audit tool with optional parameters and no output schema, the description is minimally adequate. It covers what is returned and a notable caveat, but lacks usage context, result ordering, limit behavior, and response details, so it is not fully 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?
Schema description coverage is only 50%: the 'id' parameter is documented, but 'limit' lacks a description. The tool description adds no parameter-level meaning and does not explain how 'id' or 'limit' filter the audit log entries. Since coverage is low, the description should compensate but does not.
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 'Retourne' and defines the resource precisely: mutations, revues, dry-runs et purges avec leur raison. It also distinguishes the tool from siblings by explicitly stating that purged content is not re-exposed, positioning it clearly as the read-only audit counterpart to action-oriented tools like memory_purge.
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 states what the tool returns but gives no guidance on when to use it versus alternatives. No exclusions or alternative tools are mentioned, and the use case is only implied by the tool name 'memory_audit'. There is no explicit context like 'use this to review why actions were taken'.
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, the description carries the full burden of behavioral disclosure. It only mentions that it writes atomic facts and follows memory_add semantics, but does not explain whether the batch is atomic, how failures are handled, or any side effects. This is insufficient for a write operation.
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, concise, and front-loaded with the main action. It efficiently communicates the batch nature and the token-saving benefit without unnecessary 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?
Given the tool's moderate complexity (3 parameters, nested array schema, no output schema), the description is too brief. It omits details about the shape of facts, validation, and return behavior, relying on memory_add as an external reference, which may not be available to the agent.
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 only 33% (only 'project' is described). The description does not explain the structure of the 'facts' array, the meaning of 'provenance', or any parameter-specific constraints, instead deferring to memory_add. This 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes multiple atomic facts in a single call ('Écrit plusieurs faits atomiques en un seul appel'), specifying the verb and resource. It also references memory_add to clarify semantics, distinguishing it as the batch counterpart to the single-entry sibling.
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 context: use this tool to save tokens when writing several facts ('économie de tokens'). It also implies that memory_add is for single entries by stating each entry follows its semantics. However, it does not explicitly state when not to use it or mention alternatives beyond memory_add.
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 burden of disclosure. It states the immediate effect (removes a durable suppression) and the consequence (the next write can be evaluated again). However, it does not disclose potential side effects, reversibility of the unsuppression, permission requirements, or what happens to existing suppressed data.
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 short, front-loaded sentences. The first states the primary action, the second the resulting behavior. No unnecessary words or repetition, 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?
Given 4 parameters, no annotations, and no output schema, the description is too sparse. It explains the core action but omits parameter semantics, usage prerequisites, and edge cases. For a mutating tool, more context is needed to ensure correct invocation by an agent.
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 4 parameters with 0% description coverage, and the description does not mention any of them. While the parameter names (subject, predicate, object, project) suggest a memory triple structure, the description adds no explicit meaning, failing to compensate for the schema's lack of elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Retire une suppression durable' (removes a durable suppression), and the title clarifies 'Réautoriser une valeur mémoire' (re-authorize a memory value). This clearly distinguishes it from sibling tools like memory_forget or memory_purge, which perform suppression, by being their inverse.
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 'après une décision explicite' (after an explicit decision) implies the tool should be used when deliberately reversing a previous suppression. However, it does not explicitly contrast with alternatives or mention when not to use it, leaving usage guidance only implied.
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 does disclose an important behavioral trait: the listing does not inject facts into normal retrieval. But it does not mention read-only guarantees, authentication requirements, rate limits, or the shape of the returned data, leaving gaps for a tool with no 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 a single front-loaded sentence that starts with the verb and resource, states the status scope, and adds the retrieval-injection caveat. There is no filler or redundant content.
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 low complexity (three optional scalar parameters) and no output schema, the description captures the core purpose and a key behavioral guarantee. However, it omits return format, ordering, default limit behavior, and explicit relationships to sibling tools, making it minimally adequate rather than 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?
Schema description coverage is 0%, and the description only restates the status enum values (pending/approved/rejected) that are already present in the input schema. It provides no explanation of the 'limit' parameter or the 'project' filter, so the description fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Liste') and resource ('faits... candidats'), enumerates the three statuses, and adds a key scope distinction by noting the listing does not inject facts into normal retrieval. This clearly differentiates it from a general memory list.
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 this tool is for reviewing candidate facts by status, particularly because it mentions pending/approved/rejected and the lack of injection into retrieval. However, it does not explicitly name sibling alternatives such as memory_list or memory_candidate_review, nor does it provide when-not-to-use 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 disclosure. It effectively communicates the pending state ('en attente'), the non-retrievability ('sans le rendre récupérable'), and the permanent outcome of human review ('l'approuver ou le rejeter durablement'). This adds valuable behavioral context beyond a simple 'add' description, though it omits details like side effects or reversibility.
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 concise sentences, front-loaded with the core action and followed by the review consequence. Every word earns its place, with no redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no annotations, no output schema), the description is too minimal. It does not explain parameter meanings, the review workflow's relation to siblings like memory_candidate_list/review, or any return/error behavior. The short description leaves significant gaps for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 12 parameters with zero description coverage, and the description provides no information about any parameter (subject, predicate, object, tags, evidence, etc.). The phrase 'un fait' hints at the triple structure but does not explain the semantics of optional fields, leaving the agent without guidance on parameter usage.
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 core function: 'Place un fait en attente sans le rendre récupérable' (places a fact on hold without making it retrievable). This distinguishes it from siblings like memory_add by specifying the pending state and non-retrievability, and it mentions human review, 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 implies usage when a fact should not be immediately retrievable but rather await human approval, contrasting with direct add tools. However, it does not explicitly name alternatives or state when not to use this tool, so it provides clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that only 'active' memories are returned and that they are sorted by priority with pinned memories first. However, it does not explain default behavior when no filters are given, pagination, or meaning of 'active', leaving some behavioral aspects unclear.
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: the first defines the operation, the second gives usage guidance. It is concise, front-loaded, and every word earns its place.
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 there is no output schema and no annotations, the description should clarify return format and parameter interactions (e.g., crossProject, focus, asOf). It does not mention what a memory entry looks like, what the default limit is, or whether all memories are listed if no filters are provided. This leaves the tool incomplete for a 6-parameter tool.
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 coverage is 67%, so some parameters (limit, project) lack descriptions. The description only mentions filtering by project/theme generically and does not explain any parameter semantics beyond the schema. It does not compensate for the missing parameter 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 clearly states the tool lists active memories for a project and/or theme, sorted by priority with pinned items first. This specific verb+resource+scope distinguishes it from sibling tools like memory_search or memory_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage context: 'à utiliser pour injecter le contexte pertinent au démarrage d'une session ou au changement de sujet.' It does not mention alternatives or exclusions, but the context is clear.
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. It does not explicitly state that the tool is read-only, non-mutating, or safe to call. The content-focused description omits any side-effect or access-related context.
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, concise sentence that front-loads the purpose ('Vue d'ensemble') and enumerates the key output categories. No wasted words, easily scannable.
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 no annotations, no parameters, and no output schema, the description adequately lists the main return content (counters, top priorities, recent changes). It is reasonably complete for a simple stats tool, though it could explicitly mention the read-only nature for full 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 tool has zero parameters, and the schema coverage is 100% (trivially). The baseline of 4 applies, and the description adds context about the output structure 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 identifies the tool's function as providing an overview of memory statistics, listing specific data elements (counters, top priorities, recent changes). It distinguishes itself from sibling tools like memory_list and memory_search by focusing on aggregate stats rather than individual entries.
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 when an overview of memory health or statistics is needed, but it does not explicitly state when to use this tool versus alternatives. There are no exclusions or explicit references to 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?
No annotations are provided, so the description carries the full burden. It discloses that session history feeds future consolidation, which is valuable behavioral context. However, it does not mention return values, side effects, or any limitations (e.g., idempotency, rate limits), so transparency is incomplete.
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, front-loaded with the main action and followed by a clear usage instruction. Every word contributes; no filler or redundancy.
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 add operation with no output schema and no annotations, the description gives the core purpose and timing. However, it omits explanation of the 'project' parameter and what happens after the call (e.g., return value). These are notable gaps for an agent that must 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 coverage is 67% (summary and provenance have descriptions, project does not). The description adds some context by labeling the content as 'résumé épisodique' and mentioning provenance, but it does not clarify the optional 'project' parameter, leaving a 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 saves a session episode (episodic summary + provenance) and explicitly references the 'episode' concept, distinguishing it from sibling tools like memory_add. The verb 'Enregistre' and resource 'épisode de session' make 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 says to call at the end of a conversation, giving a clear context of when to use this tool. It does not explicitly name alternatives, but the context implies it is for episodic session summaries rather than general memory entries.
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 of behavioral disclosure. It states the output (a tree of themes with counts) and its routing purpose, but it does not explicitly state that this is a read-only operation, whether the data is fresh or cached, or any performance characteristics. This is a moderate coverage gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the tool's purpose, the second gives usage guidance. Every sentence earns its place, and the key information is front-loaded. There is no filler.
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 tool with no output schema, the description adequately describes the return value (a tree of themes with counts) and provides usage context. It could mention whether the tree includes all themes or just those with entries, but overall it is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter information. The baseline for 0 parameters is 4, and the description appropriately focuses on the output rather than inputs, which is correct.
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 that the tool provides 'the tree of themes with their counts' and positions it as 'the routing map of memory.' This distinguishes it from sibling tools like memory_search or memory_list, though it lacks an explicit verb and could be more explicit about its differentiation from memory_stats or memory_index.
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 offers explicit guidance: 'Load at the start of session to know where to look, then search by theme at each topic change.' This tells the agent exactly when to use this tool and implies a workflow with other tools (searching by theme), making it highly 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?
With no annotations provided, the description carries the burden of disclosing behavior. It adds useful details: searching session summaries, listing recent episodes when no query is given, and applying a strict threshold comparable to memory search. It does not explain the return format or sort order, but the read-only nature is implied by 'search.'
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 efficiently convey purpose, examples, no-query behavior, and threshold context. Every phrase adds value, and the description is front-loaded with the core function.
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 three optional parameters and no output schema, the description covers the core semantics, usage examples, and a notable behavioral nuance. It could mention the exact return shape or pagination, but the examples and threshold note make it reasonably complete.
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 67%: query and project have meaningful descriptions, while limit is only typed. The description text does not add much beyond the schema, though it references the query behavior contextually. This is adequate but not exceptional.
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 searches through session summaries, calling it the temporal layer, which distinguishes it from the sibling memory_search. It also provides concrete example questions, making the purpose immediately understandable.
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 examples ('what did we do last week?', 'what did we talk about on this project?') indicate when to use the tool. It also notes that omitting the query lists recent episodes, and that the same strict threshold as memory search applies, giving helpful context. However, it does not explicitly name sibling tools as alternatives or state when not to use it.
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 behavioral disclosure burden. It discloses a key behavioral trait: the memory is archived (not deleted) and remains in the base, with the effect of being hidden from search results. This goes beyond a simple 'forget' and clarifies the durability of the operation. However, it does not mention reversibility or potential side effects, so it is not fully exhaustive.
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, concise sentence that efficiently communicates both the action and its consequence. Every word adds value, and the parenthetical clarification is succinct. There is no redundancy or unnecessary detail.
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 (one required parameter, no output schema, no nested objects), the description provides sufficient context. It explains what the tool does and the result of the action. The lack of explicit return-value documentation is acceptable for a simple side-effect operation, and the description is complete 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?
The input schema has 100% coverage for the single parameter 'id', with a description 'Identifiant de la mémoire'. The tool description does not add any further semantics beyond the schema, which is acceptable given the high schema coverage. The baseline of 3 applies since the schema already documents the parameter adequately.
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 (archive a memory) and specifies the exact scope: it no longer appears in searches but remains in the database. This is a specific verb plus resource and distinguishes the tool from deletion or permanent removal, which are plausible alternatives among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you want to archive a memory so it stops appearing in searches while retaining it in the database. It does not explicitly name alternative tools or exclusion criteria, but the behavior is distinct enough to guide an agent. It implies that this is not for permanent deletion, which is a useful implicit guideline.
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 of disclosing behavior. It states that the tool regenerates and returns the index, and explains the auto-injection behavior, which adds context about the file's role and how the call fits into the workflow. It does not mention potential side effects like overwriting, but 'régénère' sufficiently implies a write operation.
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: the first defines the core function and file path, the second explains the automatic injection context and the refresh use case. Every sentence adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is remarkably complete. It covers what the tool does, what the index contains, and when to use it (to refresh the session-injected index). The list of contents gives the agent a clear expectation of the return value, so no additional output documentation 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 input schema has zero parameters, so the baseline score is 4 per the rubric. The description adds no parameter information because none exist, which is appropriate.
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 ('Régénère et renvoie') with a precise resource (the memory index file ~/.memsem/memory-index.md) and enumerates its contents (themes, keywords, pinned items, facts). This clearly distinguishes it from sibling tools like memory_list or memory_search, which focus on searching or listing memory entries rather than regenerating the 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 description explains that the index is automatically injected at the start of each session and that this call is used to refresh it, providing clear usage context. It implies the primary use case (manual refresh) but does not explicitly name alternatives or exclusions, which is why it does not earn a 5.
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 and fully discloses key behaviors: default lexical matching at 50% query word threshold, no graph propagation, ranking by priority, and relax mode performing 2-hop graph associations. This is more than sufficient for a non-mutating search 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 a tight three-sentence paragraph with no redundant details. It front-loads the default behavior, then explains the relax exception, and ends with a usage warning. Every sentence contributes 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?
For an 8-parameter search tool with no output schema, the description covers the essential search semantics and usage caveats. It could go further by describing the result format or ranking details, but the priority ranking is already mentioned and the core behavior is well specified.
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 schema already documents all 8 parameters (100% coverage), but the description adds meaningful behavioral context beyond the schema, such as the 50% threshold interpretation for 'query' and the 2-hop graph traversal for 'relax'. This enriches the schema without duplicating it.
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 identifies this as a memory search tool with specific matching behavior (lexical threshold, priority ranking), distinguishing it from sibling tools like memory_list or memory_themes. The verb 'recherche' and resource 'mémoire' are explicit.
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 contrasts strict default search (suitable for answering) with relax mode (only for exploration) and warns against using relax for answering. While it doesn't name alternative tools, it gives clear contextual guidance on when to use each mode.
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 clearly reveals key guardrails: pinned facts and importance ≥0.9 untouchable, variation capped at ±0.15 per call/pass via passId, and bounds 0.4–0.85. It also explains dryRun behavior ('logue sans appliquer'), which is critical for safe usage.
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 compact and front-loaded, with the primary action stated first. The list of safeguards is dense but each phrase carries meaningful information. The final warning is direct and effective. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, constraints, dryRun behavior, and usage boundaries well. However, since there is no output schema, it does not mention what is returned on success or failure, which would be helpful for agents to interpret results. Still, the description is quite complete for a recalibration tool with such detailed guardrails.
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 already provides descriptions for all 5 parameters (100% coverage), so the baseline is 3. The description adds value by explaining the cumulative cap via passId and clarifying the +/-0.15 constraint, which is not fully detailed in the schema. It also gives a concrete example for 'reason' ('paire: X bat Y'), enriching the meaning of that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Ajuste l'importance d'une mémoire' (adjusts the importance of a memory). It also explicitly distinguishes this from writing a fact with 'Ne pas utiliser pour écrire un fait — uniquement pour recalibrer', setting it apart from sibling tools like memory_add.
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 guidance on when to use the tool: for recalibration only, and explicitly warns 'Ne pas utiliser pour écrire un fait'. This exclusion is clear and directly addresses alternatives, even though it does not name sibling tools explicitly. The mention of 'calibrage par le sub-agent de scoring, comparaisons par paires' gives context for the intended use case.
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:

[![memsem MCP server](https://glama.ai/mcp/servers/WindSeries83/memsem/badges/card.svg)](https://glama.ai/mcp/servers/WindSeries83/memsem)

Score Badge

Copy to your README.md:

[![memsem MCP server](https://glama.ai/mcp/servers/WindSeries83/memsem/badges/score.svg)](https://glama.ai/mcp/servers/WindSeries83/memsem)

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/WindSeries83/memsem'

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