slowave_remember

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals non-obvious semantics: Slowave always sets internal ts to the write time, occurred_at never changes event order, scalar claims can be created or matched, and batch results are independent item envelopes with ok/data or ok/error. This is far richer than a simple 'store memory' statement, though it does not fully clarify what happens on 'matched' beyond the disposition field.

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 well-organized with an opening purpose, Args list, IMPORTANT guidance, and Returns section. However, phrases like 'only verified commit procedures are execution-backed procedures' are cryptic and do not earn their place, and the overall length is high relative to the amount of new information. The structure is above average, but the verbiage makes it a mid-range score.

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 zero annotation coverage, this description covers nearly everything needed to call it correctly: parameter meanings, usage constraints, return fields, and batch behavior. The schema-optionality mismatch around type and the lack of a concrete invocation example leave small gaps, but the definition is largely self-sufficient.

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%, and the description compensates thoroughly: it documents scope/session provenance, content/memories mutual exclusivity, RFC 3339 occurred_at semantics, and batch inheritance of outer scope/session. The only blemish is 'type: required scalar type,' which conflicts with the schema's optional type field and is ambiguous when using the memories batch form.

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-resource pair: 'Explicitly encode a durable typed claim into long-term memory.' The IMPORTANT section then narrows the purpose to durable knowledge that persists across sessions, explicitly excluding ephemeral task state. This distinguishes the tool from siblings like slowave_recall and slowave_feedback without needing to open their schemas.

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 a clear when-to-use directive ('Use ONLY for durable knowledge that should persist across sessions') and a when-not-to-use rule ('Do NOT store ephemeral task state — that belongs in session events'). It also ties the tool to the active session from slowave_activate, establishing a prerequisite. However, it does not explicitly compare against sibling tools slowave_commit or slowave_feedback, leaving some routing to inference.

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