Memory Custom

by BRO3886

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes focused on knowledge graph operations, but 'open_nodes' and 'search_nodes' could be confused as both involve accessing nodes. The descriptions clarify that 'open_nodes' retrieves specific nodes by name while 'search_nodes' queries based on content, but the overlap in node retrieval might cause misselection.
Naming Consistency4/5
Tools follow a consistent verb_noun pattern (e.g., add_observations, create_entities) with minor deviations. 'get_current_time' uses 'get' instead of a more domain-specific verb, and 'open_nodes' uses 'open' which is less common in this context, but overall the naming is readable and mostly predictable.
Tool Count5/5
With 10 tools, the count is well-scoped for managing a knowledge graph, covering creation, deletion, reading, and search operations. Each tool earns its place by addressing specific aspects of entity, relation, and observation handling, without feeling excessive or insufficient.
Completeness4/5
The tool set provides good coverage for knowledge graph CRUD operations, including create, read, and delete for entities, relations, and observations. A minor gap is the lack of update tools (e.g., update_entities or update_relations), which agents might need to work around by deleting and recreating, but core workflows are supported.
Average 2.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Read' which implies a read-only operation, but doesn't address critical aspects like performance implications of reading 'entire' graphs, potential memory issues, authentication needs, error conditions, or return format. For a tool with no annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single four-word sentence that's front-loaded with the core action. There's zero wasted language, and it efficiently communicates the basic purpose without unnecessary elaboration. This represents ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (reading 'entire' knowledge graphs), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'reading' entails (e.g., returns structure, format, size limitations), doesn't address performance or memory concerns, and provides no context about the relationship between the memory file and the graph. For a potentially resource-intensive operation, this leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'memoryFilePath' well-documented in the schema. The description adds no parameter-specific information beyond what the schema provides—it doesn't explain what a 'memory file' is, how it relates to the knowledge graph, or provide context about the file path format. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Read the entire knowledge graph' clearly states the verb ('Read') and resource ('knowledge graph'), but it's vague about scope and specificity. It doesn't distinguish from sibling tools like 'search_nodes' or 'open_nodes', which also likely read graph data. The phrase 'entire' adds some scope but remains ambiguous about what constitutes 'entire' versus partial reads.
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. With siblings like 'search_nodes' and 'open_nodes' that likely read graph data in different ways, the description offers no context on usage scenarios, prerequisites, or exclusions. This leaves the agent guessing about the appropriate context for this tool.
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 states the tool adds observations but does not cover critical aspects such as whether this is a mutation (implied by 'Add'), potential side effects (e.g., overwriting existing observations), authentication needs, error handling, or rate limits. This is inadequate for a tool that modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent 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 of a mutation tool with no annotations, no output schema, and incomplete parameter coverage (50%), the description is insufficient. It fails to address behavioral traits, return values, or detailed usage scenarios, leaving the agent with significant gaps in understanding how to invoke and interpret results from this tool.
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 50%, with 'observations' and 'memoryFilePath' documented in the schema but lacking details in the description. The description adds minimal value by hinting at the purpose ('Add new observations to existing entities'), but does not elaborate on parameter semantics beyond what the schema provides, such as format expectations for 'entityName' or 'memoryFilePath'.
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 ('Add new observations') and target ('to existing entities in the knowledge graph'), distinguishing it from siblings like 'create_entities' or 'delete_observations' by focusing on updating existing entities. However, it lacks specificity about what 'observations' entail (e.g., text notes, metadata), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding observations to existing entities but provides no explicit guidance on when to use this tool versus alternatives like 'create_entities' or 'delete_observations', nor does it mention prerequisites (e.g., entities must already exist). This leaves gaps in contextual decision-making for the agent.
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 indicates a write operation ('create') but doesn't mention permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond the basic action.
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 wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without being overly brief or verbose.
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?
For a mutation tool with no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is inadequate. It should explain more about the creation process, expected outcomes, or error conditions to help an agent use it correctly, given the complexity implied by batch entity creation.
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 50%, with the 'entities' parameter well-documented in the schema but 'memoryFilePath' lacking description. The tool description adds no parameter-specific information beyond what's implied by the name ('create multiple new entities'), so it doesn't compensate for the coverage gap. Baseline 3 is appropriate as the schema handles half the parameters adequately.
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 multiple new entities') and the target resource ('in the knowledge graph'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'create_relations' or 'add_observations' beyond the basic resource difference, preventing 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 'add_observations' or 'create_relations', nor does it mention prerequisites, constraints, or typical scenarios for batch creation. It merely states what the tool does without contextual usage information.
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 states the tool creates relations, implying a write operation, but doesn't cover permissions, side effects, error handling, or response format. The 'active voice' note is trivial and doesn't add meaningful behavioral insight, leaving 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. However, the 'active voice' note is somewhat redundant and doesn't add value, slightly detracting from perfect conciseness.
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 of a mutation tool with no annotations, 50% schema coverage, and no output schema, the description is insufficient. It lacks details on behavioral traits, error cases, and return values, making it incomplete for safe and effective agent use in a knowledge graph context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with the 'relations' parameter well-documented but 'memoryFilePath' lacking context. The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining the structure of relations or the purpose of the memory file. Since schema coverage is moderate, the baseline score of 3 is appropriate, as the description doesn't compensate for 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 ('Create multiple new relations') and the resource ('between entities in the knowledge graph'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'delete_relations' or 'create_entities', and the 'active voice' note is stylistic rather than functional, so it doesn't reach the highest clarity level.
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_entities' or 'delete_relations', nor does it mention prerequisites or context for usage. It's purely functional without any operational context, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the deletion action without disclosing critical behavioral traits. It doesn't mention if deletion is permanent, requires specific permissions, affects related data beyond relations, or has rate limits. The phrase 'and their associated relations' adds some context but is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the action, scope, and resource without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive mutation with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error handling, return values, or safety considerations, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional meaning beyond implying 'entityNames' refers to entities in a knowledge graph, which is redundant with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Delete multiple entities and their associated relations') and the resource ('from the knowledge graph'), making the purpose unambiguous. It distinguishes from siblings like 'delete_observations' and 'delete_relations' by specifying entities and their relations, though it doesn't explicitly contrast 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 'delete_observations' or 'delete_relations', nor does it mention prerequisites such as needing existing entities. The description implies usage for bulk deletion but lacks explicit 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool deletes observations, implying a destructive mutation, but doesn't specify if deletions are permanent, require specific permissions, or have side effects like cascading changes. This leaves critical behavioral traits undocumented for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and target without unnecessary words. Every part earns its place by concisely conveying the tool's purpose, making it easy for an agent 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 tool's complexity as a destructive mutation with no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It lacks details on behavior, return values, error handling, or how it integrates with sibling tools, leaving gaps for effective agent use.
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 50%, with parameters 'deletions' and 'memoryFilePath' documented in the schema but not in the description. The description doesn't add meaning beyond the schema, such as explaining what 'observations' entail or how 'memoryFilePath' relates to the knowledge graph. Baseline 3 is appropriate as the schema provides some coverage without description enhancement.
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 ('Delete') and target ('specific observations from entities in the knowledge graph'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like 'delete_entities' or 'delete_relations', which would require mentioning it only removes observations rather than entire entities or relationships.
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 like needing existing entities or observations, nor does it compare to siblings such as 'delete_entities' for broader deletions or 'add_observations' for additions, leaving the agent without contextual usage cues.
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 deletes relations, implying a destructive mutation, but fails to mention critical aspects like required permissions, whether deletions are reversible, error handling for non-existent relations, or batch operation limits. This leaves significant behavioral gaps for a destructive 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 that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent 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?
For a destructive mutation tool with no annotations and no output schema, the description is inadequate. It lacks essential context such as what happens after deletion (e.g., confirmation, error messages), side effects on the knowledge graph, or dependencies like required file formats for 'memoryFilePath'. This leaves the agent with insufficient information for safe and effective use.
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 description coverage is 100%, with clear documentation for both parameters ('relations' and 'memoryFilePath'). The description doesn't add any meaningful parameter semantics beyond what's already in the schema, such as format examples or constraints, so it meets the baseline for high schema coverage without providing extra value.
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 ('Delete') and resource ('multiple relations from the knowledge graph'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'delete_entities' or 'delete_observations', which prevents 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 'delete_entities' or 'delete_observations'. There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'opens' nodes, which suggests a read operation, but doesn't clarify if this is a safe read, what permissions are needed, whether it modifies state, or what the output format might be. The description lacks critical behavioral context for a tool interacting with a knowledge graph.
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, clear sentence with zero wasted words. It's appropriately sized and front-loaded with the core purpose, making it easy to scan and understand 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 of a knowledge graph tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'opening' nodes entails (e.g., retrieving details, expanding views), what data is returned, or how it differs from sibling tools. For a tool with two required parameters and potential behavioral nuances, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('names' and 'memoryFilePath') adequately. The description adds no additional meaning beyond implying that 'names' refer to entity names in the knowledge graph, which is minimal value over the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('open') and target resource ('specific nodes in the knowledge graph by their names'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'read_graph' or 'search_nodes', which might have overlapping functionality for accessing graph data.
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 'read_graph' or 'search_nodes'. It mentions opening nodes 'by their names', which implies a prerequisite of knowing exact names, but doesn't explicitly state this or compare to other tools for different access patterns.
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 states the tool searches based on a query but does not describe key behaviors: whether it returns partial matches, supports pagination, has rate limits, requires authentication, or what the output format is (e.g., list of nodes with details). For a search tool with zero annotation coverage, this is a significant gap in transparency.
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 is front-loaded with the core action ('Search for nodes'), making it easy to parse. Every part of the sentence earns its place by specifying the resource and context, though it could benefit from more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (searching a knowledge graph with 2 required parameters) and the lack of annotations and output schema, the description is incomplete. It does not explain what 'nodes' include, how results are returned, or any behavioral traits like search scope or limitations. For a tool with no structured output information, the description should provide more context 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?
The input schema has 100% description coverage, with clear documentation for both parameters ('query' and 'memoryFilePath'). The description adds no additional meaning beyond the schema, such as query syntax examples or memory file path constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
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 as 'Search for nodes in the knowledge graph based on a query', which specifies the verb ('search'), resource ('nodes'), and scope ('knowledge graph'). It distinguishes from siblings like 'open_nodes' (likely for opening specific nodes) and 'read_graph' (likely for reading the entire graph), though not explicitly. However, it could be more specific about what 'nodes' encompass (e.g., entities, relations, observations).
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 does not mention sibling tools like 'open_nodes' (which might retrieve specific nodes) or 'read_graph' (which might fetch the entire graph), nor does it specify prerequisites (e.g., needing a memory file path). Without such context, an agent might struggle to choose between this and other tools for accessing graph data.
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 for behavioral disclosure. 'Get the current time' implies a read-only operation, but it doesn't specify what time format is returned, whether it's server time or system time, if there are rate limits, or any authentication requirements. This leaves significant behavioral 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 perfectly concise at three words, front-loaded with the core action, and has zero wasted sentences. Every word earns its place by directly stating the tool's function without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks context about the returned time format or timezone, which would be helpful for an agent to understand what to expect. Without output schema, some return value guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any. The baseline for 0 parameters is 4, as it avoids unnecessary detail.
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 a specific verb ('Get') and resource ('current time'), making it immediately understandable. However, it doesn't differentiate from sibling tools, which include various CRUD operations on different resources, so it doesn't reach the highest 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. With sibling tools like 'read_graph' or 'search_nodes' that might involve time-related queries, there's no indication of when this simple time-fetching tool is preferred over more complex options.
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:

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

Score Badge

Copy to your README.md:

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

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/BRO3886/mcp-memory-custom'

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