MemoryMesh

by kilhubprojects

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.8.14
Disambiguation5/5
All 17 tools serve distinct purposes: ask/generate, search passages, manage memory chunks/sources, retrieve documents/entities, graph, index, list, pin, timeline events, etc. No overlapping functionality.
Naming Consistency4/5
Predominantly verb_noun snake_case (e.g., ask_memory, forget_source, list_sources). Minor deviations like 'related_documents' (adjective+noun) and 'index_now' (adverb) slightly break the pattern, but overall clear.
Tool Count4/5
17 tools is slightly above the typical 3-15 range for a coherent set, but the memory management domain warrants many operations (indexing, search, forgetting, pinning, timeline, etc.). Still reasonable.
Completeness4/5
Covers indexing, search (various modes), memory manipulation (forget, pin), source management, entity/graph, document retrieval, timeline/event logging. Missing operations like editing memory chunks, but the surface is largely complete.
Average 4.1/5 across 17 of 17 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 3, 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.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It describes the output but does not disclose side effects, permissions, or whether the operation is safe (read-only). Since it only states what it returns, it lacks transparency about potential impacts or requirements.
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 structured as a docstring with a brief summary and an Args section. It is clear and to the point, though slightly verbose with the Args format. Every sentence contributes meaning, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description adequately explains the return value (statistics) and parameter semantics. It covers what the user needs to know to call the tool, though it could mention potential errors or response format.
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 0% description coverage, so the description's explanation of the parameter adds essential meaning. It clarifies that 'source' accepts a string or null, and that null returns data for all sources. This goes beyond the raw schema, compensating for the lack of schema descriptions.
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 returns indexing statistics for sources, listing specific metrics like indexed documents, total chunks, file type breakdown, and most recent timestamp. While it distinguishes itself from siblings like get_document (retrieves a single document) and list_sources (just lists names), it does not explicitly contrast itself, missing the highest bar for differentiation.
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 is provided on when to use this tool versus alternatives. The description implies use for retrieving source statistics, but it does not mention exclusions (e.g., when to use get_document instead) nor suggest context.
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 must fully disclose behavior. It mentions fetching and indexing, and the dry_run option skips indexing, but does not discuss side effects (e.g., whether indexing is additive or replaces), required permissions, idempotency, or error handling. Minimal transparency.
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, front-loaded with the main purpose, and structured with argument descriptions. It avoids unnecessary words, though the docstring format could be slightly more compact. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should cover return values, side effects on the search index, error conditions, and concurrency. It does not mention what the tool returns, whether it is destructive, or how it interacts with other tools like index_now. The description is inadequate for a state-modifying sync operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% (no parameter descriptions), so the description must add meaning. It explains source_type as connector key or null for all, and dry_run as fetch without indexing, which provides value. However, it lacks specifics on valid source_type values or further details, so it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch documents from one or all configured external connectors') and the resource (external connectors). It differentiates from siblings like forget_source or list_sources by specifying it fetches and indexes, making the purpose specific and distinct.
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 when to use the tool (to run enabled connectors and index documents) and how to specify arguments (source_type and dry_run). However, it does not explicitly guide when not to use it or compare with alternatives like forget_source, leaving implicit usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It only states the basic operation without disclosing details like result ordering, pagination, date format expectations, or whether the operation is read-only.
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 fairly concise and front-loaded with the main purpose. The parameter documentation is bulleted and readable, though minor redundancy exists (e.g., repeating 'Only include documents').
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 good parameter coverage, the description omits critical details: no output schema explanation, no mention of date format or inclusiveness, no pagination or limit behavior, and no error cases. For a tool with five params and no annotations, this is insufficient.
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 input schema has 0% description coverage, and the tool's description adds meaningful explanations for all five parameters (after, before, source, file_type, limit), including examples and clarifications like indexing/modification semantics.
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 lists indexed documents within a date range and mentions use cases like discovery and auditing. However, it does not explicitly differentiate from sibling tools like query_timeline, which may also handle date-based retrieval.
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 a general context ('useful for discovering recently indexed content or auditing') but does not give explicit guidance on when to use this tool versus alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals that the tool returns a ranked list of passages with file paths, scores, and previews, plus an optional extended preview. It does not explicitly state read-only nature or side effects, but the behavior is clear for a 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 concise with a brief summary followed by a bulleted Args list. Every sentence adds value, no redundancy, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers inputs, outputs, and a config-dependent behavior. However, it lacks details on error handling, empty results, or how this tool fits among siblings, making it somewhat incomplete for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains each parameter's purpose and possible values (e.g., query is a natural-language question, top_k clamped 1-50, mode options). It adds meaningful semantics beyond the bare schema.
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 searches a personal knowledge base for passages matching a query, listing returned elements. While it is distinct from siblings like query_timeline or search_by_date, it does not explicitly differentiate itself, hence not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only explains what the tool does, with no guidance on when to use it vs alternatives like ask_memory or search_by_date. No when-not-to-use or context for selection.
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 algorithm: retrieves the first chunk, embeds it, and performs vector similarity. However, it does not mention potential side effects (none expected), rate limits, or what happens if the path is invalid or missing. The disclosure of using only the first chunk is a valuable behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences and a structured Args block. Every sentence adds value, but the heading 'Args' could be considered slightly redundant since the parameter details are clear. No wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain the return format (e.g., what fields returned) or error conditions. While the description covers the algorithm and parameters, it lacks completeness regarding edge cases (empty path, negative top_k) and output structure, making the tool somewhat less predictable.
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?
All three parameters are explained: path as 'absolute file path or synthetic connector URI', top_k as 'number of similar documents to return', and exclude_self as 'whether to exclude the source document'. Since schema description coverage is 0%, the description fully compensates by providing clear semantics beyond the schema types.
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: 'Find documents semantically related to a given file or connector document.' This is a specific verb+resource, and it distinguishes from sibling tools like search_memory (keyword search) and ask_memory (QA), which serve different retrieval needs.
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 vs alternatives. The description does not state when not to use it or mention any prerequisites (e.g., document must already be indexed). The agent must infer usage from the semantic similarity description.
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 details the graph structure: nodes are entities from indexed corpus, edges represent co-occurrence in document chunks, and edge weight is shared chunk count. It also specifies return format. However, it does not mention destructive behavior, rate limits, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections but is somewhat verbose (multiple lines). It could be trimmed without losing clarity, e.g., combining the edge definition more succinctly.
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?
Covers purpose, parameters, and return format (nodes and edges with fields). Given no output schema, this is adequate. However, it lacks details on default behavior, limits, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains both parameters: min_mentions as 'minimum mention count for a node to appear' and entity_type as 'optional entity type filter (e.g. PERSON)'. This adds meaningful context beyond the schema's type and default.
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 it returns the entity co-occurrence knowledge graph, explaining nodes and edges with specific definitions. The verb 'return' and resource 'knowledge graph' are precise, and it distinguishes itself from sibling tools like get_entity by focusing on graph structure.
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 get_entity or search_memory. It describes parameters but does not indicate use cases or scenarios where this tool is preferred.
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 full burden. It explains the indexing action and parameter effects (force skips hash comparison) but does not disclose potential side effects, return values, or rate limits. Basic behavior is 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?
The description is concise, front-loads the main action, and uses a clear Args list. Every sentence is meaningful with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not mention what the tool returns (e.g., success status, job ID). For a tool with 2 parameters, this missing information reduces completeness, though the action and parameters are well explained.
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?
Since schema description coverage is 0%, the description fully compensates by explaining both parameters: 'path' can be None to scan all sources, and 'force' skips hash comparison. This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers an immediate (re-)index of a file, directory, or all sources. The verb 'trigger' and resource 'index' are explicit, and it distinguishes from siblings like 'sync_source' and 'forget_source' by focusing on indexing.
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 you want to re-index) but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'sync_source'). No 'when-not-to-use' statements are included.
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 discloses the return format (file counts, chunk count, disk size) but does not mention any side effects, performance characteristics, or data freshness. For a read-only listing, this is minimally adequate.
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 with two sentences, front-loading the main purpose and then detailing the return summary. No unnecessary 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?
Given no parameters and no output schema, the description provides a good overview of what the tool returns. However, it does not specify whether results are paginated or if there is a limit, which could be relevant for many sources.
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 provides full coverage. The description does not add extra meaning beyond the schema, but that is acceptable. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists configured source directories with indexing statistics, using specific verb and resource. It distinguishes itself from sibling tools that perform memory or modification operations.
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?
No explicit when-to-use or when-not-to-use guidance is provided. While the context implies use for overview of sources, there is no comparison with sibling tools like 'summarize_source' or 'sync_source'.
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 truncation behavior with a truncated flag in the response and preconditions. Could mention error handling for missing files, but overall 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?
Concise and well-structured. The main action is front-loaded, and the argument descriptions are bulleted. No unnecessary 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?
Given no output schema or annotations, the description covers preconditions, parameter semantics, and truncation. It is reasonably complete for a read tool, though missing error behavior details.
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 has 0% description coverage. Description adds meaning to both parameters: path as absolute file path, and max_bytes with truncation behavior. No enum or nested objects, but coverage is good.
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 reads and returns the contents of an indexed file. It specifies the preconditions (file must exist on disk and be indexed) and the parameter meanings, distinguishing it from other tools.
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 when to use the tool (file must be indexed) but does not explicitly state when not to use it or compare with sibling tools like related_documents or search_by_date.
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 conveys it is a retrieval operation with a prerequisite, but does not explicitly state that it is read-only or safe. This is a minor gap, but overall acceptable.
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, with a clear structure: purpose, return value, prerequisite, and parameter details. 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?
For a simple retrieval tool with 2 parameters and no output schema, the description covers purpose, return, prerequisite, and parameter meaning. It lacks error handling or differentiation from related sibling tools, but overall is fairly 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?
Schema description coverage is 0%, but the description includes an Args section that adds detail: 'name' is case-insensitive, 'entity_type' is optional. This provides meaning beyond the schema's type information.
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 retrieves a named entity and its associated document chunks, specifying the return fields (name, type, chunk IDs) and case-insensitivity. It distinguishes from siblings like get_document which retrieves entire documents.
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 mentions a prerequisite (entity extraction enabled during indexing), which sets clear context for when the tool is usable. However, it does not discuss when not to use it or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly discloses key behaviors: pinned chunks are never demoted and receive no decay in relevance scores. It also specifies the return fields. However, it does not mention potential side effects or access requirements.
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, front-loading the purpose in the first sentence, and organized with Args/Returns sections. 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?
For a simple tool with one parameter and no output schema, the description covers purpose, behavior, parameter format, and return structure. It assumes domain knowledge (e.g., 'hot memory tier'), but overall it is sufficiently complete for an 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?
The only parameter 'chunk_id' has no description in the schema (0% coverage). The description provides a specific format: 'Stable chunk identifier <path>:<chunk_index>', adding valuable 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 the tool's purpose: 'Pin a specific chunk to the hot memory tier.' The verb 'pin' and resource 'chunk' are specific, and the sibling 'unpin_memory' further distinguishes it as an inverse operation.
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 the behavioral consequences of pinning (no demotion, full relevance scores) but does not explicitly state when to use this tool versus alternatives. No guidance on prerequisites or scenarios where pinning 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?
No annotations provided, so description carries full burden. It reveals that the chunk stays in hot tier until next maintenance run, which is additional behavioral insight beyond just the action. 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 clear and well-structured with Args/Returns sections. Slightly wordy but front-loaded with the main action. Efficient for the complexity.
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?
With only one parameter and no output schema, the description fully covers input format and return type. It also explains the behavioral effect on tiering, making it complete for this simple 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 0% despite one parameter, but the description includes a docstring for 'chunk_id' with format '<path>:<chunk_index>', adding value beyond the schema's minimal type definition.
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 specific verb 'Remove' and identifies the resource ('chunk'), clearly stating the action of unpinning. It distinguishes from sibling tool pin_memory by contrasting the operation.
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 implies when to use (to reverse a pin) but lacks explicit exclusions or alternatives beyond pin_memory. Mentions the effect on tiering, which provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: top_k clamping (1-20), hybrid search, RAG prompt building, and the null answer with hint when Ollama is unavailable. However, it doesn't cover edge cases like no relevant passages found or other error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet thorough, with clear sections for parameters and return values. Every sentence adds value, and the structure (bullet points, code block) enhances readability without 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?
Given no output schema, the description explains return keys well. It covers input, behavior, and a key failure mode (Ollama unavailable). However, it could address more error scenarios or mention performance considerations like rate limits.
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 adds significant meaning: question is the query, top_k is clamped 1-20 with default 5, model is an optional override. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the knowledge base and generates an answer using a local LLM, distinguishing it from sibling tools like search_memory that likely only retrieve passages. The verb+resource combination 'search and generate an answer' is specific and 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 provides context on when Ollama is unavailable and explains the fallback behavior. While it doesn't explicitly state when to use versus siblings, the name and description imply it's for question-answering. It lacks explicit exclusions or alternative tool references.
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 describes the output structure and purpose clearly, implying a read-only operation. However, it does not explicitly state that it is non-destructive or address any safety concerns, such as no 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 well-structured with a clear front-loaded purpose, followed by Args and Returns sections. Every sentence adds value, and there is no extraneous information.
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 tool with no output schema or annotations, the description provides comprehensive information: purpose, parameter explanations, and detailed return structure. It is sufficient for an agent to use the tool 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?
Input schema has 0% description coverage, but the description's Args section adds meaningful semantics to all three parameters, compensating for the lack. Baseline for 0 params is 4, and the description meets that.
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?
Description clearly states it queries the episodic memory timeline for recent activity, with a specific verb and resource. It explicitly mentions returning chronological events to reconstruct user activity, differentiating it from siblings like search_memory or graph_memory.
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?
Context is given: 'reconstruct what the user was working on during a given period.' This suggests when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states the tool creates a persisted event dict and returns an event_id. No destructive behavior implied. Adequately covers creation behavior without needing to mention auth or rate limits.
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 short and well-structured: one-line summary, contextual usage note, then parameter list. Every sentence adds value without redundancy. Front-loaded with the core action.
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 annotations or output schema, the description provides complete information: what it does, when to use, parameter meanings, and return value (persisted event dict with event_id). No gaps for this tool's complexity.
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 has 0% description coverage, but the description's Args section explains each parameter meaningfully: event_type as 'Category string', source as 'Associated file path or source name', note as 'Free-text annotation stored in metadata.note', chunk_ids as 'Chunk identifiers involved'. Adds substantial value beyond names.
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 records a custom episodic event in the memory timeline, with examples of usage. It distinguishes from search-related siblings (e.g., search_memory) by noting it 'without triggering a search', making the purpose specific and 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 indicates when to use: for annotating significant moments without triggering a search. It gives context (e.g., 'user reviewed this document') but does not explicitly state when not to use or list alternatives like ask_memory. However, the sibling list provides implicit differentiation.
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, description fully discloses that it deletes from multiple stores, is irreversible, and includes a dry_run option. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs: purpose, behavior details, parameter descriptions. No wasted words, every sentence adds value.
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 deletion tool: covers purpose, behavior, consequences, and parameters. No output schema needed for this action.
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 coverage is 0%, but description adds full meaning: source is 'Source name as it appears in the index' with example, and dry_run is 'Preview without deleting.' Exceeds minimal requirement.
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 'Remove all indexed content from a named source' with specific verb and resource, and lists what gets deleted (vector store, BM25 index, SQLite metadata). Distinguishes from siblings like 'forget_memory' and 'sync_source'.
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?
Provides context by noting that the action is irreversible unless re-synced. Does not explicitly exclude scenarios or mention alternatives, but implied usage is 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?
Despite no annotations, the description discloses key behaviors: suppress is permanent and requires direct DB access to reverse, cold decays over time and is reversible via pin_memory. This is thorough 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, bullet points, and front-loaded purpose. 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?
No output schema exists, but the description specifies return format (confirmation dict with fields). Covers all aspects: purpose, modes, parameters, reversal, and permanence consequences.
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 coverage is 0%, but the description fully compensates by explaining chunk_id format (<path>:<chunk_index>) and mode enum values with their effects, adding 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 the tool forgets a memory chunk using two modes (suppress and cold). It uses specific verbs and distinguishes from sibling tools like pin_memory by explaining cold can be reversed.
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 explains when to use each mode (suppress for permanent removal, cold for gradual fading) and mentions pin_memory as a reversal for cold. Provides clear guidance on selection.
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:

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

Score Badge

Copy to your README.md:

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

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/kilhubprojects/memory-mesh'

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