ZeroDB Agent Memory MCP Server

Server Quality Checklist

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

Latest release: v1.2.7
Disambiguation3/5
Several memory retrieval tools (search_memory, semantic_search, synthesize_context) have overlapping objectives, differing mainly in input format and output granularity. The plan and external integration tools are clearly distinct, but the search variants create ambiguity for agents.
Naming Consistency3/5
Most tools use a zerodb_ prefix, but the verb-noun pattern is inconsistent: store_memory is verb-first while plan_create and slack_send are noun-first. Semantic_search uses an adjective rather than a verb, further deviating from a consistent convention.
Tool Count3/5
With 18 tools, the server offers a broad surface for memory management plus external integrations. While not excessive, the count is in the 16-25 borderline range and feels heavy for a memory-focused server.
Completeness3/5
Core memory operations (store, search, retrieve context, clear) are well covered, and plan artifacts include CRUD plus history. However, there is no plan delete or listing, no individual memory deletion, and external service integrations only expose a single action each, leaving notable gaps.
Average 3.8/5 across 18 of 18 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 14 of 31 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions OAuth-based authentication but does not disclose side effects (e.g., the irreversibility of creating a remote issue), success/failure behavior, rate limits, or specific permission requirements. For a mutation tool, this is a significant transparency 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 a single, focused sentence with no redundant or filler words. It is front-loaded with the action, but is somewhat under-specified, so it does not earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with a well-documented schema, but the description lacks important behavioral context (e.g., return values, error cases, or whether the OAuth connection must be pre-configured). It is minimally complete but leaves gaps for an agent to discover.
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 provides complete descriptions for all 4 parameters (repo, title, body, labels), so the description adds no additional parameter semantics. The baseline of 3 is appropriate given the high schema coverage (100%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a GitHub issue' and the resource (a GitHub issue), using a specific verb and resource. It distinguishes itself from sibling tools which target different domains (memory, planning, Slack, Gmail, etc.) and there is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites beyond mentioning the stored OAuth connection, and no exclusions. It simply states the action without contextual cues, leaving the agent to infer usage solely from the tool's name and 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 present, the description carries full responsibility for disclosing behavior. It mentions 'directly search using vector embeddings' but omits critical details such as the relationship and exclusivity between text and vector parameters, expected return format, error behavior, or how similarity thresholds are applied. This creates ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the action ('Search memory by semantic similarity'), and contains no filler or repetitive content. Every word contributes to the core purpose.
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 tool with five parameters and no output schema or annotations, this minimal description is insufficient. It omits crucial context like whether text is still accepted despite the 'without needing a text query' phrasing, how session_id scopes the search, and what min_similarity impacts. The agent would need to infer too much.
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 provides 100% parameter coverage, so the baseline is met. The description's mention of 'vector embeddings' aligns with the vector parameter but adds no new insight beyond the schema. It does not explain parameter interplay or selection strategies for text vs. vector.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches memory by semantic similarity, with a specific focus on vector embeddings. It distinguishes from sibling text-search tools by noting 'without needing a text query' and 'using vector embeddings or similar memories.' This makes the primary purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a vector embedding or semantic similarity is desired, and hints that a text query is not required. However, it does not explicitly name alternative tools (like zerodb_search_memory) or provide when-not-to-use guidance, leaving the choice somewhat to 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 only notes that the tool uses a stored Google OAuth connection, but does not mention side effects (e.g., sending invitations, notifications), whether changes are reversible, or what the response looks like. This is a significant gap for a mutating 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, front-loaded sentence that efficiently conveys the action, resource, and auth method. It contains no redundant or unnecessary information.
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 tool with six parameters and no annotations, the description provides basic purpose and auth context, while the schema covers all parameter details. However, it omits return behavior and potential side effects, leaving some uncertainty about the outcome of the call.
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 each parameter already having a descriptive comment (e.g., start/end in ISO 8601, attendees list, calendar_id default). The tool description adds no additional parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Google Calendar event, with a specific verb ('Create') and resource ('Google Calendar event'). It is distinct from sibling tools like gmail_reply or github_create_issue, which target different services.
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?
There is no explicit guidance on when to use this tool versus alternatives, but the direct action and resource make its intended usage inferable. No exclusions or alternative tools are mentioned, so the agent must infer context from the sibling list and tool name.
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 the full burden. It discloses the mutating action and use of an OAuth connection, but does not mention side effects, error behavior, expected response, or any additional constraints, offering limited transparency beyond the obvious create 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 concise sentence that front-loads the primary action and context with no superfluous content, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema fully covers parameters, but the description does not explain expected return values or post-creation behavior. Without annotations, the description is minimally adequate for invoking the tool but lacks richer 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 100%, so the baseline is 3. The description adds no parameter-specific information; all parameter semantics are derived from the schema, which fully documents each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('Notion page'), and specifies the authentication context ('stored Notion OAuth connection'), distinguishing it from sibling integration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided, but the tool's name and description make it evident that it is for creating Notion pages, implying usage among other integration tools. There are no stated exclusions or alternative guidance.
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?
The description discloses the destructive nature (permanently deletes conversation history), which is important given no annotations are present. However, it fails to mention the required confirmation flag and the optional keep_important behavior that can prevent deletion of important memories, making the claim 'Clear all memories' potentially misleading.
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 very concise, with two short sentences that front-load the action and include a necessary caution. Every word serves a purpose with no extraneous details.
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 tool with no annotations and no output schema, the description is incomplete. It omits the confirmation requirement and the conditional nature of deletion via keep_important, leaving the agent without critical context to safely invoke the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters (100% coverage), so the description adds no additional parameter semantics. Per the rubric, baseline 3 is appropriate when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Clear all memories for a session' with a specific verb and resource. It also notes the permanent deletion of conversation history, distinguishing it from sibling tools like store or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a caution ('Use with caution') and warns about permanent deletion, which implies when not to use it. However, it does not explicitly mention alternatives or specific scenarios where this tool should be preferred, leaving usage guidelines somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states what it does and a general use case, but does not disclose output format, safety/read-only nature, rate limits, or any dependencies (e.g., model download). The lack of output schema makes this gap more significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with a clear verb ('Generate'), and includes only essential information. No wasted words 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?
With no output schema and no annotations, the description should explain return values and integration context. It implies the output is an embedding vector but gives no detail on return format or how the vector can be used. It mentions custom similarity calculations but does not reference sibling tools. Moderate completeness for a simple 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 coverage is 100% with descriptions for all three parameters, including model dimensions and default normalization. The description adds no parameter-specific detail beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 'Generate vector embeddings for text' with a specific verb and resource. It also names the model family (BAAI BGE) and differentiates from siblings by positioning it for 'manual vector operations or custom similarity calculations,' making it distinct from higher-level tools like zerodb_semantic_search.
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?
It provides a clear use case: 'Useful for manual vector operations or custom similarity calculations,' which serves as guidance for when to use this tool. However, it does not explicitly name alternative tools or state when not to use it. The context is sufficient but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool uses a stored OAuth connection and sends from the connected account, indicating a mutation. However, it does not mention potential side effects like the reply being appended to the thread, failure modes, rate limits, or permission requirements. The description is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no redundant or extraneous information. Every clause adds value by explaining the action and the authentication mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description covers the core functionality and authentication but leaves gaps about the return value, error behavior, and prerequisites beyond the OAuth connection. Given the simplicity of the tool, it is adequate but could be more complete by mentioning what happens after a successful reply.
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 provides complete descriptions for all three parameters (thread_id, body, cc), achieving 100% schema coverage. The tool description adds no extra parameter semantics beyond what the schema already offers, so the baseline score of 3 is appropriate.
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 ('Reply to a Gmail thread') and the resource (Gmail thread) with the method (using stored Google OAuth). It distinguishes itself from sibling tools like Slack send or calendar create by focusing on Gmail replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no explicit guidance on when to use it versus alternatives. There are no exclusions or context about when this tool is preferred over other communication methods. Usage is implied from the tool's name and function, but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does disclose some behaviors: automatic importance scoring, embedding, multi-session tracking, and decay. However, it does not mention side effects like whether writes are idempotent, whether existing memories are overwritten, or what output/confirmation is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose, and each sentence adds value without redundancy. It is appropriately sized for 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?
With no output schema and no annotations, the description should explain what happens after storage, including return values or how to reference memories later. It covers key behaviors but omits practical details like confirmation or error scenarios, leaving the agent with some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented with descriptions and defaults. The tool description adds no parameter-specific guidance beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Store') and resource ('conversation context in agent memory'), and adds distinctive details like 'automatic importance scoring and embedding'. It clearly differentiates from sibling tools like search_memory and semantic_search.
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 through 'Store conversation context' and mentions 'multi-session tracking and memory decay', but it does not explicitly state when to use this vs alternatives or provide exclusions. No comparison with sibling tools is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'get' conveys a non-mutating read operation, but the description does not disclose response format, error behavior, or whether the configuration might be absent. It is basic but not misleading.
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, front-loaded sentence with no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool, the description is adequate for basic invocation. However, without an output schema or annotations, it does not describe the returned configuration structure or any edge cases, leaving slight ambiguity.
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% coverage with a clear description of agent_id as 'Agent identifier to retrieve configuration for'. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and clearly identifies the exact resource ('current auto-context configuration for an agent'). It distinguishes itself from the sibling tool zerodb_configure_auto_context, which implies setting/modifying the configuration.
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 a retrieval use case but does not explicitly state when to use this tool versus alternatives like zerodb_get_context or zerodb_configure_auto_context. No exclusions or alternative calls are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that the tool searches semantically and supports cross-session/filtering, but it does not explicitly state that it is read-only or describe result behaviors like ranking or return format. Some context is added, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary verb and object, and contains no redundant phrasing. It efficiently communicates the core action and notable features, with clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the search returns (e.g., list of memories, relevance scores). It provides a high-level purpose but omits result format and any side-effect information. The misleading 'time range' also undermines completeness. The tool's moderate complexity is not fully addressed.
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 covers all 7 parameters with descriptions (100% coverage), giving a baseline of 3. However, the description claims filtering by 'time range,' but no such parameter exists in the schema—only tags, user_id, session_id, scope, limit, and min_importance. This misleading statement reduces clarity and adds confusion, warranting a lower score.
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 states a specific verb and resource: 'Search agent memory semantically using natural language queries.' It clearly distinguishes the tool from siblings by focusing on agent memory and cross-session capabilities, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (searching agent memory) and highlights key capabilities like cross-session search and filtering. However, it does not mention exclusions or alternatives, such as when to prefer zerodb_get_context or zerodb_semantic_search.
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 full behavioral disclosure burden. It does add useful context by revealing that the tool uses Claude Haiku for synthesis and returns a ready-to-use string. Yet it omits potential latency/cost implications, read-only guarantees, or rate limits, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two focused sentences: the first states the core purpose, the second explains the process and output. Every sentence adds value with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's function, the synthesis pipeline, and output format options (narrative, bullet, structured), which is fairly complete given no output schema or annotations. It could mention the non-deterministic nature or cost of the LLM call, but it is otherwise adequate.
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 all parameters already have descriptive entries. The description adds a high-level pipeline overview but does not provide additional detail on individual parameter semantics beyond what the schema offers, staying at baseline.
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 retrieves memories and LLM-synthesizes them into a context string, specifying the verb, resource, and output. However, it does not explicitly distinguish it from sibling tools like zerodb_get_context or zerodb_search_memory, which might have overlapping functionality.
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 a clear use case ('for grounding AI responses') and outlines the process flow (search, retrieve, synthesize). It does not, however, state when not to use this tool or mention alternatives for simpler retrieval, so exclusions are missing.
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 clearly explains the primary side effect: when enabled, the tool causes relevant memories to be automatically retrieved and prepended to every tool call. It also uses the term 'ambient' to convey the automatic background nature. However, it does not mention details like per-agent scoping or potential performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the primary purpose. It avoids redundancy and provides a concrete example of the behavior ('agents get memory without calling recall() explicitly'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration tool with no output schema, this description is reasonably complete. It explains the core behavior and captures the value proposition. It could be slightly more complete by mentioning that the configuration is scoped to an agent (which the schema does) or by hinting at the customization parameters, but the essential context is present.
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 baseline is 3. The description does not add extra meaning beyond the schema's property descriptions; it only explains the overall feature rather than parameter specifics. The schema already covers 'enabled', 'auto_trace', 'max_results', and 'synthesis_style' adequately, so the description adds no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to configure ambient memory injection. It uses a specific verb ('configure') and resource ('ambient memory injection'), and it explains what that means by describing the automatic retrieval and prepending of memories. This distinguishes it from sibling tools that perform actual recall or storage operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by contrasting with 'calling recall() explicitly'—you use it to enable automatic memory injection instead of manual recall. However, it does not explicitly state when to use it versus alternatives like zerodb_get_auto_context_config, nor does it provide any exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses persistence and the return of an artifact ID, but does not mention error handling, overwrite behavior, or authorization needs. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently state purpose and return value, with no redundant content. The first sentence is front-loaded with the core action, and the second adds actionable integration context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with a simple four-parameter schema and no output schema, the description adequately covers purpose, persistence, and the returned artifact ID. It does not specify failure modes or exact response format, but this is sufficient for the complexity level.
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 each parameter already described. The description adds no parameter-specific insight beyond echoing the artifact type enum, so it does not exceed the baseline provided by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the object ('a persistent plan, PRD, or task artifact'), and the location ('in ZeroDB'). It also mentions integration with sibling tools (plan_get/update/history), differentiating it from those read/update tools.
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: it is for creating persistent artifacts that can be referenced later. It implies a workflow of creating then using the ID with plan_get/update/history. It does not explicitly exclude alternatives, but the context is sufficient.
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 a heavier burden. It does add behavioral context by explaining the authentication mechanism: 'uses the token from your connected Slack account in ZeroDB.' However, it doesn't disclose potential failure modes (e.g., no Slack connection), rate limits, or confirm side effects beyond the obvious message send. This partial transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action ('Send a Slack message'). Every word adds value: it specifies the method (stored OAuth connection), clarifies the authentication advantage (no API key), and ties it to the ZeroDB context. Zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only 3 parameters and no output schema, the description covers the essential context: auth method, token source, and required connection. It doesn't explain return values or edge cases, but given the tool's simplicity and the schema's high coverage, it is largely complete. A minor gap is not mentioning what happens if no Slack connection exists.
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 baseline is 3. The description does not add parameter-level semantics beyond what the schema already provides. It mentions 'Slack message' generically, but each parameter (channel, message, thread_ts) is already well-described in the schema. The description adds no extra value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Send a Slack message' using a stored OAuth connection. The verb 'send' plus the explicit resource 'Slack message' is specific and unambiguous. It distinguishes itself from sibling tools by explicitly naming Slack, which is not covered by any other sibling.
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 on when to use this tool: whenever you need to send a Slack message. It also explains that no API key is required, implying the prerequisite of a connected Slack account. While it doesn't explicitly list alternative tools or exclusions, the context is sufficient for this simple send operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: automatic token management, memory decay, and prioritization of important/recent memories. This goes beyond the name and gives useful insight into how pruning works, though it doesn't specify return format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the main purpose, and includes no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main functionality and behavioral features but lacks explicit mention of the return value structure, which is important given no output schema exists. It also doesn't address prerequisites or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description's mention of token management and memory decay loosely connects to max_tokens and include_stats, but it doesn't add substantial meaning beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full conversation context window for a session, using a specific verb and resource. It distinguishes from siblings by focusing on session context retrieval with smart pruning, which is distinct from search or synthesis tools.
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?
It provides clear context for when to use the tool (retrieving full session context) but does not explicitly mention alternatives like zerodb_synthesize_context or zerodb_search_memory, nor does it give exclusions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It uses 'Retrieve' to imply a read-only operation, and 'restore' suggests state recovery. However, it does not disclose outcomes for missing IDs, errors, or any side effects, leaving some ambiguity for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the primary function, and the second adds usage context. It is front-loaded, efficient, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one well-documented parameter and no output schema, the description covers the core purpose and typical usage scenario. It is sufficiently complete for an agent to understand when and how to use it.
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 provides full coverage of the 'id' parameter with a clear description ('Artifact ID returned by zerodb_plan_create'). The tool description adds little beyond that, so baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve a plan artifact by ID') and identifies the specific resource (a plan artifact). This distinguishes it from siblings like zerodb_plan_create, zerodb_plan_update, and zerodb_plan_history, which handle different operations.
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 a clear when-to-use scenario: 'Use this at session start to restore a plan from a previous session.' This gives practical context, though it does not explicitly mention alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the return type (list of diffs) and the nature of the operation ('Get' → read-only). It does not detail potential errors, ordering, or whether the current version is included, but for a simple history retrieval, the key behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and wastes no words. It succinctly conveys both the purpose and the output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is reasonably complete. It explains the return type (list of diffs) but does not elaborate on diff structure or ordering. For a minor gap like this, a 4 is appropriate; a 5 would require explicit mention of edge cases or detailed output shape.
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 only parameter 'id' already described as 'Artifact ID'. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (version history for a plan artifact), and specifies the return type (list of diffs). It is distinct from sibling tools like zerodb_plan_get, which fetches the current plan, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to see how a plan evolved. It does not explicitly mention alternatives or exclusions, but the phrase 'version history' implies usage for audit or change tracking, which differentiates it from the current-state getter. However, it stops short of stating when not to use it or explicitly comparing with plan_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait beyond a simple update: 'Content changes are diffed and stored in version history automatically.' This informs the agent that updates are non-destructive and that history is preserved. With no annotations provided, this adds meaningful transparency, though it does not cover permissions, rate limits, or error 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, focused sentence that front-loads the primary verb and resource. It avoids redundancy and earns its place by adding the versioning detail. No fluff or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, no annotations, no output schema), the description covers the essential purpose and a critical behavioral aspect. It does not explain return values, but for a straightforward update tool this is acceptable. The versioning context also enriches the overall understanding. It falls short only in not providing explicit usage guidelines, which are implied by sibling names.
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 already documents all four parameters with 100% coverage, so the baseline is 3. However, the description adds semantic value by explaining that 'content' changes are diffed, which affects how the content parameter should be used. It also implies that the 'id' selects an existing artifact, reinforcing the purpose of the required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update a plan artifact.' The verb 'Update' is specific, and 'plan artifact' distinguishes it from sibling tools like create, get, and history. The mention of 'version history' further aligns with the plan tool family, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing plan artifact, but it does not explicitly contrast with zerodb_plan_create or provide when-not-to-use guidance. The intent is inferable from the sibling tool names, but the description itself offers no direct alternatives or exclusions.
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:

[![ainative-zerodb-memory-mcp MCP server](https://glama.ai/mcp/servers/AINative-Studio/ainative-zerodb-memory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/AINative-Studio/ainative-zerodb-memory-mcp)

Score Badge

Copy to your README.md:

[![ainative-zerodb-memory-mcp MCP server](https://glama.ai/mcp/servers/AINative-Studio/ainative-zerodb-memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AINative-Studio/ainative-zerodb-memory-mcp)

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/AINative-Studio/ainative-zerodb-memory-mcp'

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