Myelin

by et-do

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a clearly distinct operation on the memory system: stats for aggregation, store/recall/forget for CRUD, pin/unpin for priority memory, decay_sweep for maintenance, status for system info, consolidate for memory processing, ingest for bulk loading, and health for liveness. There is no ambiguity between tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., pin_memory, decay_sweep, consolidate) with no mixing of casing or conventions. The names are concise and descriptive, making the action and target immediately clear.
Tool Count5/5
With 11 tools, the server covers the full lifecycle of memory management (store, recall, forget, pin, unpin, stats, status, consolidate, decay_sweep, ingest, health) without being bloated. Each tool serves a necessary function, and the count feels well-scoped for a memory database server.
Completeness5/5
The tool set provides comprehensive coverage: CRUD operations (create through store/recall/forget), pinning for prioritized recall, bulk ingestion, maintenance through decay_sweep, consolidation for semantic learning, and monitoring via stats/status/health. There are no obvious gaps for a memory system.
Average 4/5 across 11 of 11 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 5, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states 'Remove' without clarifying side effects (e.g., irreversibility, impact on related data, or required permissions). The return line mentions 'confirmation or error' but lacks specifics on what the confirmation looks like.
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 concise and structured, with a clear purpose sentence followed by parameter and return sections. It is front-loaded and uses minimal words, though it could be slightly more compact without losing clarity.
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 simplicity (one parameter, delete operation), the description is mostly complete. However, it lacks details on the output format (the output schema exists but is not referenced) and does not address edge cases like missing IDs or concurrent modifications. This leaves some ambiguity for an agent.
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 0% description coverage, so the description carries the burden. It explains 'memory_id: The ID of the memory to remove', which adds basic meaning but no extra context like format, examples, or constraints. For a single parameter, this is adequate but not enriching.
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 'Remove' and the resource 'memory by ID', clearly distinguishing this deletion tool from siblings like 'store', 'recall', or 'pin_memory'. No tautology; the name 'forget' is clarified by the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as checking that the memory exists, or situations where other tools like 'decay_sweep' might be more appropriate.
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 bears full responsibility for disclosing behavior. It mentions pruning based on 'idle threshold' and 'low access counts' and that it returns a JSON summary, but it does not explain what the threshold is, whether the operation is reversible, what happens to pinned memories, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, clearly front-loaded with the core action. Every sentence provides useful information: the purpose, the mechanism, and the return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema present, the description covers the essential aspects: what it does, how it selects memories, and what it returns. It could elaborate on the idle threshold or any configuration, but given the simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is trivially 100%. The description adds meaning beyond the empty schema by explaining the action (pruning stale memories) and the return value (JSON summary). This is valuable context that the schema alone cannot provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prunes stale memories based on recency and access counts, using specific verbs like 'Prune' and 'Removes'. It distinguishes from siblings like 'forget' (explicit removal) and 'store'/'recall' by focusing on automatic cleanup of unused memories. However, it could be more explicit about the idle threshold and access count criteria, which are not fully defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'forget' for explicit removal or 'consolidate' for merging. It does not state prerequisites, context, or when not to use it. The description implies automated cleanup but lacks explicit usage boundaries.
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 of behavioral disclosure. It indicates the operation is destructive (removing a pin), mentions possible not_found result, but does not clarify whether the memory is deleted or simply unpinned, nor does it state authorization or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences plus an Args section. It is front-loaded with the purpose and includes parameter and return info. No unnecessary text.
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?
With no output schema provided in the input (though context signals indicate it exists), the description mentions the return shape (JSON confirmation or not_found). For a simple single-parameter tool, this is reasonably complete, but could still benefit from clarifying whether 'remove' means deletion or just unpinning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the memory_id parameter as 'The ID of the memory to unpin', which adds clear meaning beyond the schema's minimal 'Memory Id' title. This is good coverage given only one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'pinned memory from the thalamic buffer'. It also mentions the expected return value (JSON confirmation or not_found). This distinguishes it from siblings like pin_memory, but doesn't fully differentiate from related tools like forget.
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 does not provide any guidance on when to use this tool vs. alternatives such as forget or pin_memory. It lacks context about prerequisites (e.g., memory must be pinned first) or scenarios where using this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral effect (always included in recall) and explains the priority parameter's meanings. Without annotations, it carries the transparency burden well, though it omits mention of mutability 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, conceptual analogy, and parameter details. The thalamic relay analogy adds context but may be slightly verbose for an AI agent; still concise overall.
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, parameters, and return format. It references the relevant sibling 'unpin_memory' implicitly but doesn't mention prerequisites or integration with other tools. Given the output schema exists, the return description is sufficient.
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?
The Args section provides clear, human-readable explanations for all three parameters, adding meaning beyond the schema's type and default definitions. Priority values are explicitly mapped to semantic categories.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Pin a memory') and its effect ('always included in recall results'). It distinguishes from siblings like 'unpin_memory' and 'forget' by specifying the persistent inclusion in recall.
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 alternatives like 'store' or 'unpin_memory'. The description does not mention prerequisites or when pinning is appropriate, leaving the agent to infer 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 must disclose behavioral traits. The description suggests a read-only operation by stating 'recall' and 'returns ... memories,' but it does not explicitly confirm no side effects, required permissions, or rate limits. The behavior is implied but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an Args/Returns format and is front-loaded with the purpose. While somewhat lengthy, the parameter descriptions are necessary given the schema coverage. Every sentence contributes, but minor redundancy could be trimmed (e.g., default values for n_results are both in schema and description).
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 complexity (8 parameters, output schema exists) the description is fairly complete. It covers all parameters, return format, and basic semantics. It lacks mention of edge cases (e.g., empty results, error handling) and sorting order, but the output schema presumably defines the exact structure. Overall adequate for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential explanations for each of the 8 parameters, including defaults, examples (e.g., reference_date ISO-8601), and semantics (e.g., agent_id for namespace). This fully compensates for the schema's lack of descriptions and adds significant value.
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 'Recall memories relevant to a query.' The verb 'recall' and resource 'memories' precisely describe the operation. It distinguishes itself from sibling tools like store (write), forget (delete), and stats (aggregate), making the tool's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for querying memories but does not explicitly state when to use it vs. alternatives (e.g., stats for aggregated data, or ingest for adding data). No exclusions or prerequisites are mentioned, leaving the agent to infer usage context from sibling 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?
No annotations are provided, so the description carries the burden. It correctly describes the tool as an information retrieval (dashboard) with no destructive side effects, but does not mention performance implications (e.g., might be expensive on large databases), concurrency behavior, or permission requirements. The level of transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a one-line summary, then a bullet-like list of returned metrics, followed by parameter documentation. This front-loads the purpose and scans well. It could be slightly more concise by merging the parameter and returns sections, but remains 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 the tool's complexity (aggregating many metrics), limited parameters, and the presence of an output schema that documents the return structure, the description is remarkably complete. It explains what each section of the return value covers and how filtering works, leaving no major 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 description coverage is 0%, so the description must explain parameters. It does so effectively: it states 'project restricts results to this project name' and 'agent_id restricts results to this agent namespace', and documents that empty values mean no filtering. This adds clear meaning beyond the schema's minimal 'Project' and 'Agent Id' titles.
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 'KPI dashboard for the memory database' and enumerates specific metrics returned (counts by type, project, scope, etc.), which distinguishes it from siblings like 'status' and 'health' that likely provide operational or health check information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains optional filtering by project or agent_id, but provides no guidance on when to use this tool versus alternatives like 'status', 'health', or 'ingest'. It lacks explicit context on when it is appropriate to call stats or when to avoid it.
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 must stand alone. It correctly indicates a read-only operation ('show') and states the return type, but does not disclose any side effects, rate limits, or whether configuration implies mutable state. Adequate for a read-only 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 extremely concise with two short sentences, front-loading the purpose and briefly summarizing the return value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters, the description provides sufficient context for a simple status read tool. The presence of an output schema likely details the JSON structure, so repeating it is unnecessary. One minor gap: it does not explain what 'memory count' or 'configuration' represent.
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?
There are zero parameters, so the schema is fully covered. The description does not need to add parameter meaning but adds value by describing the return format ('JSON with memory count and configuration').
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 'Show memory system status', which is a specific verb-resource combination. It distinguishes itself from siblings like 'stats' (likely focuses on statistics) and 'health' (likely checks system health).
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 provides no explicit guidance on when to use this tool versus alternatives like 'stats' or 'health'. However, given there are zero parameters and the purpose is clear, usage context is implied as a simple status read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description correctly identifies this as a write/transform operation (not read-only) and mentions it 'extracts entities' and 'builds co-occurrence relationships', implying no destructive side effects. However, it does not disclose concurrency concerns, required state (e.g., must have memories stored first), or whether it can be safely run multiple times (idempotency).
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 with biological analogy front-loaded, then processing details, then return format. No wasted words.
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 an output schema, the description is complete. It explains the abstract purpose, the internal process, and the return value format without needing to detail parameters or schema fields.
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?
No parameters exist, so the baseline is 4. The description adds meaning by explaining what happens during consolidation (entity extraction, relationship building), which compensates for the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'replays episodic memories into the semantic network' using the specific verb 'consolidate'. It distinguishes itself from siblings (store, recall, forget) by explaining its offline processing role similar to hippocampal replay during sleep.
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 is for processing stored memories into long-term semantic structure, but does not explicitly state when to use it versus siblings like 'store' or 'decay_sweep'. No when-not-to-use guidance or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the tool is non-destructive and lightweight, which is a strong behavioral disclosure. The only gap is not explaining what happens if internal state is partially initialized, but for a health check, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence of purpose, then a bullet pointing to return values. Every word earns its place, and it's front-loaded with the key behavioral trait.
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 zero parameters, no annotations, and a simple health check task, the description is complete. It covers purpose, behavior, and return value format (JSON with status and version). 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?
The schema has no parameters, and schema description coverage is 100%, so the baseline is 4. The description adds no param info but doesn't need to.
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 purpose: 'Lightweight health check — returns ok without initializing stores.' The verb 'returns' and resource 'health check' are specific, and the tool distinguishes itself from siblings like 'stats' or 'status' by emphasizing it's lightweight and doesn't initialize stores.
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 'without initializing stores,' implying it's safe to call without side effects. However, it doesn't explicitly state when to use this versus other tools like 'stats' or 'status,' though the context is clear enough for an agent to infer it's a basic readiness check.
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. It explains overwrite behavior, silent failure for malformed relations, agent_id scoping, and return format. This is comprehensive and avoids 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?
The description is well-structured with Args and Returns sections and is front-loaded with the main purpose. It is somewhat lengthy but justified by 10 parameters. Every sentence adds value, so no waste.
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 (10 params, no annotations, sibling tools), the description covers purpose, all parameters with detailed semantics, return values, and edge cases (malformed inputs). It is comprehensive enough for an agent to correctly select and invoke the tool.
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?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains all 10 parameters, including overwrite's response details, relations format with error handling, and agent_id scoping. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Store a memory with optional context metadata,' which is a specific verb+resource. It distinguishes from sibling tools like recall, forget, and ingest by focusing on storage creation.
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 storing memories but does not explicitly state when to use this tool versus alternatives (e.g., ingest for bulk import). However, the purpose is self-evident and adequately differentiated by name and siblings.
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 carries full behavioral disclosure. It details how files are processed (YAML frontmatter overrides, JSON array shape), recursion behavior, and the return summary (stored, skipped, errors). This gives the agent a solid understanding of what the tool does beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (intro, formats, args, returns). While detailed, every sentence earns its place and there is no redundancy. It front-loads the main purpose and then organizes supporting details logically.
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 complexity (multiple formats, options, recursion), the description is complete. It covers all inputs, behaviors, and return values. The output summary is mentioned, and the schema adds further specificity. It is fully adequate for agent invocation.
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?
The description provides an 'Args:' section that describes every parameter beyond the schema: path is absolute/relative, project/scope are overridden by frontmatter, source is a label for all memories, and recursive defaults to true. This adds substantial meaning to the bare schema entries.
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 it 'Bulk-load memories from a file or directory,' with specific verbs ('load') and resources ('memories'). It distinguishes itself from siblings like 'store' (which presumably handles single memories) by emphasizing bulk ingestion from files/directories.
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 clearly implies when to use this tool—when you have memories in a file/directory. It explains supported formats and recursion behavior, providing clear context. However, it does not explicitly mention alternatives or when not to use it, such as pointing to 'store' for individual memories.
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:

[![myelin MCP server](https://glama.ai/mcp/servers/et-do/myelin/badges/card.svg)](https://glama.ai/mcp/servers/et-do/myelin)

Score Badge

Copy to your README.md:

[![myelin MCP server](https://glama.ai/mcp/servers/et-do/myelin/badges/score.svg)](https://glama.ai/mcp/servers/et-do/myelin)

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/et-do/myelin'

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