remember

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

With no annotations provided, the description carries the full behavioral burden, and it delivers: it discloses that admission is conditional on evidence, that refusals are typed and actionable, and that the tool is a write operation ('commit'). The schema adds the byte-range binding and receipt behavior. Gaps: it does not describe what a successful call returns (the receipt format) or explicitly state the response envelope beyond typed refusals.

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?

Three dense sentences, zero wasted words. The primary verb is front-loaded, the gating mechanic follows immediately, and the verbatim constraint closes it out. Every clause earns its place and no structured-field content is redundantly repeated.

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 tool of moderate complexity — a gated mutation with typed refusals and byte-range receipt binding — the description plus schema covers the essentials: purpose, evidence requirement, failure mode, and the optional source_text binding. The main omission is the success response shape (what the receipt actually is on the happy path), which is hinted at in the schema but never fully described.

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 100%, so the baseline is 3. The description adds real interpretive value beyond the schema: framing the caller as 'proposer' subject to a 'deterministic gate' explains WHY claim and evidence matter and how they interact, and the verbatim emphasis reinforces the constraint on the evidence parameter. This contextual rationale is more than the schema's terse field descriptions provide.

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?

Opens with a specific verb+resource construction — 'Commit a fact to memory' — and immediately distinguishes itself from the sibling set: it is not recall (reading), not forget (deleting), not verify_receipts (checking), and not add_source (storing a source document). The added detail about the deterministic gate and verbatim evidence requirement makes the tool's identity unambiguous.

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 implies when to use the tool — when an agent holds a fact supported by verbatim quoted evidence — and the gate/verbatim constraints effectively rule out using it for paraphrased claims. However, it never explicitly names alternatives or states when-not-to-use, leaning entirely on implicit context. No exclusion guidance such as 'for uncited facts use add_source first' is present.

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