anneal-memory

Tool Scores

• recordA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full disclosure burden. It successfully explains the accumulation behavior (episodes collect during session) and ultimate destination (compression into continuity file), but lacks operational details like idempotency, memory limits, concurrency, or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four sentences with zero waste: sentence 1 defines the action, sentence 2 lists trigger conditions, sentence 3 gives content guidance with concrete example, sentence 4 explains session lifecycle. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 100% schema coverage and no annotations/output schema, the description appropriately focuses on systemic context—explaining how episodic recording fits into the broader continuity workflow. Missing only technical constraints (rate limits, max episode size) to achieve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% description coverage, establishing baseline 3. The description adds usage context ('Chose X because Y') that informs the content parameter but does not elaborate syntax, formatting rules, or dependencies beyond what the schema already documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Record') and resource ('typed episode to memory'). It clearly distinguishes from siblings by explaining that episodes accumulate during a session and serve as raw material for compression into the continuity file at session end, positioning it distinctly from save_continuity and recall.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit positive guidance on when to call ('when important decisions are made, patterns are noticed...') and content quality expectations ('Record the reasoning, not just the fact'). Lacks explicit exclusions or named alternative tools (e.g., when to use recall instead).

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

• recallA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full behavioral burden. It successfully discloses return ordering ('ordered by timestamp, newest first') and return type ('matching episodes'). However, it omits explicit read-only safety assertions or rate limit warnings that would help an agent understand operational constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four well-structured sentences: purpose (1), usage scenarios (1), return behavior (1), filter summary (1). Zero redundancy; every sentence earns its place with distinct information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 7-parameter query tool with no output schema, the description adequately covers return format and ordering. It could improve by defining the domain-specific term 'episode' or describing behavior when no matches are found, but is sufficient for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, establishing a baseline of 3. The description maps conceptual filter categories ('time range, type, source, and keyword') to parameters but adds no syntax, format details, or semantic constraints beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Query episodes from memory with filters' — a specific verb (Query), resource (episodes), and scope. It clearly distinguishes from sibling 'record' (which implies write/create) by emphasizing retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use scenarios: 'find prior context before making decisions,' 'locate specific episodes for citation during graduation,' and 'review recent work.' However, it lacks explicit when-not-to-use guidance or naming alternatives like 'use record instead for writing'.

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

• prepare_wrapA
  4.5/5.0
  Behavior5/5

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

  With no annotations, description carries full disclosure burden and succeeds. It explicitly states the side effect 'Marks a wrap as in-progress', details the complex return structure (episodes, continuity file, stale warnings, compression instructions), and explains the cognitive purpose of the compression step.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Front-loaded with purpose and trigger conditions. Five sentences total, each earning its place—including the philosophical note about 'real thinking' which clarifies the abstract compression concept. Slightly verbose but justified given lack of output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Compensates well for missing annotations and output schema by describing return values and workflow. Covers domain concepts (episodes, continuity files, stale patterns). Minor gap: doesn't specify error conditions or in-progress state conflicts.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% description coverage for both parameters (max_chars and staleness_days). Description does not repeat parameter details, which is appropriate when the schema is self-documenting. Baseline score applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Prepare' with clear resource 'compression package for session wrap'. It effectively distinguishes from siblings by contrasting with save_continuity (which persists the data) and implying this handles session boundaries vs. ongoing recording.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Excellent explicit guidance: 'Call this at session boundaries — when work is ending, the user says to wrap up, or the session is getting long'. Also provides clear workflow sequence mentioning save_continuity as the required follow-up step, clarifying the tool chain.

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

• statusA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Compensates well by extensively detailing return payload (episode counts, wrap history, continuity file size, wrap status). Implies read-only nature via 'Get,' though could explicitly state 'safe to call' given the mutation siblings context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three efficient clauses: purpose statement ('Get memory health metrics'), usage timing ('Call this at session start...'), and return value specification ('Returns episode counts...'). Front-loaded with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Rich description compensates for missing output schema by exhaustively listing return fields. Explains domain-specific concepts (wrap, continuity, episodes) necessary to understand tool utility. Complete for a zero-parameter diagnostic tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Zero parameters present. Per calibration rules, 0 params = baseline 4. Description correctly omits parameter discussion since schema requires no input.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Specific verb 'Get' + resource 'memory health metrics' clearly identifies this as a diagnostic read operation. Distinguished from action-oriented siblings (prepare_wrap, record, save_continuity) by its observational purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to call: 'at session start' and 'when diagnosing issues.' Provides clear temporal context for invocation. Could be strengthened by explicitly contrasting with mutation siblings, but the verb choice establishes clear separation.

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

• save_continuityA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full behavioral disclosure burden. It comprehensively documents validation logic: structure checking (4 required sections), citation verification against real episodes, explanation overlap detection, citation gaming detection, and consequence handling (demotion of ungrounded graduations). Also specifies return values 'validation results and section sizes' despite lack of output schema. Minor gap: doesn't specify if this operation is idempotent or handles duplicates.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Five information-dense sentences with zero waste. Front-loaded with action+resource, followed by workflow context, input constraints, validation details, and return values. Each sentence serves a distinct purpose and the structure mirrors the invocation lifecycle.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a validation-intensive tool with no annotations and no output schema, the description admirably compensates by detailing complex validation logic and return value characteristics. Would benefit from explicit mention of error handling behavior or failure modes when validation fails, but otherwise comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% but the description adds crucial semantic detail by enumerating the exact 4 required section headers (## State, ## Patterns, ## Decisions, ## Context) that the schema only refers to generically as 'all 4 required sections'. This specificity is essential for correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with specific verbs 'Validate and save' and identifies the exact resource 'compressed continuity file'. It explicitly references sibling tool 'prepare_wrap' to situate this tool in the workflow sequence, clearly distinguishing it from recall/record/status siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Contains explicit temporal guidance 'Call this after compressing your episodes' and cites the prerequisite sibling tool 'prepare_wrap'. Provides clear preconditions (must use prepare_wrap instructions first) and validates specific input structure, effectively establishing when to use this tool versus alternatives.

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