Synap Memory

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

With no annotations, the description carries the behavioral burden and does it well: it reveals asynchronous extraction, the returned information (status and memory count), and the identifier contract exception. It stops short of stating read-only behavior or error semantics, but the core behavior is 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?

Four sentences, each earning its place: purpose, parameter source, return value, usage rationale, and identifier-contract exception. The most important information is front-loaded and there is no filler.

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 a single required parameter, an output schema that can carry return-value details, and sibling tools providing surrounding context, the description covers what an agent needs: what the tool does, when to use it, and how to obtain the parameter.

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 0%, so the description must compensate, and it fully does. It tells the agent exactly where to get ingestion_id ('returned by log_exchange') and explains why no user_id or customer_id is needed, adding meaning far beyond the bare string 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 opens with a specific verb and resource: 'Check whether a logged exchange has finished processing.' It clearly defines the tool's scope and differentiates it from siblings by clarifying that it takes no user_id or customer_id, since the ingestion_id already identifies the write.

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 explicit situational guidance: use it to confirm a save completed because extraction is asynchronous, and pass the ingestion_id from log_exchange. It does not enumerate when-not-to-use alternatives, but the intended workflow is clear.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.