Skip to main content
Glama

Synap Memory

by ai.maximem

log_exchange

After each user message, send the exchange here so it can be remembered. You do not need to decide what is important, just forward the user message (and your reply, if you have one) and Synap will keep what matters. If your app serves more than one end-user, pass that person's stable id as user_id so each person's memory stays separate; if every conversation is the same single user, omit it. 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. Logging is fire-and-forget by default; set wait_for_processing=true only when you need to confirm the memory finished extracting before continuing.

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.
user_messageYes
conversation_idNo
assistant_messageNo
wait_for_processingNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses fire-and-forget logging, the meaning of wait_for_processing, and concrete failure modes including HTTP 400 on B2C and the invalid user_id-only case on B2B.

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?

Although long, it is front-loaded with the core purpose and every subsequent sentence carries meaningful scoping or behavioral guidance. The SCOPING block is dense but necessary given the mode-dependent behavior, and there is no filler.

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 6-parameter tool with no annotations, this description covers the required call pattern, optional parameters, async behavior, error conditions, and mode detection. An output schema exists, so return-value explanation is not needed. The only meaningful gap is conversation_id, which is undocumented in both the schema and description.

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 only 33%, and the description compensates for most parameters: user_message and assistant_message contents, user_id omission rule, customer_id B2B-only behavior, and wait_for_processing semantics. However, conversation_id is never mentioned in the description or schema, leaving that parameter unexplained.

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 'send the exchange here so it can be remembered', clearly identifying this as the memory-write action. It distinguishes itself from sibling read-only tools like check_memory_status and recall_context by orienting the agent toward logging rather than retrieving.

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 explicitly says to use this after every user message and tells the agent not to judge importance. It gives precise when-to-use rules for user_id and customer_id based on instance mode, how to resolve ambiguity via GET /api/v1/auth/whoami, and when to set wait_for_processing.

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