remember

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

With no annotations at all, the description carries the burden of behavioral disclosure. It clearly states the tool is a write operation that modifies memory, and it explains the side effects: unsaved durable facts are bugs, keys become hubs, and hints may return near-duplicate keys. It also documents decay_profile semantics and source auto-stamping. However, it does not explain what the response contains beyond hints, whether the call is idempotent, or whether there are any rate limits or confirmation behaviors (e.g., confirm_memory). A 3 is fair — it covers the core mutation behavior but not all consequences.

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 dense and front-loaded with the mandatory gate, but it is quite long — roughly 170 words — and mixes policy (what to save), style guidance (key naming rules), parameter semantics, and hint-handling instructions in one block. Every sentence adds information, but the structure is a single wall of text with no paragraph breaks, which makes it harder to scan. The urgency tone ('MANDATORY', 'bug') is justified but adds noise.

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 complex, high-stakes memory-write tool with 8 parameters, no annotations, and no output schema, the description covers the essential behavioral contract: when to call, what to save, how to structure keys, how to handle cross-lingual facts, and what hints may come back. It is somewhat incomplete in that it does not explain key_types at all, does not describe the success/failure response body, and assumes the agent knows what 'canonical concepts' means from recall's description. Still, it provides far more operational context than most tool definitions.

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 description coverage is 0%, so the description must compensate for all 8 parameters. It explains keys (atomic, 1-2 words, diverse), content (durable facts), namespace (groups memories by project/context), ttl_seconds (sets expiry), decay_profile (transient/standard/stable/permanent), related_to (explicit memory links), and source (provenance, auto-stamped). Only key_types is not explicitly explained, and it is an optional advanced field. This is strong compensation despite one gap.

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 clearly identifies the tool as a memory-save operation with a mandatory end-of-turn gate, specifying that durable facts must be saved silently before replying. It distinguishes itself from recall/read_memory/browse_keys by focusing on writing new facts, and from remember_batch by describing single-turn single-item saving. However, it never explicitly says 'saves facts to memory' in a simple verb+resource form — the purpose is conveyed through instructions rather than a direct statement.

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: before every reply, save every durable fact newly revealed, and save nothing only after consciously confirming nothing durable appeared. It differentiates from remember_batch by framing this as the per-turn single-item save path, and it tells the agent to recall() the same namespace and reuse canonical concepts — an explicit integration with sibling tools. This is strong operational guidance.

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