Skip to main content
Glama

Synap Memory

by ai.maximem

recall_context

Before replying, call this to recall anything already known about this user from past conversations. Use the user's latest message as the query. If you serve multiple end-users, pass the same user_id you log with so you recall the right person's memory. 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
queryYes
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.1/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does meaningful work: it explains that customer_id is B2B-only, that a B2C instance rejects it with HTTP 400, and that GET /api/v1/auth/whoami reports the mode. This goes well beyond a generic recall description. It stops short of stating read-only/no-side-effects explicitly, but the usage context makes that reasonably safe to infer.

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 content is dense and every sentence serves a purpose. The earlier paragraphs carry the core usage, and the scoping details appear later. It is a single long paragraph and could benefit from bullets for the B2B/B2C modes, but it is still appropriately sized for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a recall tool with mode-dependent scoping, the description covers the when, the query, the identity, the failure modes, and how to disambiguate the instance mode. An output schema exists so return shape is covered. The only notable gap is max_results semantics, but it is optional and its title is reasonably self-explanatory.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial semantics for query, user_id, and customer_id, especially the B2B/B2C distinction and which identifier to send. However, max_results is not mentioned anywhere, and the schema only gives it a type and default, leaving its effect unexplained. With schema description coverage at 50%, the description compensates for most but not all parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'call this to recall anything already known about this user from past conversations'. This is specific and naturally distinguishes recall from the sibling tools (status check, listing, logging). It also adds the timely behavior 'before replying', which sharpens the purpose.

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

Usage Guidelines4/5

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

It gives explicit usage direction: call before replying, use the latest message as the query, pass the same user_id you log with, and fall back to user_id-only when the instance mode is unknown. It does not explicitly name alternatives such as list_recent_memories or check_memory_status, so the when-not-to-use guidance is limited.

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