basic-memory

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
There is significant overlap between several tools, creating confusion. For example, 'search' and 'search_notes' appear to serve very similar purposes, and 'read_note' and 'view_note' both seem to retrieve notes with unclear distinctions. However, descriptions help differentiate some tools like 'edit_note' versus 'write_note', preventing complete ambiguity.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., 'create_memory_project', 'delete_note', 'list_directory'), which is clear and predictable. Minor deviations exist, such as 'build_context' and 'canvas' not following this pattern, but they are exceptions rather than the rule, maintaining overall readability.
Tool Count3/5
With 17 tools, the count is borderline high for a memory management server, feeling slightly heavy but not excessive. It covers various operations like CRUD for notes and projects, but the overlap suggests some tools could be consolidated, making the set feel a bit bloated for the domain.
Completeness4/5
The tool set provides good coverage for memory and note management, including create, read, update, delete, search, and project handling. Minor gaps exist, such as no explicit tool for updating project details or managing links beyond moving notes, but core workflows are well-supported, allowing agents to work around these limitations.
Average 3.1/5 across 17 of 17 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 94 of 111 community issues answered or closed in the last 6 months
- 367 commits in the last 12 weeks
- Last stable release on July 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'advanced syntax support' which adds some context about query capabilities, but it doesn't describe what the search returns (e.g., results format, pagination behavior), whether it's read-only (implied but not stated), or any rate limits or authentication needs. For a search tool with 8 parameters and no annotations, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a search tool and front-loaded with the core functionality, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, 0% schema coverage, no annotations) and the presence of an output schema (which might help with return values), the description is incomplete. It doesn't explain parameter usage, behavioral details like pagination or result limits, or how it differs from sibling tools. For a tool with this many undocumented parameters, more context is needed to be minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The tool description doesn't mention any parameters or their semantics (e.g., what 'search_type' or 'entity_types' mean), failing to compensate for the lack of schema documentation. This leaves the agent with no guidance on how to use the parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches across all content in the knowledge base, which provides a clear verb ('search') and resource ('knowledge base content'). However, it doesn't distinguish this from sibling tools like 'search' (which appears to be a simpler search) or 'fetch'/'read_note' (which retrieve specific content), leaving the purpose somewhat vague in relation to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'advanced syntax support' which implies this tool should be used for complex queries, but it doesn't explicitly state when to use this vs. other search or retrieval tools like 'search' or 'read_note'. No guidance is provided on exclusions or prerequisites, leaving the agent to infer usage from context alone.
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 the full burden of behavioral disclosure. It implies a read operation ('fetch'), but doesn't address permissions, rate limits, error handling, or what 'full contents' entails (e.g., format, size limits). This leaves significant gaps for a tool that likely interacts with documents.
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 a single, efficient sentence that is front-loaded with the core action. There's no wasted verbiage, making it appropriately concise for a simple tool, though it could benefit from more detail given the lack of annotations.
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 complexity (simple fetch operation), 1 parameter, and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and low schema coverage, it should provide more context about behavior and parameters to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('id') with 0% description coverage, and the tool description adds no meaning beyond the schema. It doesn't explain what the 'id' represents (e.g., a document identifier from search results) or its format, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'fetches the full contents of a search result document,' which provides a clear verb ('fetch') and resource ('search result document'), but it's somewhat vague about what constitutes a 'search result document' and doesn't differentiate from siblings like 'read_content' or 'read_note.' It avoids tautology by not just restating the name 'fetch.'
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 offers no guidance on when to use this tool versus alternatives such as 'read_content' or 'read_note,' nor does it specify any prerequisites or context for usage. It merely states what the tool does without indicating when it's 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Search') without any details on permissions, rate limits, result format, pagination, or error handling. For a search tool with no annotation coverage, this leaves critical behavioral traits unspecified.
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 a single, efficient sentence with no wasted words. It's front-loaded and to the point, though it could benefit from more detail given the tool's complexity. The structure is clear but overly brief for a tool with no annotations and low schema coverage.
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 moderate complexity (search operation), no annotations, low schema coverage (0%), but presence of an output schema, the description is minimally complete. It states the basic purpose but lacks details on behavior, parameters, and usage context. The output schema helps, but the description doesn't fully compensate for the gaps in annotations and schema.
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 1 parameter with 0% description coverage, so the description must compensate. It mentions 'query' implicitly but doesn't explain what the query parameter expects (e.g., keywords, filters, syntax). Since schema coverage is low, the description adds minimal value beyond the schema, meeting the baseline for adequate but incomplete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for content across the knowledge base' states a clear verb ('Search') and resource ('content across the knowledge base'), but it's vague about what 'content' specifically means and doesn't distinguish this tool from sibling tools like 'search_notes' or 'fetch'. It provides a basic purpose but lacks specificity.
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 offers no guidance on when to use this tool versus alternatives. With siblings like 'search_notes', 'fetch', and 'read_content' available, there's no indication of what makes this search tool unique or when it's preferred over other search or retrieval tools. It's a generic statement with no usage 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 carries the full burden of behavioral disclosure. It mentions viewing as a 'formatted artifact', which implies a read-only operation with enhanced presentation, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what 'formatted' entails. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy to parse quickly, though it could benefit from more detail given the complexity of the tool.
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 has 4 parameters with 0% schema coverage and no annotations, but an output schema exists, the description is incomplete. It doesn't explain parameter meanings or behavioral traits, though the output schema might cover return values. For a tool with multiple parameters and no annotation support, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about parameters like 'identifier', 'project', 'page', or 'page_size', failing to compensate for the lack of schema documentation. This leaves all four parameters semantically undefined, hindering proper tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'View a note as a formatted artifact for better readability', which specifies the verb 'view' and resource 'note'. However, it doesn't clearly distinguish this from sibling tools like 'read_note' or 'read_content', leaving the exact differentiation vague. The mention of 'formatted artifact' adds some specificity but isn't fully clarifying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'read_note' or 'search_notes'. There's no mention of prerequisites, exclusions, or specific contexts where this tool is preferred, leaving the agent with no usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool edits notes with various operations, implying mutation, but doesn't disclose behavioral traits like whether edits are reversible, permission requirements, rate limits, or error handling. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Edit an existing markdown note') and lists operation types. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., bullet points for operations).
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 7 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to explain returns), the description is incomplete. It covers the basic purpose and operation types but misses parameter details, behavioral context, and usage guidelines. It's minimally adequate for a simple edit tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions operations (append, prepend, find_replace, replace_section) which partially explains the 'operation' parameter, but doesn't clarify other parameters like 'identifier', 'content', 'project', 'section', 'find_text', or 'expected_replacements'. The description adds minimal value beyond the schema's property names.
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 action ('Edit an existing markdown note') and resource ('note'), specifying the type of operations available (append, prepend, find_replace, replace_section). It distinguishes from siblings like 'write_note' (create) and 'delete_note' (remove), but doesn't explicitly differentiate from 'view_note' or 'read_note' in terms of when to edit versus read.
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 is provided. It doesn't mention prerequisites (e.g., note must exist), when to choose specific operations, or when to use 'write_note' for new notes instead. The context is implied (editing existing notes), but lacks actionable usage rules.
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 disclosure. It states the tool creates/updates notes and returns a markdown summary, but doesn't cover critical aspects like whether updates overwrite existing notes, authentication requirements, error conditions, or rate limits. This leaves significant gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in a single sentence that states the core function and return value. There's no unnecessary verbiage, though it could be slightly more comprehensive given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, 0% schema coverage, no annotations, but with an output schema, the description is moderately complete. It covers the basic action and return format, but lacks parameter explanations and behavioral context that would be needed for optimal agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 6 parameters, the description provides no information about what the parameters mean or how they should be used. It doesn't mention any of the parameters (title, content, folder, project, tags, note_type) or their purposes, failing to compensate 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create or update') and resource ('a markdown note'), distinguishing it from sibling tools like 'delete_note' or 'edit_note'. However, it doesn't explicitly differentiate from 'edit_note' which might also update notes, making it slightly less specific than a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'edit_note' or 'create_memory_project'. It mentions the tool's function but lacks context about prerequisites, when-not scenarios, or comparisons with sibling tools.
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 the full burden of behavioral disclosure. It states 'Create' which implies a write operation, but doesn't cover critical aspects like permissions needed, whether it overwrites existing files, error handling, or the format of the created canvas. This leaves significant gaps for an agent to understand the tool's behavior beyond basic creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse quickly, which is ideal for conciseness.
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 has 5 parameters with 0% schema coverage and no annotations, but an output schema exists, the description is minimally adequate. It covers the basic purpose but lacks details on parameters, behavioral traits, and usage context, making it incomplete for a creation tool with multiple inputs. The output schema mitigates some gaps, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning all 5 parameters lack descriptions in the schema. The description adds no information about parameters like 'nodes', 'edges', 'title', 'folder', or 'project', failing to compensate for the schema gap. For example, it doesn't explain what 'nodes' and 'edges' should contain or how 'folder' paths are structured.
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 action ('Create') and resource ('Obsidian canvas file') with a purpose ('to visualize concepts and connections'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'create_memory_project' or 'write_note' that might also create files, leaving room for ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_memory_project' or 'write_note', nor does it mention prerequisites or exclusions. It implies usage for visualization tasks but lacks explicit context for distinguishing from other creation tools in the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action is 'Delete', implying a destructive mutation, but fails to disclose behavioral traits such as whether deletion is permanent, reversible, requires specific permissions, or has side effects. This is a significant gap 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 a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary details.
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 has an output schema (which handles return values) but no annotations and low schema coverage, the description is incomplete. It adequately states the basic action but lacks crucial details for a destructive operation, such as behavioral context and parameter explanations, leaving gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by title or permalink', which clarifies the 'identifier' parameter, but does not explain the 'project' parameter or its optionality. The description adds some meaning but does not fully address the undocumented parameters.
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 ('Delete') and resource ('a note'), specifying it can be done 'by title or permalink'. However, it does not explicitly differentiate from sibling tools like 'delete_project' or 'move_note', which also involve deletion 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'edit_note' or 'move_note', nor does it mention prerequisites like required permissions or project context. It lacks explicit usage context or exclusions.
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 but offers minimal behavioral insight. It mentions 'filtering and depth control' but doesn't disclose critical details like whether this is a read-only operation, what permissions are needed, how results are structured, or any rate limits. For a tool with 4 parameters and no annotation coverage, this is inadequate.
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) and front-loaded with the core purpose. Every word earns its place, with no redundant or vague language, making it efficient for quick understanding.
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 moderate complexity (4 parameters, no annotations, but with an output schema), the description is incomplete. The output schema reduces the need to explain return values, but the description lacks guidance on usage, parameter details, and behavioral context, leaving significant gaps for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'filtering' (hinting at 'file_name_glob') and 'depth control' (hinting at 'depth'), but doesn't explain the purpose of 'dir_name' or 'project', nor provide any syntax or format details. With 4 undocumented parameters, this adds minimal value beyond the 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 the tool's purpose with specific verbs ('list directory contents') and resources ('directory'), and mentions capabilities ('filtering and depth control'). However, it doesn't explicitly differentiate from sibling tools like 'search' or 'fetch' that might also retrieve file information.
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 'search', 'fetch', or 'read_content'. The description mentions filtering capabilities but doesn't specify scenarios where this tool is preferred over others or any prerequisites for use.
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 but offers limited behavioral insight. It mentions 'updating database' (implying mutation) and 'maintaining links' (hinting at referential integrity), but lacks details on permissions, error conditions, side effects, or what 'maintaining links' entails operationally. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the action, outcome, and key behavioral aspect ('maintaining links'). It's appropriately sized and front-loaded, making every word count without unnecessary elaboration.
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 a mutation tool with 3 parameters (0% schema coverage), no annotations, but an output schema exists, the description is minimally complete. It covers the core action and hints at behavior, but lacks details on parameters, error handling, and operational context that would be needed for full agent understanding, though the output schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal param semantics. It implies 'identifier' selects the note and 'destination_path' specifies the new location, but doesn't explain formats (e.g., path syntax, identifier types) or the optional 'project' parameter's role. This fails to bridge the coverage gap effectively.
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 action ('Move a note') and the resource ('note'), specifying the outcome ('updating database and maintaining links'). It distinguishes from siblings like 'edit_note' or 'delete_note' by focusing on relocation, but doesn't explicitly contrast with tools like 'write_note' or 'view_note' in terms of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., note existence, permissions), exclusions (e.g., when not to move), or comparisons to siblings like 'edit_note' for content changes or 'delete_note' for removal, leaving usage context unclear.
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 the full burden of behavioral disclosure. It states the tool reads raw content but doesn't mention permissions, rate limits, error handling, or output format. This is a significant gap for a read operation that could involve file access constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose and includes a useful detail ('by path or permalink'), making it appropriately sized and easy to parse.
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 moderate complexity (2 parameters, no annotations, but has an output schema), the description is incomplete. It covers the basic purpose but lacks usage guidelines, parameter details, and behavioral context. The output schema mitigates some gaps, but overall it's minimally viable with clear deficiencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only mentions 'path or permalink' without explaining the 'project' parameter. It adds minimal meaning beyond the schema, failing to clarify parameter roles or usage, which is inadequate given the coverage gap.
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 action ('Read') and resource ('a file's raw content'), specifying it can be done 'by path or permalink'. It distinguishes from siblings like 'read_note' or 'view_note' by focusing on raw file content rather than notes, though it doesn't explicitly compare them.
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 'read_note', 'view_note', or 'fetch'. The description implies usage for reading files but doesn't specify contexts, prerequisites, or exclusions, leaving the agent to infer based on tool names alone.
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 the full burden of behavioral disclosure. It states the action ('Read') but lacks details on permissions, rate limits, error handling, or output format. While it hints at retrieval by identifier, it doesn't clarify if this is a safe read operation or has side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action and key parameter. It's appropriately sized for the tool's complexity, making it easy to parse without unnecessary elaboration.
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 has an output schema (which handles return values), the description's gaps in parameter semantics and behavioral transparency are partially mitigated. However, with 4 parameters and no annotations, it should provide more context on usage and parameters to be fully complete, resulting in an average score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'identifier' (title or permalink), ignoring 'project,' 'page,' and 'page_size.' This partial coverage fails to explain the purpose or usage of most parameters, adding minimal value beyond the 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 the verb ('Read') and resource ('a markdown note'), specifying it can be accessed 'by title or permalink.' This distinguishes it from generic read operations but doesn't explicitly differentiate from sibling tools like 'view_note' or 'read_content,' keeping it from a perfect score.
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 such as 'view_note,' 'search_notes,' or 'read_content.' The description implies usage for retrieving notes but offers no context on prerequisites, exclusions, or comparative scenarios with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool retrieves ('Get') data, implying it's read-only, but doesn't mention behavioral traits like pagination, rate limits, authentication needs, error handling, or what 'recent activity' includes (e.g., events, changes). The timeframe format details are helpful but insufficient for a mutation-free tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by specific timeframe examples. Every sentence earns its place by adding value—no redundancy or waste. The bullet-point list for timeframe formats is structured for clarity without verbosity.
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 4 parameters with 0% schema coverage and no annotations, the description is incomplete. It partially covers 'timeframe' but omits details for 'type,' 'depth,' and 'project.' An output schema exists, so return values needn't be explained, but for a read operation with multiple inputs, more parameter guidance is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'timeframe' by providing natural language and standard format examples, which clarifies semantics beyond the schema's title. However, it doesn't explain 'type,' 'depth,' or 'project' parameters, leaving three of four parameters with minimal guidance. The baseline is lowered due to incomplete compensation.
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's purpose: 'Get recent activity for a project or across all projects.' It uses a specific verb ('Get') and resource ('recent activity'), and distinguishes between project-specific and all-projects scope. However, it doesn't explicitly differentiate from sibling tools like 'search' or 'fetch' that might also retrieve activity data.
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 context by mentioning 'for a project or across all projects,' suggesting this tool is for retrieving activity logs. However, it provides no explicit guidance on when to use this versus alternatives like 'search' or 'fetch,' nor does it mention prerequisites or exclusions. The timeframe examples offer some operational context but not comparative guidance.
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 the full burden of behavioral disclosure. While it explains the tool builds context for conversations and provides format details, it doesn't disclose critical behavioral traits like whether this is a read-only operation, what permissions are needed, whether it modifies data, rate limits, or what the output contains. For a tool with 7 parameters and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with the core purpose, provides usage guidance, then details parameter formats with clear sections. While comprehensive, every sentence serves a purpose - explaining the tool's function, when to use it, and parameter specifics. It could be slightly more concise by integrating some format details more tightly.
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 complexity (7 parameters, memory system interaction) and the presence of an output schema, the description provides good context about the tool's purpose and key parameters. However, with no annotations and incomplete parameter semantics coverage, it doesn't fully prepare an agent for all aspects of tool invocation. The output schema existence helps, but behavioral aspects remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides extensive information about the 'url' parameter format (memory:// URIs, pattern matching, valid characters, examples) and 'timeframe' parameter (natural language and standard formats). With 0% schema description coverage, this adds substantial value beyond the bare schema. However, it doesn't explain the semantics of 'depth', 'project', 'page', 'page_size', or 'max_related' parameters, leaving half the parameters without semantic explanation.
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's purpose: 'Build context from a memory:// URI to continue conversations naturally.' This specifies the verb ('build context') and resource ('memory:// URI'), though it doesn't explicitly differentiate from sibling tools like 'read_note' or 'search_notes' that might also access memory content. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to follow up on previous discussions or explore related topics.' This gives guidance on when to use the tool (for conversation continuity or topic exploration). However, it doesn't specify when NOT to use it or mention alternatives among the many sibling tools, which would be needed for a perfect score.
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 carries the full burden. It discloses that the project directory will be created if missing and mentions the optional default-setting behavior, which adds useful context beyond just the creation action. However, it doesn't cover potential errors, permissions needed, or what happens with existing projects.
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?
Well-structured with clear sections (description, args, returns, example) and front-loaded purpose. The example section is helpful but slightly lengthens the description. Most sentences earn their place, though some formatting could be tighter.
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 3 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameters and includes an output schema (returns confirmation message). It covers the core creation behavior well, though additional context about error conditions or relationships to other tools would make it more complete.
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 fully compensate. It provides clear semantic explanations for all three parameters: project_name (must be unique), project_path (file system path where stored), and set_default (optional default behavior). This adds significant value 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 specific action ('Create a new Basic Memory project') and resource ('project'), distinguishing it from sibling tools like 'list_memory_projects' or 'delete_project'. It specifies the exact operation rather than being vague or tautological.
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 is provided. While it's clear this creates projects, there's no mention of prerequisites, when creation might fail, or how it relates to other project management tools in the sibling list.
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 of behavioral disclosure. It effectively describes the tool's behavior: it lists projects with status, is used for discovery, and includes session management guidance. However, it doesn't mention potential limitations like rate limits, error conditions, or whether the list is paginated.
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 clear sections (purpose, usage guidelines, post-call instructions, returns, example). It's front-loaded with the core purpose. Some sentences could be more concise (e.g., 'Shows all Basic Memory projects...' slightly repeats the first sentence), but overall it's efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations), the description is quite complete. It explains purpose, usage, and behavioral aspects. Since an output schema exists, it doesn't need to detail return values, though it mentions 'Formatted list of projects with session management guidance,' which adds helpful context. Minor gaps include lack of error handling or performance 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on usage and output. A baseline of 4 is applied since there are no parameters to document.
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's purpose: 'List all available projects with their status' and 'Shows all Basic Memory projects that are available for MCP operations.' It specifies the verb (list/show) and resource (projects), but doesn't explicitly differentiate from sibling tools like 'list_directory' or 'search_notes' that might also list resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'At conversation start when project is unknown,' 'When user asks about available projects,' and 'Before any operation requiring a project.' It also includes post-call instructions ('Ask user which project to use,' 'Remember their choice for the session'), which effectively guides usage context.
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 full burden and does an excellent job. It discloses critical behavioral traits: that this is a destructive operation ('cannot be undone'), clarifies what gets affected (configuration and database records but NOT files on disk), and explains the consequence (project would need re-adding to access content).
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 (Args, Returns, Example, Warning) and front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second clarifies scope, and subsequent sections provide practical guidance 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?
For a destructive tool with no annotations, 0% schema coverage, but with output schema present, the description is remarkably complete. It covers purpose, behavioral implications, parameter meaning, example usage, and warnings - providing everything needed for safe invocation despite minimal structured data support.
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 and only one parameter, the description fully compensates by explaining the 'project_name' parameter meaning ('Name of the project to delete') in the Args section. It provides essential semantic context that the schema lacks entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete a Basic Memory project') and distinguishes it from sibling tools like 'create_memory_project' and 'list_memory_projects'. It explicitly mentions what resource is affected ('project') and what system it operates on ('Basic 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?
The description provides clear context about when to use this tool (to remove a project from configuration/database) and includes a warning about irreversibility. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among siblings like 'delete_note' for different operations.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/basicmachines-co/basic-memory'

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