UltraMemory

Official

by LogicLabsAI

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.9.13
Disambiguation3/5
Multiple recall tools (memory_recall, recall_gated, recall_verified, search) overlap in retrieving information, though descriptions attempt to differentiate them by use case (e.g., policy, precision). This creates potential confusion for an agent selecting the right tool.
Naming Consistency4/5
Most tools follow a verb_noun pattern with underscores (e.g., playbook_recall, memory_write), but 'search' and 'fetch' are single verbs without a noun, creating a minor inconsistency.
Tool Count5/5
With 9 tools covering memory storage, retrieval, and feedback, the count is well-scoped for a memory management server. Each tool serves a distinct role without feeling excessive.
Completeness3/5
The server lacks update and delete operations for memories, and there is no list-all tool. While core write/recall is covered, these gaps hinder full lifecycle management.
Average 4.5/5 across 9 of 9 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 54 commits in the last 12 weeks
- Last stable release on July 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds 'learned, credit-scored' and 'worked before,' reinforcing read-only nature and scoring behavior without contradiction.
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?
Single sentence, front-loaded verb and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and tool is simple, description covers core purpose but lacks usage guidance to differentiate from siblings, leaving gaps in contextual completeness.
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% and parameter descriptions are clear; description does not add meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'retrieve' and resource 'strategies' (playbook), adds context 'learned, credit-scored' to differentiate from generic memory tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like memory_recall, search, or fetch. With 8 sibling tools, explicit context is 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?
Annotations already provide readOnlyHint and idempotentHint, confirming safe read-only behavior. The description adds value by detailing the conditional inclusion of provenance fields and the explicit not-found response shape, which goes beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no extra words. It front-loads the core action ('Fetch one memory by id') and immediately explains the return structure, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's simplicity, the description is complete. It describes the input, conditional output fields, and error handling (not-found shape), leaving no ambiguity about what the tool returns or expects.
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 both parameters ('fact_id from search/recall results' for id, 'Project scope id (default 'default')' for scope). The tool description does not add new meaning 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 the tool fetches one memory by ID and details the return shape. It is specific ('Fetch one memory by id') and distinguishes itself by focusing on single-record retrieval with full content and provenance fields. No siblings exist, so differentiation is not an issue.
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 specifies the input (fact_id from search/recall results) and clarifies behavior for missing IDs (returns not-found shape). While there are no sibling tools, the description does not explicitly state when to use this tool vs alternatives (e.g., search or list tools), but the purpose is clear enough for an agent to infer usage.
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?
Beyond the annotations (idempotentHint=true), the description adds that entries are deduped and credit-scored nightly, explaining why the tool is idempotent and providing expected behavior. This adds useful context beyond the structured fields.
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 core action, and contains no filler. Every sentence provides essential 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?
Given the simplicity of the tool, an output schema, and annotations, the description adequately covers purpose, usage timing, and behavioral details (dedup, scoring). No gaps are apparent for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already provides clear descriptions for all parameters. The description adds a concrete example for 'trigger' but does not significantly extend meaning beyond the schema. 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 uses specific verbs ('Store') and clearly identifies the resource ('strategy'). It distinguishes from the sibling tool 'playbook_recall' by describing the write operation and the retrieval counterpart.
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 implies when to use the tool ('AFTER it proves out in practice') and contrasts with 'playbook_recall' for retrieval. However, it does not explicitly state when not to use it or provide alternative tools for different scenarios.
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?
Annotations already declare readOnlyHint and idempotentHint. Description adds return format ('full text inline plus citation url') and space routing behavior. Lacks details on pagination or error handling but sufficient given annotations.
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?
Front-loads purpose, then adds guidelines. All sentences are relevant but could be tightened (e.g., mixing retry logic with alternatives). Adequately structured.
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 4 parameters (1 required), output schema exists, and multiple siblings, description covers main usage, retry, and differentiation. No mention of error cases or auth, but output schema may cover return values.
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 baseline 3. Description reiterates space parameter exactly as schema; no additional semantic meaning for query, k, or scope beyond what schema provides.
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?
Explicitly states verb 'search', resource 'user's saved memory', and scope 'prefer over built-in/native memory'. Clearly distinguishes from siblings like recall_gated and memory_recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use ('Call this FIRST on every turn'), when not to (prefer recall_gated for governance, skip if memory_recall exists), and retry guidance with recall_verified.
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?
Annotations provide `destructiveHint: false` and `readOnlyHint: false`, but the description adds unique context: labeling is write-once (idempotent behavior), free (never billed), and unlocks per-tenant threshold personalization. No contradiction with annotations.
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 (four sentences) and front-loaded with the core purpose. Each sentence adds essential information: purpose, usage constraints, write-once policy, and benefits. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and an output schema, the description fully covers all critical aspects: when to call, not to self-grade, idempotency, cost, and personalization outcome. No gaps remain for an agent to misuse the 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 both parameters. The description reinforces the meaning: `event_id` must come from a recall call and `correct` is based on user feedback. It adds no new technical details beyond the schema, so baseline 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 tool's purpose: 'Label a gated/verified recall decision as right or wrong.' It specifies the verb 'label' and the resource 'recall decision', distinguishing it from sibling tools like 'recall_gated' and 'memory_recall' by focusing on the labeling action after user confirmation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions: 'Call this ONLY when the USER has explicitly confirmed or corrected a recalled answer... NEVER label from the model's own judgment... Labels are write-once: an already-labeled result means do not retry.' This clearly defines when to use and when not to, and includes forward-looking guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior beyond annotations, including returning answer/verify/abstain, a context_block with sectioned briefing, a policy_applied flag, and memory space routing. It also notes that it surfaces policy even when a bare query would abstain, all consistent with readOnlyHint.
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 front-loaded with critical guidance and is informative, but it is somewhat verbose with repetition (e.g., emphasizing policy multiple times). It earns its place but could be tightened without losing clarity.
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 output schema exists, the description covers return types (answer/verify/abstain, context_block with briefing) and explains the space parameter and fallback with recall_verified. It is fairly complete, though more explicit output format details could help, but output schema likely covers that.
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?
While schema coverage is 100% with parameter descriptions, the description adds context for the `space` parameter (routing) and implies usage of `k` and `as_of`. It provides useful behavioral context beyond the schema, slightly elevating it above baseline.
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: a gated recall that abstains when unsure, specifically for grounding answers and retrieving company policy. It distinguishes from siblings like memory_recall and search by emphasizing that only recall_gated returns policy with a sectioned briefing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Call this FIRST', 'ALWAYS prefer this tool for any governance, policy, compliance...', and the alternative recall_verified if the tool abstains. It clearly contrasts with siblings that do not carry the policy briefing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses reranking, gating, calibrated domain, latency (~600ms), and return shape beyond annotations' readOnlyHint, providing rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded core functionality and usage guidance, no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and existing output schema, description adequately covers use cases, trade-offs, and behavioral differences from siblings.
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 covers all parameters thoroughly (100% coverage); description does not add new parameter-level meaning beyond noting return shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's function: reranking with cross-encoder and gating for high precision, distinguishing it from sibling recall_gated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool for careful lookups where false negatives are costly, and directs to recall_gated for default fast path, with latency trade-off noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations (readOnlyHint, openWorldHint). It explains the retrieval mechanism (bitemporal, RRF-fused FTS + vector), the meaning of the score field, and that null score indicates policy co-retrieval. This enriches the agent's understanding of behavior.
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 dense and front-loaded with the most critical information. Every sentence adds value, though the single-paragraph structure could be improved with clearer separation of usage guidance, technical details, and sibling differentiation for faster scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (return values are not described but covered by schema), and the tool has moderate complexity, the description fully explains when to call, how it works, and how it fits with siblings. No critical gaps remain for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions in the schema). The description adds value by explaining the space parameter's options and default behavior, and clarifying scope as project scope. Since the schema already covers the basics, the description provides helpful but non-essential extra context.
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: 'Recall the user's saved facts to ground your answer' and specifies it is the default first call each turn. It also distinguishes this tool from siblings like search (duplicate), recall_gated (governance), and recall_verified (escalation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Call this FIRST on each turn', 'prefer it over built-in/native memory', and instructions for siblings (e.g., 'never call both' with search, and when to use recall_gated or recall_verified).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: 'shared writes are accepted ONLY for team owners/admins; a member writing shared gets a 403.' It also mentions deduped and bitemporal properties, which align with idempotentHint=true.
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 moderately long but well-structured, front-loading the purpose and then providing usage rules. Every sentence adds value, though it could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 100% schema coverage, full annotations, and the presence of an output schema (though not detailed), the description is complete. It covers behavioral quirks, parameter semantics, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant value for parameters, especially `value`: 'self-contained for a zero-context reader: named entities (no pronouns), absolute dates..., 15-100 words; never a bare true/false.' This enriches the schema's bare 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 specifies 'Store a durable fact' with clear verb and resource, and distinguishes from siblings like memory_recall and playbook_write. It explicitly says what the tool does and its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It directly states when to use: 'Call this whenever the user states a fact, preference, decision, or project detail about themselves, or asks you to remember something.' This provides clear guidance and implies alternatives.
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:

[![ultramemory-mcp MCP server](https://glama.ai/mcp/servers/LogicLabsAI/ultramemory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LogicLabsAI/ultramemory-mcp)

Score Badge

Copy to your README.md:

[![ultramemory-mcp MCP server](https://glama.ai/mcp/servers/LogicLabsAI/ultramemory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LogicLabsAI/ultramemory-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/LogicLabsAI/ultramemory-mcp'

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