Server Quality Checklist

Tool Scores

• observeA
  4.7/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 explains the logging is for audit and continuity, mentions the salience worker reads events, and describes event shape tolerance (JSON, string). However, it doesn't mention rate limits, storage quotas, or if logging is synchronous—minor gaps for a logging tool.

  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?

  Description is front-loaded with a clear purpose statement, followed by structured sections (WHEN TO/NOT, ARGUMENTS, RETURN). Every sentence adds nuance—no fluff. Examples and edge cases (bare string accepted) are included efficiently.

  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?

  Given the tool's low complexity (1 parameter, required, nested), presence of output schema, and thorough description, this is fully complete. It explains return format, event shaping, and usage context. No gaps remain for an agent to misuse the 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?

  Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the 'actor' field's attribution purpose versus client derivation, listing recognized optional keys with examples, and detailing how arbitrary fields are handled. This exceeds bare schema requirements.

  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 the tool's purpose with a specific verb ('Log a structured event') and resource ('own agent activity to the user's vault'), clearly distinguishing it from siblings like 'remember' and 'recall'. It explains this is for the AI agent's auto-journal, not user-saved content.

  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?

  Explicit 'WHEN TO CALL' and 'WHEN NOT TO CALL' sections are provided, with concrete examples like after completing substantive tasks, and exclusions for micro-steps or conversational acks. It also contrasts with 'remember' for user-chosen content.

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

• recallA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full burden. It thoroughly discloses behavioral traits: read-only nature ('read the user's memory vault'), cheapness ('Recall is cheap'), no side effects from reading, the effect of feedback (drives self-improvement tuner), the mutation via decide (explained as additive optional arg permitted under I1). Return format, field meanings, and edge cases (empty hits, invalidation, cursor cap) are all covered. No contradictions.

  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?

  The description is long but well-structured with clear sections (purpose, when-to, arguments, return). It front-loads the essential purpose and usage mandate. However, some argument documentation is verbose, e.g., the repeated why-optional rationale for decide and feedback could be consolidated. Still, the complexity justifies the length, and the structure aids readability.

  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?

  Given the complexity (14 optional parameters, rich return fields, multiple usage patterns), the description is remarkably complete. It covers all parameters, all return fields with meanings, edge cases (empty hits, invalidation, cursor cap, truncation), and even explains the client field and summary. The output schema is effectively documented inline. No gaps are apparent.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description must compensate for all 14 parameters. It does so extensively: provides natural-language examples for query, explains depth modes with timing and behavior, clarifies limit clamping, verbosity per-level, cursor paging mechanics, full_payload and stats behavior, feedback schema with purpose, decide with verdict options and batch handling, and pending pagination. This adds rich semantic meaning far beyond the bare schema definitions.

  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 a clear verb+resource statement: 'Read the user's memory vault, afair, the persistent substrate they share across every session and every AI tool.' It explicitly identifies the tool as a read operation on the shared memory vault, distinguishing it from sibling tools 'remember' (likely write) and 'observe' (likely watch). This provides unambiguous purpose and scope.

  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?

  The description provides a detailed 'WHEN TO CALL' and 'WHEN NOT TO CALL' section, with explicit scenarios (starting substantive tasks, before context-dependent questions, on topic shifts) and exclusions (pure compute, trivial responses, recent same query). It also suggests alternatives like by_id for full events and stats for snapshots. This is exemplary guidance.

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

• rememberA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels. It explains beyond what annotations might cover: deduplication behavior (identical content+actor), return schema details (event_id, content_hash, deduplicated flag, invalidated list), size limits (10 MB for inline, up to 1 GB via blob-ref), compound event atomicity, and the 'asserted_by' trust model. No contradictions exist.

  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?

  The description is comprehensive and well-organized with clear sections (WHEN TO CALL, WHEN NOT TO CALL, ARGUMENTS, RETURN, etc.). It is front-loaded with the tool's purpose and bias. However, it is verbose in some parts (e.g., the full code examples in parameter descriptions and the disambiguation section) and could be tightened slightly without losing clarity.

  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?

  Given 7 parameters (1 required), 0% schema coverage, no annotations, and the presence of an output schema, the description is fully complete. It explains every parameter in detail, covers the complex content union with 4 variants, clarifies compound event atomicity vs. parent_hashes, and documents the return schema. The output schema exists and the description doesn't repeat it but rather adds behavioral context. No gaps remain.

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

  Parameters5/5

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

  Even though schema description coverage is 0%, the description provides rich, detailed meaning for all 7 parameters. For content, it enumerates 4 discriminated union variants (text, binary, blob-ref, compound) with behavioral intent. It gives concrete examples for context, type_hint, parent_hashes, invalidates, and actor, and includes a detailed disambiguation block for client vs. actor vs. asserted_by. This far exceeds baseline requirements.

  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 uses specific verbs like 'save' and 'remember', clearly identifies the resource as the user's persistent memory vault (afair), and distinguishes itself from siblings by explicitly contrasting with recall (for retrieval) and observe (implied passive). It thoroughly explains the tool's role as a durable, cross-session storage.

  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?

  Provides explicit WHEN TO CALL examples (user says 'remember', shares durable facts, shows content, makes decisions, corrects facts with invalidates) and WHEN NOT TO CALL categories (conversational filler, content destined elsewhere, re-derivable facts, unrequested personal details). Also includes a clear DEFAULT bias toward remembering without asking permission.

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