Server Quality Checklist

Tool Scores

• get_audit_logC
  2.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden for behavioral disclosure. It usefully explains that results are chronological, filtered by 'since', and cover certain event types. However, it does not disclose pagination, response shape, or the behavior when 'since' is null.

  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 tight and front-loaded, with the core purpose stated first and the 'since' behavior in the second sentence. It wastes no words, though the missing scope explanation prevents a top score.

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

  Completeness2/5

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

  For a tool with no annotations and no output schema, the description leaves important gaps: it does not define the required 'scope' parameter, describe the return structure, or state how 'since' defaults behave. The event-type list is helpful but only partially completes the picture.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It clearly documents the 'since' parameter as an ISO8601 timestamp with ordering semantics, but it does not explain the meaning of the required 'scope' parameter at all, leaving a significant gap.

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

  Purpose4/5

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

  The description identifies the tool as a human-readable audit trail and lists the event categories it covers (written, invalidated, superseded, resolved) plus the rationale. This distinguishes it from the sibling memory operations, though it lacks an explicit retrieval verb like 'gets' or 'returns'.

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

  Usage Guidelines2/5

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

  The description implies this is for viewing historical audit information but gives no explicit guidance on when to choose this over write_episode, query_memory, or record_recall_save. There are no stated exclusions, prerequisites, or alternative routing conditions.

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

• write_episodeA
  4.3/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 meets it thoroughly. It discloses that the server never calls an LLM and that the calling agent must extract entities/facts itself, specifies that the confidence value must be exactly one of three literal strings or the call is rejected, and explains when entity_resolutions is required. It also documents the strict matching constraint between fact source/target and entity names, giving the agent a clear behavioral model.

  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?

  The description is long but every sentence earns its place: it front-loads the purpose, gives precise field-by-field shapes and validation rules, and ends with a concrete example. Given that the schema provides no property descriptions, the length is justified and well-structured rather than verbose.

  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 5-parameter tool with no annotations, no output schema, and an empty schema, the description covers the entities/facts structure, confidence validation, optional entity_resolutions flow, and an example. It falls short on the semantics of scope and session_id, and it does not describe what the tool returns in response, so an agent still has some uncertainty about the complete call contract.

  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?

  The input schema is nearly empty (objects with additionalProperties: true and 0% description coverage), so the description must compensate. It richly defines entities (name, type, uniqueness), facts (source/target/relation_type/fact/confidence with validation), and entity_resolutions (resolved_to or new). However, the two required parameters scope and session_id are only shown in the example call and never semantically defined, leaving a gap in compensation.

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

  Purpose4/5

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

  The description clearly states a specific verb and resource: 'Record something worth remembering later' and enumerates concrete examples (a decision, a correction, a stated preference, or context). It does not explicitly contrast itself with the sibling tool 'record_recall_save', so an agent cannot immediately distinguish between the two write-like tools, which prevents a 5.

  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?

  The description gives explicit situational triggers: 'Call this proactively and immediately when you notice one of these - don't wait to be asked, and don't batch it up for later in the conversation.' It also explains the cost-benefit rationale for erring on the side of calling. However, it does not mention any alternatives or state when not to use the tool, so it lacks exclusions and sibling routing.

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

• record_recall_saveA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and handles it thoroughly. It discloses idempotency (duplicate note is a no-op), disqualification (same-tool recalls are recorded but do not count), server-side written_by resolution, and the consequences of inflated counts. It also warns that the caller cannot assert authorship.

  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 front-loaded with the core action and trigger, then organized into focused paragraphs. It is long, but the behavior is subtle enough to justify the length. The historical note about v1a is arguably redundant for callers, but it does explain why fact_id is required.

  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?

  The description is unusually complete for a recording tool: it explains when, why, and how to call it, including edge cases and disqualifying conditions. It falls short of a 5 only because the required `scope` parameter remains undocumented and success/error behavior is not explicitly described beyond the duplicate no-op.

  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?

  The description adds meaningful context for fact_id, note, and recalled_by, going well beyond the bare schema. However, schema coverage is 0% and the required `scope` parameter is never explained, leaving a significant gap in a required field.

  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 specific verb and resource: 'Record that a fact you recalled from memory saved the user from re-explaining something to you.' This clearly distinguishes it from siblings like query_memory (which reads memory) and write_episode (which writes memory) by positioning it as a post-recall evidence-recording action.

  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 gives an explicit trigger condition: call in the same turn, only when query_memory returned a memory-derived fact that would otherwise require re-explanation, and only when the fact was written by another tool or past session. It also lists clear exclusions: do not call speculatively, for facts written this session, or simply because the recall was interesting.

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

• query_memoryA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does well: it discloses that digest=True ignores the query, returns the most recently written active facts, and is never automatic. It also reveals the pending_ingest field behavior and why the queue exists, which is valuable operational 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?

  The description is front-loaded with the main purpose, then usage, then digest, then the pending_ingest workflow. Each paragraph is relevant and non-redundant; the length is justified by the tool's complexity.

  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?

  The description covers purpose, usage timing, scope semantics, digest behavior, and the pending_ingest workflow. It is less complete on the output format of ordinary recall results and top_k semantics, which matters more because there is no output schema.

  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?

  The schema has 0% description coverage, so the description must compensate. It explains scope values ('solo' vs 'shared') and the digest parameter's behavior in detail. However, top_k is never mentioned, and the behavior of a null query without digest is left unspecified.

  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 and resource: 'Recall prior facts relevant to query' from memory. It immediately clarifies the two scopes ('solo' vs 'shared'), making the tool's function unmistakable and distinct from write-oriented siblings like write_episode.

  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?

  Usage is explicitly prescribed: 'Call this at session start, and any other time recalling prior context would save the user from re-explaining something.' It also tells the agent to check here before asking the user to repeat themselves, and it explains when digest should be invoked explicitly.

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