Enables sending Slack messages to channels or threads using stored OAuth tokens.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ZeroDB Agent Memory MCP Server Search my memories for the user's communication preferences"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Persistent Memory for AI Agents
Optimized MCP server providing 14 tools for agent memory management, context synthesis, auto-context middleware, and write-back actions to external services.
Before: Monolithic server with 77 tools consuming 10,400+ tokens After: Focused server with 14 tools consuming ~1,400 tokens Result: 87% reduction in context footprint, faster agent decisions, better accuracy
Related MCP server: BuildAutomata Memory MCP Server
Automatic token limiting - Never exceed LLM context windows
Intelligent pruning - Keep important and recent memories
Memory decay - Old memories naturally fade over time
Importance scoring - Automatically rank memory significance
Vector embeddings - BAAI BGE models (384, 768, 1024 dimensions)
Semantic search - Find by meaning, not just keywords
Cross-session memory - Remember across conversations
Auto-embedding - No manual embedding required
ZeroLocal - localhost:8000 (fast, free, private)
ZeroDB Cloud - api.ainative.studio (scalable, managed)
Auto-detection - Automatically finds available endpoint
# Clone repository
git clone https://github.com/ainative/zerodb-memory-mcp.git
cd zerodb-memory-mcp
# Install dependencies
npm install
# Configure environment
cp .env.example .env
# Edit .env with your credentials
# Test locally
npm start# Recommended: API key auth (no login needed)
ZERODB_API_KEY=sk_xxx
ZERODB_API_URL=https://api.ainative.studio
ZERODB_PROJECT_ID=your-project-id
# OR username/password auth:
ZERODB_USERNAME=your@email.com
ZERODB_PASSWORD=your-password
ZERODB_API_URL=https://api.ainative.studio
ZERODB_PROJECT_ID=your-project-idTip: API key authentication (
ZERODB_API_KEY) is preferred over username/password. It avoids token expiry issues and is not affected by shell environment variable conflicts.
export ZERODB_API_URL="http://localhost:8000" # or cloud URL
export ZERODB_API_KEY="sk_your-api-key" # recommended
export ZERODB_PROJECT_ID="your-project-id"{
"mcpServers": {
"zerodb-memory": {
"command": "node",
"args": ["/path/to/zerodb-memory-mcp/index.js"],
"env": {
"ZERODB_API_URL": "http://localhost:8000",
"ZERODB_USERNAME": "your-username",
"ZERODB_PASSWORD": "your-password",
"ZERODB_PROJECT_ID": "your-project-id"
}
}
}
}{
"mcpServers": {
"zerodb-local": {
"command": "node",
"args": ["/path/to/zerodb-memory-mcp/index.js"],
"env": {
"ZERODB_API_URL": "http://localhost:8000",
"ZERODB_USERNAME": "your-local-username",
"ZERODB_PASSWORD": "your-local-password",
"ZERODB_PROJECT_ID": "your-local-project-id"
}
},
"zerodb-cloud": {
"command": "node",
"args": ["/path/to/zerodb-memory-mcp/index.js"],
"env": {
"ZERODB_API_URL": "https://api.ainative.studio",
"ZERODB_USERNAME": "your-cloud-username",
"ZERODB_PASSWORD": "your-cloud-password",
"ZERODB_PROJECT_ID": "your-cloud-project-id"
}
}
}
}zerodb_store_memoryStore conversation context with automatic importance scoring and embedding.
Input:
{
"content": "User prefers technical explanations over simplified ones",
"role": "system",
"session_id": "chat-123",
"tags": ["preference", "important"],
"user_id": "user-456"
}Output:
{
"success": true,
"memory_id": "mem_abc123",
"importance": 0.85,
"message": "Memory stored successfully"
}Features:
Auto-calculates importance (0.0 to 1.0)
Generates embeddings automatically
Supports tags for categorization
Links to user for cross-session memory
zerodb_search_memorySearch memory semantically using natural language.
Input:
{
"query": "What are the user's dietary restrictions?",
"limit": 10,
"session_id": "chat-123",
"scope": "agent",
"min_importance": 0.5
}Output:
{
"results": [
{
"content": "User is allergic to peanuts",
"role": "user",
"importance": 0.95,
"timestamp": "2026-02-28T10:30:00Z",
"tags": ["health", "critical"],
"similarity": 0.89,
"session_id": "chat-123"
}
],
"count": 1,
"scope": "agent"
}Features:
Semantic search (meaning, not keywords)
Cross-session search with scope: "agent"
Filter by importance, tags, user
Returns similarity scores
zerodb_get_contextGet full conversation context with smart pruning.
Input:
{
"session_id": "chat-123",
"max_tokens": 8192,
"include_stats": true
}Output:
{
"memories": [
{
"content": "Hello, how can I help?",
"role": "assistant",
"importance": 0.6,
"timestamp": "2026-02-28T10:00:00Z",
"tags": []
}
],
"total_tokens": 2048,
"stats": {
"pruned": true,
"original_count": 50,
"returned_count": 25,
"token_limit": 8192
}
}Features:
Auto-prunes to fit token limit
Keeps important and recent memories
Applies memory decay if enabled
Returns pruning statistics
zerodb_embed_textGenerate vector embeddings for text.
Input:
{
"text": "The quick brown fox jumps over the lazy dog",
"model": "BAAI/bge-small-en-v1.5",
"normalize": true
}Output:
{
"embedding": [0.123, -0.456, 0.789, ...],
"model": "BAAI/bge-small-en-v1.5",
"dimensions": 384,
"normalized": true
}Features:
Three model sizes (384d, 768d, 1024d)
Normalized vectors
Fast local embedding (if using ZeroLocal)
zerodb_semantic_searchSearch by semantic similarity without text query.
Input:
{
"text": "food preferences",
"limit": 10,
"session_id": "chat-123",
"min_similarity": 0.7
}Output:
{
"results": [
{
"content": "User prefers vegetarian meals",
"similarity": 0.85,
"metadata": {
"role": "user",
"tags": ["preference"]
}
}
],
"count": 1,
"search_vector_dims": 384
}Features:
Direct vector similarity search
Can provide text or pre-computed vector
Filter by similarity threshold
Session-scoped or global search
zerodb_clear_sessionClear all memories for a session.
Input:
{
"session_id": "chat-123",
"keep_important": true,
"confirm": true
}Output:
{
"success": true,
"deleted_count": 45,
"kept_count": 5,
"message": "Session cleared, important memories preserved"
}Features:
Requires confirmation
Optional preservation of important memories
Returns deletion statistics
zerodb_synthesize_contextRetrieve and LLM-synthesize relevant memories into a coherent context string. Wraps POST /memory/v2/context. (Issue #2631)
Input:
{
"query": "What did we decide about the pricing model?",
"agent_id": "user-456",
"synthesis_style": "narrative",
"max_tokens": 1000,
"top_k": 10
}Output:
{
"context": "In previous discussions, the team decided to use a usage-based pricing model...",
"synthesis_style": "narrative",
"sources_count": 5,
"confidence": 0.87,
"token_count": 312,
"agent_id": "user-456"
}Features:
Three synthesis styles: narrative, bullet, structured
Powered by Claude Haiku for fast, coherent summaries
Graceful fallback if synthesis fails (concatenates top snippets)
Scoped by agent_id for per-user memory isolation
zerodb_configure_auto_contextEnable auto-context middleware so that relevant memories are automatically prepended to every tool response for a given agent. (Issue #2678)
Input:
{
"agent_id": "user-456",
"enabled": true,
"max_results": 10,
"synthesis_style": "bullet",
"auto_trace": false
}Output:
{
"success": true,
"agent_id": "user-456",
"config": {
"enabled": true,
"max_results": 10,
"synthesis_style": "bullet",
"auto_trace": false
},
"message": "Auto-context enabled for agent user-456"
}Features:
Once enabled, every subsequent tool call for the agent_id automatically prepends _auto_context to the response
auto_trace: true stores each tool response as a new episodic memory for future recall
Config persisted via /remember — survives MCP server restarts
Skip list: config tools themselves are never auto-contexted
zerodb_get_auto_context_configRetrieve the current auto-context configuration for an agent.
Input:
{
"agent_id": "user-456"
}Output:
{
"agent_id": "user-456",
"config": {
"enabled": true,
"max_results": 10,
"synthesis_style": "bullet",
"auto_trace": false
}
}Five tools that write back to external services using OAuth tokens stored in ZeroDB sync connections. Connect accounts at /api/v1/public/memory/v2/connections.
Agent workflow:
zerodb_recall→zerodb_synthesize_context→ take action (send Slack, reply email, create event, etc.)
zerodb_slack_sendSend a Slack message using the user's stored OAuth token. (Issue #2645)
Input:
{
"agent_id": "user-456",
"channel": "C012AB3CD",
"message": "Sprint planning scheduled for Monday 10am",
"thread_ts": "1609459200.000100"
}Output:
{
"ts": "1609459201.000200",
"channel": "C012AB3CD",
"message": "Message sent successfully"
}Notes: thread_ts is optional — omit to post a new message, include to reply in a thread.
zerodb_gmail_replyReply to a Gmail thread using the user's stored Google OAuth token. (Issue #2646)
Input:
{
"agent_id": "user-456",
"thread_id": "17abc123def456",
"body": "Thanks for the update. I'll review the PR by EOD.",
"cc": ["manager@example.com"]
}Output:
{
"id": "17abc123def999",
"thread_id": "17abc123def456",
"message": "Reply sent successfully"
}zerodb_calendar_createCreate a Google Calendar event using the user's stored Google OAuth token. (Issue #2647)
Input:
{
"agent_id": "user-456",
"title": "Sprint Planning",
"start": "2026-05-10T10:00:00Z",
"end": "2026-05-10T11:00:00Z",
"description": "Q2 sprint kickoff",
"attendees": ["alice@example.com", "bob@example.com"],
"calendar_id": "primary"
}Output:
{
"id": "evt_abc123",
"html_link": "https://calendar.google.com/event?eid=abc123",
"title": "Sprint Planning",
"message": "Event created successfully"
}Notes: Uses the same Google OAuth token as Gmail. calendar_id defaults to "primary".
zerodb_github_create_issueCreate a GitHub issue using the user's stored GitHub OAuth token. (Issue #2648)
Input:
{
"agent_id": "user-456",
"repo": "acme/widget",
"title": "Fix null pointer in payment flow",
"body": "Steps to reproduce:\n1. Add item to cart\n2. Proceed to checkout\n3. Observe crash",
"labels": ["bug", "priority:high"]
}Output:
{
"number": 142,
"html_url": "https://github.com/acme/widget/issues/142",
"title": "Fix null pointer in payment flow",
"message": "Issue created successfully"
}zerodb_notion_create_pageCreate a Notion page using the user's stored Notion OAuth token. (Issue #2649)
Input:
{
"agent_id": "user-456",
"parent_id": "parent-page-uuid",
"title": "Meeting Notes — May 10",
"content": "Attendees: Alice, Bob\n\nDecisions:\n- Ship v2 on Friday\n- Rollback plan: revert to v1.9"
}Output:
{
"id": "page-uuid-xyz",
"url": "https://notion.so/page-uuid-xyz",
"title": "Meeting Notes — May 10",
"message": "Page created successfully"
}Notes: Content is converted to Notion paragraph blocks (one per non-empty line). Lines longer than 2000 characters are truncated.
# Set maximum tokens (default: 8192)
CONTEXT_WINDOW=16384
# Choose pruning strategy (default: hybrid)
# - relevance: Keep highest-scored memories
# - recency: Keep most recent memories
# - hybrid: Combine both (70% relevance, 30% recency)
PRUNE_STRATEGY=hybrid
# Always keep N recent messages (default: 5)
KEEP_RECENT=5
# Keep memories tagged as important (default: true)
KEEP_IMPORTANT=trueEnable natural memory decay over time:
# Enable decay (default: false)
DECAY_ENABLED=true
# Half-life in days (default: 30)
# After 30 days, importance score is halved
DECAY_HALFLIFE=30
# Protect tags from decay
PRESERVE_TAGS=important,permanent,criticalExample:
Day 0: importance = 0.8
Day 30: importance = 0.4
Day 60: importance = 0.2
Memories with important tag: never decay
Compress old conversations automatically:
# Enable summarization (default: true)
SUMMARIZE_ENABLED=true
# Summarize after N messages (default: 20)
SUMMARIZE_AFTER=20
# Model for summarization
SUMMARY_MODEL=claude-3-haiku-20240307
# Keep original messages (default: false)
KEEP_ORIGINALS=falseBehavior:
After 20 messages, oldest 15 are summarized
Summary stored as new memory with summary tag
Original messages deleted (unless KEEP_ORIGINALS=true)
Recent 5 messages always kept
Choose embedding model based on needs:
# Small (384 dimensions) - Fast, efficient
EMBEDDING_MODEL=BAAI/bge-small-en-v1.5
# Base (768 dimensions) - Balanced
EMBEDDING_MODEL=BAAI/bge-base-en-v1.5
# Large (1024 dimensions) - Most accurate
EMBEDDING_MODEL=BAAI/bge-large-en-v1.5Trade-offs:
Small: 3x faster, 70% accuracy
Base: 2x faster, 85% accuracy
Large: 1x baseline, 95% accuracy
// Store user preferences
await zerodb_store_memory({
content: "User prefers email support over phone",
role: "user",
session_id: "support-session-123",
tags: ["preference", "communication"],
user_id: "customer-456"
});
// Later, search across all sessions for this user
const prefs = await zerodb_search_memory({
query: "communication preferences",
scope: "agent",
user_id: "customer-456"
});// Store important facts
await zerodb_store_memory({
content: "User's birthday is March 15th",
role: "system",
session_id: "assistant-123",
tags: ["important", "permanent", "personal"],
metadata: { category: "birthday" }
});
// Retrieve context before responding
const context = await zerodb_get_context({
session_id: "assistant-123",
max_tokens: 4096
});// Store findings
await zerodb_store_memory({
content: "Study shows 85% efficacy in clinical trials",
role: "assistant",
session_id: "research-789",
tags: ["research", "statistics"],
metadata: { source: "Nature 2026", confidence: 0.9 }
});
// Search semantically
const related = await zerodb_semantic_search({
text: "clinical trial results",
limit: 5,
min_similarity: 0.7
});// 1. Recall relevant memories
const memories = await zerodb_recall({
query: "pending items from last standup",
agent_id: "agent-456",
top_k: 10,
rerank: true
});
// 2. Synthesize into a coherent summary
const context = await zerodb_synthesize_context({
query: "pending items from last standup",
agent_id: "agent-456",
synthesis_style: "bullet",
top_k: 5
});
// context.context = "- PR #42 needs review\n- Deploy blocked on staging tests\n- Alice OOO Monday"
// 3. Take action — send Slack update
await zerodb_slack_send({
agent_id: "agent-456",
channel: "C012AB3CD",
message: `Standup summary:\n${context.context}`
});
// 4. Log the action as a memory for future recall
await zerodb_store_memory({
content: `Sent standup summary to #engineering: ${context.context}`,
role: "assistant",
session_id: "agent-456",
tags: ["action", "slack", "standup"]
});Enable auto-context so every tool call gets relevant memories prepended automatically:
// Enable once per agent
await zerodb_configure_auto_context({
agent_id: "agent-456",
enabled: true,
max_results: 10,
synthesis_style: "bullet",
auto_trace: true // also store tool responses as memories
});
// Now every subsequent tool call automatically includes _auto_context
const result = await zerodb_slack_send({
agent_id: "agent-456",
channel: "C123",
message: "Update sent"
});
// result._auto_context = "• User prefers concise updates\n• Last message sent 2h ago"
// result.ts = "..."Metric | Monolithic Server | Agent Memory MCP | Improvement |
Tools | 77 | 6 | 92% reduction |
Token cost | ~10,400 | ~800 | 92% reduction |
Load time | 2.5s | 0.3s | 8x faster |
Memory usage | 150MB | 20MB | 87% less |
Agent accuracy | 60% | 95% | 58% better |
ZeroLocal (localhost:8000):
Store memory: ~5ms
Search memory: ~15ms
Get context: ~20ms
Embed text: ~10ms
ZeroDB Cloud (api.ainative.studio):
Store memory: ~50ms
Search memory: ~75ms
Get context: ~100ms
Embed text: ~60ms
npm testDEBUG=* npm startnpm run devCommon cause: Shell environment variables (~/.zshrc, ~/.bashrc) override the credentials set in your MCP config (e.g., .claude.json or Claude Desktop config). The MCP server inherits all shell env vars, and stale ZERODB_USERNAME/ZERODB_PASSWORD values in your shell profile will take precedence.
Fix:
Remove or update stale ZERODB_USERNAME/ZERODB_PASSWORD exports from ~/.zshrc or ~/.bashrc
Or switch to API key auth (ZERODB_API_KEY) which is not typically set in shell profiles
Or set credentials explicitly in your MCP server config env block to override shell vars
Also check:
ZERODB_USERNAME and ZERODB_PASSWORD are correct
Account exists in ZeroDB
Password hasn't changed
Check:
ZERODB_PROJECT_ID is correct
Project exists in your account
You have access permissions
If using ZeroLocal:
# Check if ZeroLocal is running
curl http://localhost:8000/health
# Start ZeroLocal
cd /path/to/zerodb-local
zerodb local upIf using Cloud:
# Check internet connection
ping api.ainative.studio
# Verify API is online
curl https://api.ainative.studio/healthCheck configuration:
# Ensure context window is set
echo $CONTEXT_WINDOW
# Verify prune strategy
echo $PRUNE_STRATEGY
# Check if keep_recent is too high
echo $KEEP_RECENT┌─────────────────────────────────────────────┐
│ Agent Memory MCP Server │
├─────────────────────────────────────────────┤
│ │
│ Main (index.js) │
│ └── MCP Server initialization │
│ │
│ Client (zerodb-client.js) │
│ ├── Auto-detection (local vs cloud) │
│ ├── Authentication & token refresh │
│ └── API request handling │
│ │
│ Memory Manager (memory-manager.js) │
│ ├── Context window management │
│ ├── Memory pruning (relevance/recency) │
│ ├── Importance scoring │
│ ├── Memory decay │
│ └── Automatic summarization │
│ │
│ Tools (memory-tools.js) │
│ ├── zerodb_store_memory │
│ ├── zerodb_search_memory │
│ ├── zerodb_get_context │
│ ├── zerodb_embed_text │
│ ├── zerodb_semantic_search │
│ ├── zerodb_clear_session │
│ └── zerodb_synthesize_context │
│ │
└─────────────────────────────────────────────┘LLM-based automatic summarization
Memory clustering and organization
Export/import memory archives
Memory analytics dashboard
Multi-agent memory sharing
Memory permissions and access control
Federated memory across instances
Memory replication and backup
Graph-based memory relationships
Temporal memory queries
Memory compression algorithms
Real-time memory streaming
Contributions welcome! Please read our contributing guidelines first.
MIT License - see LICENSE file for details
Documentation: https://www.ainative.studio/docs
Issues: https://github.com/ainative/zerodb-memory-mcp/issues
Discord: https://discord.gg/ainative
Built with by AINative Studio
Making AI agents smarter, one memory at a time.
Create a Google Calendar event using your stored Google OAuth connection.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End datetime in ISO 8601 format | |
| start | Yes | Start datetime in ISO 8601 format (e.g. "2026-05-10T14:00:00-07:00") | |
| title | Yes | Event title / summary | |
| attendees | No | Optional list of attendee email addresses | |
| calendar_id | No | Calendar ID (default: "primary") | primary |
| description | No | Optional event description |
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.
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.
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.
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.
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.
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.
Clear all memories for a session. Use with caution - this permanently deletes conversation history.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Confirmation flag - must be true to execute | |
| session_id | Yes | Session identifier to clear memories for | |
| keep_important | No | Keep memories tagged as "important" or "permanent" |
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.
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.
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.
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.
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.
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.
Configure ambient memory injection. When enabled, ZeroDB automatically retrieves relevant memories before each tool call and prepends them as context — agents get memory without calling recall() explicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | Enable or disable auto-context injection (default: false) | |
| agent_id | Yes | Agent identifier to configure (scopes config to this agent) | |
| auto_trace | No | Automatically store tool responses as memories for future recall (default: false) | |
| max_results | No | Number of memories to inject per tool call (1-20, default: 10) | |
| synthesis_style | No | Format of injected context: narrative prose, bullet points, or structured summary | bullet |
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.
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.
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.
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.
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.
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.
Generate vector embeddings for text using BAAI BGE models. Useful for manual vector operations or custom similarity calculations.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to generate embeddings for | |
| model | No | Embedding model to use (small=384d, base=768d, large=1024d) | BAAI/bge-small-en-v1.5 |
| normalize | No | Normalize vector to unit length |
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.
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.
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.
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.
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.
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.
Get the current auto-context configuration for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier to retrieve configuration for |
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.
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.
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.
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.
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.
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.
Get full conversation context window for a session with smart pruning. Automatically manages token limits, applies memory decay, and prioritizes important/recent memories.
| Name | Required | Description | Default |
|---|---|---|---|
| max_tokens | No | Maximum tokens to include in context window (default: 8192) | |
| session_id | Yes | Session identifier to retrieve context for | |
| include_stats | No | Include statistics about memory usage and pruning |
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.
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.
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.
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.
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.
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.
Create a GitHub issue using your stored GitHub OAuth connection.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Issue body / description (markdown supported) | |
| repo | Yes | Repository in "owner/repo" format (e.g. "acme/backend") | |
| title | Yes | Issue title | |
| labels | No | Optional list of label names |
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.
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.
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.
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.
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.
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.
Reply to a Gmail thread using your stored Google OAuth connection. Sends from your connected Gmail account.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | Optional list of CC email addresses | |
| body | Yes | Reply body (plain text or HTML) | |
| thread_id | Yes | Gmail thread ID to reply to |
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.
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.
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.
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.
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.
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.
Create a Notion page using your stored Notion OAuth connection.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Page title | |
| content | No | Page content as plain text or markdown. Converted to Notion blocks automatically. | |
| parent_id | Yes | Parent page or database ID to create the page under |
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.
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.
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.
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.
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.
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.
Create a persistent plan, PRD, or task artifact in ZeroDB. Returns an artifact ID you can pass to zerodb_plan_get/update/history in future sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Artifact type | plan |
| title | Yes | Artifact title (max 200 chars) | |
| content | Yes | Markdown content | |
| session_id | No | Optional session ID to associate with |
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.
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.
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.
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.
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.
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.
Retrieve a plan artifact by ID. Use this at session start to restore a plan from a previous session.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Artifact ID returned by zerodb_plan_create |
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.
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.
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.
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.
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.
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.
Get version history for a plan artifact. Returns list of diffs showing how the plan evolved.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Artifact ID |
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.
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.
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.
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.
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.
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.
Update a plan artifact. Content changes are diffed and stored in version history automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Artifact ID | |
| title | No | New title (optional) | |
| status | No | New status (optional) | |
| content | No | New content (optional) |
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.
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.
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.
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.
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.
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.
Search agent memory semantically using natural language queries. Supports cross-session search and filtering by tags, user, or time range.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional tags to filter results | |
| limit | No | Maximum number of results to return | |
| query | Yes | Natural language query to search for in memory (e.g., "user preferences about food") | |
| scope | No | Search scope: session (current conversation), agent (all sessions for this agent), or global | session |
| user_id | No | Optional user ID to search across all sessions for this user | |
| session_id | No | Optional session ID to limit search to specific conversation | |
| min_importance | No | Minimum importance score (0.0 to 1.0) to filter results |
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.
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.
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.
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.
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.
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.
Search memory by semantic similarity without needing a text query. Directly search using vector embeddings or similar memories.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Text to find semantically similar memories for (will be embedded automatically) | |
| limit | No | Maximum number of similar memories to return | |
| vector | No | Pre-computed embedding vector to search with (alternative to text) | |
| session_id | No | Optional session ID to limit search scope | |
| min_similarity | No | Minimum cosine similarity score (0.0 to 1.0) |
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.
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.
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.
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.
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.
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.
Send a Slack message using your stored Slack OAuth connection. No API key required — uses the token from your connected Slack account in ZeroDB.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Slack channel name (e.g. "#general") or channel ID | |
| message | Yes | Message text. Supports Slack mrkdwn formatting. | |
| thread_ts | No | Optional. Thread timestamp to reply in an existing thread. |
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.
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.
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.
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.
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.
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.
Store conversation context in agent memory with automatic importance scoring and embedding. Supports multi-session tracking and memory decay.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Role of the speaker (affects importance scoring) | user |
| tags | No | Optional tags for categorization (e.g., ["important", "preference", "health"]) | |
| content | Yes | The content to store in memory (conversation text, facts, preferences, etc.) | |
| user_id | No | Optional user identifier for cross-session memory | |
| metadata | No | Additional metadata to store with the memory | |
| session_id | Yes | Session identifier to organize memories by conversation |
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.
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.
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.
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.
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.
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.
Retrieve and LLM-synthesize relevant memories into a coherent context string. Searches memory for the query, retrieves top results, then uses Claude Haiku to synthesize a narrative, bullet list, or structured summary. Returns a ready-to-use context string for grounding AI responses.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The question or topic to retrieve context for | |
| top_k | No | Number of memory results to retrieve before synthesis (default: 10) | |
| agent_id | Yes | Agent or user identifier (used to scope memory retrieval) | |
| max_tokens | No | Maximum tokens in the synthesized context (default: 1000) | |
| synthesis_style | No | Output format: narrative prose, bullet points, or structured JSON-like summary | narrative |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.7zerodb_calendar_createzerodb_clear_sessionzerodb_configure_auto_contextzerodb_embed_textzerodb_get_auto_context_configzerodb_get_contextzerodb_github_create_issuezerodb_gmail_replyzerodb_notion_create_pagezerodb_plan_createzerodb_plan_getzerodb_plan_historyzerodb_plan_updatezerodb_search_memoryzerodb_semantic_searchzerodb_slack_sendzerodb_store_memoryzerodb_synthesize_contextSeveral 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
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
