coherra_remember

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

With no annotations, the description must carry the behavioral burden by itself. It does add some transparency: it states that the tool wraps memory_remember, enforces a versioned body shape for uniformity/auditability, and returns a success dict. However, it does not disclose what happens on duplicate category/name (overwrite vs error), effect on existing memory, or any permission/rate-limit constraints.

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 front-loaded with the core purpose, followed by a compact one-line implementation note, a structured Args list, and a Returns line. Every section carries information; 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?

The five parameters are fully explained, and the return shape is stated. The main gap is lack of guidance on duplicates or failure modes, which could matter for a memory-write tool. However, the presence of an output schema softens the return-value burden, and the description is largely sufficient for successful invocation.

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's Args section fully compensates. It gives logical grouping examples, unique-within-category semantics for name, JSON-serializable requirement for value, a 0.0–1.0 range for confidence, and provenance examples for source. This goes beyond the raw schema types.

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: 'Store a structured fact in Sibyl Memory using Coherra's schema.' This clearly distinguishes the write operation from retrieval siblings like coherra_recall and coherra_list, and the mention of a versioned body shape adds precision.

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 the tool is for persisting facts but never explicitly states when to choose it over siblings or when not to use it. There is no exclusionary guidance (e.g., 'use coherra_recall to read'), so the agent must infer usage from the verb 'Store' and the sibling names.

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