Skip to main content
Glama

Synap Memory

by ai.maximem

list_recent_memories

List recent things remembered about this user. Useful for debugging or to confirm that memory is working. Pass user_id to scope to one person. SCOPING: customer_id is B2B ONLY. On a B2B instance (user_context_isolation=strict) it is REQUIRED and a user_id on its own is an error. On a B2C instance (user_context_isolation=equals_customer) it is NOT accepted: the API rejects it with HTTP 400, customer-scoped retrieval does not exist there, and user_id is the whole identity. If you do not know which mode this instance is in, send user_id only and no customer_id; GET /api/v1/auth/whoami reports the mode as user_context_isolation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_idNoStable id of the end-user this call belongs to. On a B2C instance this is the ONLY identifier you send and it is the whole identity. On a B2B instance send it together with customer_id. Omit both if every conversation is the same single user.
customer_idNoB2B ONLY. Required on a B2B instance (user_context_isolation=strict), where a user_id on its own is an error. NOT accepted on a B2C instance (user_context_isolation=equals_customer): the API rejects it with HTTP 400 and there is no customer scope to read from. When in doubt leave this out and send user_id alone. GET /api/v1/auth/whoami reports the mode.
max_resultsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations available, the description carries the full burden, and it does impressively: it discloses B2B/B2C mode-specific error behavior (HTTP 400, rejected customer_id), explains that customer-scoped retrieval does not exist on B2C, and points to the whoami endpoint for determining the intended mode. This goes well beyond the schema and gives an agent a realistic picture of API 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 longer than average but front-loads the core purpose and then organizes scoping rules in a clear 'SCOPING' block. There is some repetition of the B2B/B2C rules, and it could be tightened, but each section contributes necessary operational detail.

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 complex authentication/scoping model, the description is quite complete: it explains when each parameter is valid, what errors occur, and how to resolve mode uncertainty. Since an output schema exists, return values do not need to be spelled out. It does not mention auth beyond instance mode, but the provided guidance is sufficient for selecting and invoking this tool 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 67% and the description substantially enriches user_id and customer_id semantics by explaining mode-dependent rules, required combinations, and error cases. It does not add any meaning to max_results beyond the schema's default, which keeps this at a 4 rather than a 5.

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 opens with a specific verb and resource: 'List recent things remembered about this user.' It also adds the intended use case ('debugging or to confirm that memory is working'), which distinguishes it from the sibling tools like log_exchange and recall_context by focusing on inspecting what was already stored.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance ('useful for debugging or to confirm that memory is working') and provides extensive conditional rules about when to include or omit customer_id based on instance mode. It does not explicitly compare against sibling alternatives, so it misses the full 'alternatives' aspect for a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Synap Memory toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a clearly distinct operation: logging an exchange, recalling relevant context, listing recent memories, and checking async processing status. recall_context and list_recent_memories both read memory but are separated by semantic relevance versus recency/debugging, so there is no real ambiguity.

Naming Consistency5/5

All four names follow the same lowercase snake_case verb_noun pattern: check_, list_, log_, recall_. The action is predictable from the verb and the resource from the noun, making the set easy to navigate.

Tool Count5/5

Four tools is well-scoped for a memory server: write, recall, list, and status check. Each tool earns its place and there is no redundancy or bloat.

Completeness4/5

The core conversational memory workflow is covered end-to-end: log, recall, list, and confirm processing. The only notable gap is the lack of a delete/forget operation for memory management, but that does not break the primary use case.

Resources