sage_turn

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

With no annotations, the description carries the full burden and discharges most of it: atomic recall+store behavior, a payload-free message_inbox_unread flag/count, explicit non-claiming of payloads, federation-miss reporting on exact-domain recall, and domain-omission fallback semantics that are never silently remapped. It omits only edge behavior such as idempotency or what happens to a malformed/empty observation.

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?

Purpose is front-loaded in the first clause, and the dense content is warranted by a complex, unannotated tool. There is mild redundancy ('so you have context' / 'so future-you has context') and the inbox/claim paragraphs run long, but nothing is fully wasted.

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 write+recall tool with no annotations and no output schema, the description covers the operational lifecycle end-to-end: what it stores, what it returns, how the inbox flag routes to sage_inbox, how claiming is separated, and how domain resolution works. Adequate to call correctly; the only gap is failure/edge-case behavior.

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 100%, so the schema already documents topic, domain, and observation. The description's notes on domain (approved app-v23 home domain vs legacy general, never remapped) largely restate the schema's own description, adding only the minor guidance to pass domain 'only when you intentionally want that exact domain.' Baseline 3 is correct when the schema does the heavy lifting.

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 resource+scope ('Per-conversation-turn memory cycle') and enumerates exactly two atomic actions: recalling committed memories and storing a turn observation. It clearly separates itself from siblings like sage_recall, sage_remember, sage_inbox, and sage_message_claim by stating it 'never claims or embeds message payloads.' An agent can distinguish it without opening any schema.

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?

Explicit when-to-use ('Call this EVERY turn'), conditional routing ('call sage_inbox with a fresh poll when true'), and a clear when-NOT to use the claiming path ('use sage_message_claim only after accepting an authorized exact request'). Alternatives and the conditions selecting them are spelled out, not inferred.

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