anneal-memory

Server Quality Checklist

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

Latest release: v0.9.6
Disambiguation5/5
Each tool has a distinct purpose: crystal_index and crystal_recall handle crystallized patterns; delete_episode, recall, record, save_continuity handle episodic memory; spore_* tools handle prospective memory with clear operations; status provides health metrics. No two tools overlap in functionality.
Naming Consistency4/5
Most tools follow a verb_noun or noun_verb pattern (e.g., delete_episode, spore_add). The spore family is consistently prefixed with 'spore_'. However, three tools (recall, record, status) are single verbs without a noun, breaking the pattern slightly.
Tool Count4/5
With 16 tools, the count is slightly above the ideal 3-15 range but still reasonable for a feature-rich memory server. Each tool serves a necessary function without redundancy.
Completeness5/5
The tool surface covers the full lifecycle of memory: recording, recalling, deleting, compressing (wrap/save), crystallizing, spore management (add, resolve, update, touch, list, surface), and health monitoring. There are no obvious gaps.
Average 4.2/5 across 16 of 16 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 66 commits in the last 12 weeks
- Last stable release on June 30, 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.
This repository includes a glama.json configuration file.
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.
View related servers

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 full burden. It discloses that in v1 the tool only records a pointer, and the actual write is left to the host. This is a useful behavioral trait. However, it does not cover other aspects like idempotency, error states, or whether the spore state changes, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but packed with domain-specific jargon that may confuse. It is not overly long, but the metaphorical framing reduces efficiency. Some phrases like 'the membrane INTO retrospective memory' are decorative rather than informative, adding noise without earning their 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 the absence of an output schema and the existence of many sibling tools with similar names, the description lacks completeness. It doesn't explain what 'resolving upward' means in contrast to 'descend', nor does it specify what happens to the spore after this action (e.g., is it consumed?). The cryptic language leaves significant gaps for an AI agent.
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 67% (spore_id lacks description). The description adds meaning by explaining that 'ref' is a pointer to what the spore became and that 'kind' must be valid for the spore's type. This elaborates beyond the schema's enum descriptions, helping the agent understand the relationship between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses metaphorical language ('resolve a spore UPWARD', 'membrane INTO retrospective memory') which obscures the primary action. It states that it records a ref and kind, but the core purpose is not clearly defined in plain terms. It partially distinguishes from siblings by specifying that the actual write is deferred, but the jargon reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit constraints on valid kind values based on spore type (task, question, thought), but does not explicitly guide when to use this tool versus siblings like spore_descend or spore_add. There is no 'when to use' or 'when not to use' advice, nor any mention of prerequisites or context.
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 the parameter effect but does not state whether the tool is idempotent, volatile, or what side effects (if any) occur. It implies a read operation but not explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) but the first sentence is awkwardly phrased ('The seed-side surface a salience generator consumes'), reducing clarity. It could be reworded for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns. It mentions 'ranked' but does not describe the output format, fields, or types. The behavior is partially covered but not fully enough for an agent to understand the return value.
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 describes the parameter with 100% coverage (baseline 3). The description adds meaningful context by explaining that top_of_mind=true returns only spores that are 'hot' OR 'growing', ranked across three types, which goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explains the behavior when top_of_mind is true or false, but the overall purpose is vague with jargon like 'seed-side surface a salience generator consumes' without a clear verb indicating what the tool does.
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 guidance on when to use this tool versus its many siblings (e.g., spore_list, spore_get, spore_add). The description does not state prerequisites or alternative scenarios.
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 bears full burden. It discloses the partial update behavior and clearing via empty strings, but lacks details on permissions, error cases, return values, or what happens if the spore is not open. The absence of output schema compounds this 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?
Three concise sentences: first states purpose, second clarifies clearing semantics, third explains what is not done and alternative. No fluff.
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 8 parameters and no output schema, the description covers core logic but omits return format, error handling, and prerequisites for non-open spores. Sufficient for basic usage but not fully comprehensive.
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 50% (4 of 8 params described). The description adds meaning by explaining that empty strings clear next/pointer/domain and that add_note appends a dated note. However, it does not explain spore_id, tier, text, or salience beyond their schema type/enum.
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 'Metadata surgery on an OPEN spore' with a specific verb ('update') and resource ('spore'), and distinguishes from siblings like spore_touch (for bumping seen) and add_note (for notes). It also clarifies that empty strings clear fields.
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 specifies to use this tool only on OPEN spores and directs to spore_touch for engagement signals. It also explains the add_note parameter. However, it does not explicitly state when not to use this tool (e.g., for non-open spores).
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 burden. It states episodes 'accumulate during a session' and serve as raw material for compression, implying additive behavior. It does not explicitly commit to being non-destructive or clarify 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the main action. Every sentence adds necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in a session lifecycle (accumulating episodes for later compression into continuity), the description provides sufficient context. Return value is not described but is a common expectation for write operations.
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 baseline is 3. The description adds value for the 'content' parameter by emphasizing reasoning over facts, but does not enhance understanding of 'source', 'metadata', or 'episode_type' beyond what the schema already describes.
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 the verb 'Record' and specifies the resource as 'a typed episode to memory'. It clearly distinguishes itself from sibling tools (delete_episode, recall, save_continuity) by being the only tool for episodic recording.
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 lists specific triggers for use: important decisions, patterns, tensions, questions, outcomes. It advises recording reasoning over facts. However, it does not mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is a 'close' that does not affect retrospective memory, and explains the special meaning of 'composted'. This provides useful behavioral context beyond the schema.
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 two sentences, front-loaded with the core action. It uses backticks for code-like elements sparingly. No redundant information, though slightly dense.
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 provides essential behavioral context (not crossing into memory) and parameter constraints. However, it lacks explanation of return values or prerequisites, and the spore_id parameter is left undocumented, which is a gap for a tool with two required parameters.
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 only 50% (only 'kind' has a description). The description adds meaning for 'kind' by explaining the type-dependent validity, but does not describe 'spore_id' beyond its schema definition. It partially offsets the gap but is not comprehensive.
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 the specific verb 'resolve' with 'spore', clearly indicating downward action. It distinguishes from siblings by mentioning 'downward' and 'self-clean', and provides a mapping of kind values per spore type, 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 states when to use this tool (to close a spore downward) and contrasts with alternatives by noting it does not cross into retrospective memory. It gives guidelines on valid kind values per spore type, though it does not explicitly name sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses ordering (newest first) and filtering capabilities. However, it lacks mention of rate limits, authentication needs, or side effects, though for a read tool these are less critical.
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, no wasted words. Purpose is front-loaded, and structure is efficient.
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 7 optional params with full schema descriptions, the description covers purpose, use cases, ordering, and filtering. No output schema exists, but the description adequately describes return behavior.
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 100% with descriptions for each parameter. The description adds only a summary of filter types ('time range, type, source, and keyword'), not substantive new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries episodes from memory with filters and gives specific use cases (prior context, citation, review). It distinguishes from write-oriented siblings like delete_episode and record, though not explicitly.
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?
Description explicitly says to call for prior context, citation, or review. It doesn't state when not to use or list alternatives, but the context is clear given sibling tool names.
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?
Despite no annotations, the description discloses key behavioral traits: setting a timestamp, clearing an alarm, and state transition ('returning it to growing'). It reveals the side effect on the spore's state beyond simple mutation.
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?
Extremely concise: two sentences that front-load the action and follow with usage context. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description covers purpose, usage, and basic behavior. Missing parameter details lower completeness slightly, but it is adequate for a straightforward mutation.
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 single parameter `spore_id` has no description in the schema (0% coverage) and the description does not add any meaning or guidance for its value. The tool's purpose implies it identifies a spore, but no clarification is provided on format or source.
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: 'Engage a spore: set `seen` to today and clear an elapsed `next:` alarm'. It uses specific verbs and resource terms, and distinguishes from sibling tools like spore_add or spore_update by focusing on revisiting without resolving.
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?
Explicitly says when to use: 'Call when you revisit an open loop but aren't resolving it'. This provides clear context but does not explicitly mention when not to use or name alternatives, though siblings are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the search order ('searches open first, then resolved') and what the return includes ('full record including computed germination and any resolution'). However, it does not mention what happens if the id is not found (e.g., returns null or error), leaving a minor behavioral 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 extremely concise: two sentences, no filler. The first sentence immediately states the primary action, and the second adds return details. Every word contributes useful information, adhering to the principle of front-loading key 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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the core functionality and return content well. It explains the search behavior and what the response contains. However, it omits the case of a missing spore (error/null) and does not mention that the return is a JSON object, which could be helpful. Still, it is largely complete for a straightforward fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that the id is used for searching in a specific order (open then resolved), which is beyond the schema's format-only description. This enriches the semantic understanding of the single 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 'Fetch one spore by id', which is a specific verb and resource. It distinguishes itself from sibling tools like spore_list (listing) and spore_add (creation) by focusing on single spore retrieval. The additional detail about searching open first then resolved further clarifies its unique behavior.
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 does not explicitly state when to use this tool versus alternatives such as spore_list for multiple spores or spore_surface for a summary. While the search order hint provides implicit context, there is no direct guidance on when not to use it or which sibling tool to choose instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the germination computation at read-time with specific states and conditions. Since annotations are not provided, it carries the full burden and adds value beyond the schema. It does not mention whether the tool is read-only, but the listing nature implies no modification.
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 no redundancy. It front-loads the core purpose and ordering, then efficiently explains the germination states and available filters.
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 listing tool with four parameters and no output schema, the description explains the key behavioral aspect (germination states) and filtering options. It lacks details on pagination, sorting direction, or return format, but covers the essential context.
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 description mentions filtering by 'type, tier, domain, or germination', mapping to all four parameters. However, it does not elaborate on the meaning of each filter beyond the enum values, and 'domain' is a free-form string without further context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'OPEN spores', and the ordering 'by tier then salience then germination'. It distinguishes from the sibling tool 'spore_surface' by stating it's for the salience-generator surface.
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 this tool as 'the working view' and directs to an alternative ('spore_surface') for a different surface. It provides clear context but does not include explicit exclusions.
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 bears full burden. It discloses that spores are open loops that must resolve, the meanings of tier and next (reminder not deadline), and the separation from episodic memory. It lacks some operational details like side effects or persistence, but overall it is transparent enough for an agent to anticipate behavior.
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, dense paragraph that efficiently conveys the core concept, parameter meanings, and connections to sibling tools. It is front-loaded with the primary action and distinguishes the tool from related tools. No extraneous sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, 2 required), the description covers most needs: concept, parameters, and resolution methods. It does not describe return values, but that is acceptable without an output schema. The tool's creative nature is well-contextualized.
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?
All 7 parameters are documented in the schema (100% coverage), giving a baseline of 3. The description adds valuable context beyond the schema: it explains the purpose of 'type' as kinds of openness, defines 'parked' as deliberate dormancy, and clarifies that 'next' is a reminder date not a deadline. This enhances understanding.
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: planting a spore as an open cognitive loop in the PROSPECTIVE layer. It explicitly contrasts with episodic/continuity memory and lists the three types of spores (task, question, thought), making the action and resource unmistakable.
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 when to use the tool (for open intentions that need later resolution) and distinguishes it from other memory types. It also references how to resolve spores (using spore_descend or spore_ascend), providing clear context for usage. However, it does not explicitly 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses cascading deletion of Hebbian associations, audit trail logging, tombstone preservation with specific retained fields (episode ID, timestamp, type, hash), irreversibility, and even GDPR framing and configuration option. This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and is concise given the complexity. Each sentence adds necessary context (cascading, tombstone, audit). However, it is somewhat lengthy for a simple delete operation, but the added detail is justified.
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 complexity of the deletion operation (cascading effects, tombstone policy, audit trail), the description is highly complete. It explains consequences and configuration options. No output schema exists, but the description adequately covers the side-effect behavior.
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 100% with a single parameter 'episode_id' already described as '8-character hex ID' with guidance to use recall or prepare_wrap. The description adds minimal value beyond the schema for parameter semantics, merely reiterating 'by ID'.
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 verb 'delete' and resource 'episode by ID'. It distinguishes from siblings by explicitly noting when to use this tool (for content that should not exist like PII) and when not to (for factual corrections, suggesting alternative 'record').
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 provides when to use (accidentally recorded PII, sensitive data, fundamentally wrong recordings) and when not to use (factual corrections), and names the alternative tool 'record'.
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 provided, so description carries full burden. It comprehensively details validation rules, citation checks, gaming detection, Hebbian association recording, shrink gate behavior, and token verification. Leaves no behavioral ambiguity.
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?
Rather long but well-structured and front-loaded with core purpose. Every sentence conveys important information. Could be slightly tighter, but no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complexity (4 params, nested object, no output schema), the description covers expected return values ('validation results, association metrics, and section sizes'), all parameter behaviors, and usage context. No gaps.
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 100% with detailed descriptions. The description adds meaningful context beyond schema: e.g., effect of affective_state on association strength, wrap_token mismatch error, allow_shrink gate conditions. Adds value to already good parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb (validate and save), resource (compressed continuity file), and context (after compressing episodes using prepare_wrap). Distinguishes itself from sibling tools like prepare_wrap, delete_episode, recall, etc.
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?
Explicitly specifies when to use: after compressing episodes from prepare_wrap. Details required input structure and validation steps. Lacks explicit when-not-to-use or alternatives, but context is sufficiently clear.
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, the description fully discloses behavior: associative search via Hebbian backend, precision-biased, return structure (scored patterns with fields). It also notes the default behavior and the zero-match case.
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 moderately concise; it front-loads the core purpose and adds necessary detail. Each sentence contributes meaning, though a minor trim could improve brevity.
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 no output schema, the description adequately explains the return format (scored patterns with name, level, etc.) and behavior. For a retrieval tool with complete parameter schema, it is comprehensive.
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 100%, but the description adds value by explaining the associative parameter's Hebbian backend in detail and mentioning default values. It doesn't merely repeat schema 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 explicitly states 'Recall crystallized patterns relevant to a free-text query' with a specific verb and resource. It distinguishes itself from siblings by naming 'crystal_index' and clarifying it is an on-demand tier (AM-CRYSTAL).
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 provides clear when-to-use guidance ('Call this when a decision, design choice, or question touches a topic where prior graduated wisdom might apply') and when-not ('a thin query or no match returns none'). It also suggests pairing with crystal_index.
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?
Despite no annotations, the description fully discloses behavior: returns data, marks wrap in-progress, mints a token, and explains that compression reveals patterns. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat lengthy but every sentence adds value. Front-loaded with purpose and usage. Slightly verbose in explaining the token and follow-up, but still focused.
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?
Complete for a complex tool without output schema: explains return values, side effects, and necessary follow-up action (save_continuity). Covers all operational aspects.
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 100%, so description adds extra context beyond schema: explains default derivation for max_chars and default value for staleness_days.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb+resource: 'Prepare a compression package for session wrap.' Distinguishes from siblings like save_continuity and record by focusing on session boundaries.
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 specifies when to call: 'at session boundaries — when work is ending, the user says to wrap up, or the session is getting long.' Also describes the follow-up action with save_continuity and the token round-trip.
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?
Despite no annotations, the description fully discloses behavior: returns a sorted list by name, is deliberately thin to be cheap, and returns nothing when empty. This covers all relevant behavioral aspects for an agent.
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 (two sentences) and front-loaded with the key action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is complete: it explains what is returned, sorting, emptiness behavior, and when to use. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description does not need to explain parameters, but it provides context about the output format and usage, which is sufficient.
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 verb 'List' and the resource 'crystallized INDEX', specifying that it returns a name plus one-clause menu of every live crystallized pattern. It differentiates from sibling tools like 'crystal_recall' by indicating its role as an overview before detailed recall.
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 at session start or when needing to know existing wisdom, and directs to use 'crystal_recall' for full pattern retrieval. The description also notes the empty return state, providing clear guidance on when and why 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully discloses behavior: it is a read-only operation that returns health signals but not integrity proof. It specifies exactly what data is returned and acknowledges limits, leaving no surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is around 100 words, front-loaded with purpose, then lists specifics, and ends with a contrast to the CLI. Every sentence serves a purpose; no fluff.
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 fully complete: it covers all returned data, usage context, and limitations. Nothing is missing for an agent to decide and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters and 100% coverage. The description adds value by detailing the output metrics, effectively documenting the return value for an agent, which is beyond the baseline of 4 for zero-param tools.
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 starts with a clear verb+resource ('Get memory health metrics'), and then enumerates the specific metrics returned. It is easily distinguished from sibling tools (delete_episode, prepare_wrap, recall, record, save_continuity) which cover other operations.
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 call the tool ('at session start to understand memory state, or when diagnosing issues') and provides a clear when-not by referencing the CLI tool 'anneal-memory verify' for integrity proof. No ambiguity.
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:

[![anneal-memory MCP server](https://glama.ai/mcp/servers/phillipclapham/anneal-memory/badges/card.svg)](https://glama.ai/mcp/servers/phillipclapham/anneal-memory)

Score Badge

Copy to your README.md:

[![anneal-memory MCP server](https://glama.ai/mcp/servers/phillipclapham/anneal-memory/badges/score.svg)](https://glama.ai/mcp/servers/phillipclapham/anneal-memory)

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/phillipclapham/anneal-memory'

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