Server Quality Checklist

Tool Scores

• memory_searchB
  3.3/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 burden. It discloses case-insensitive matching and that results include 'full conversation turns,' but omits behavioral details like empty result handling, search scope limitations, or result ordering.

  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 appropriately sized with the main purpose front-loaded in the first sentence. The Args section, while slightly informal in formatting, efficiently documents three parameters without redundancy.

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

  Completeness3/5

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

  Given the presence of an output schema, the description appropriately avoids repeating return value details. However, for a tool with no annotations and 0% schema coverage, it could further clarify behavior regarding date boundaries or result ranking.

  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?

  With 0% schema description coverage, the description effectively compensates via the Args section. It adds critical semantics: case-insensitive matching for 'query', date format constraint (YYYY-MM-DD) for 'since', and business logic clarification (0 = no limit) for 'max_results'.

  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 the specific verb (search), resource (chat history), and output format (full conversation turns). It implicitly distinguishes from siblings memory_log_conversation and memory_log_conversation_append by function (retrieval vs. storage), though it does not explicitly name them.

  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 provides no guidance on when to use this tool versus its siblings (memory_log_conversation, memory_log_conversation_append). It does not clarify that this is for retrieval while the siblings are for persistence.

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

• memory_log_conversationA
  4.4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Explains temporal scoping ('today's journal'), integrity requirements ('complete' messages), and default title derivation logic. However, lacks disclosure on error handling, idempotency, or size limits before requiring the append sibling.

  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?

  Well-structured with clear progression: purpose → constraints → workflow guidance → parameter docs. The Args section is necessary given 0% schema coverage. Slightly verbose format but every sentence earns its place by conveying required usage constraints.

  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 output schema exists (per context signals), description appropriately omits return value details. Covers primary workflow and sibling coordination. Minor gap: does not specify maximum length thresholds before requiring append tool, which would be useful for 'complete' message handling.

  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% (only titles, no descriptions), but the Args section compensates fully by providing semantic meaning for all 5 parameters, including format examples like 'claude-4-opus' for model and '- `src/foo.py` (created)' for code_changes.

  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 opens with specific verb+resource ('Record one full conversation turn to today's journal') and distinguishes from siblings by explicitly naming memory_log_conversation_append() for handling long replies, clearly differentiating initial logging vs continuation.

  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 conditional guidance: 'If your reply is very long, pass the first part here then use memory_log_conversation_append() for the rest.' Also states mandatory constraints ('You MUST pass the **complete** user message... no truncation').

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

• memory_log_conversation_appendA
  4.6/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It effectively discloses key behaviors: it appends to 'today's journal', maintains 'the same turn' across multiple calls, and guarantees 'no truncation'. Missing minor details like error cases if no previous section exists.

  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 sentences/stanzas: first defines the action, second explains the workflow timing and multi-call behavior, third documents the parameter. No wasted words; information is front-loaded with the core action in the first sentence.

  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 the tool has only one parameter and an output schema exists (so return values need not be described), the description is complete. It adequately explains the journaling workflow, chunking mechanism, and parameter semantics. Could be improved by mentioning error states or auth requirements.

  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 0% (no property descriptions in the JSON schema). The description compensates by documenting the parameter in the Args section, explaining it is the 'Next part of your reply' and adding the 'no truncation' constraint which is not inferable from the schema type alone.

  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 states a specific action ('Append more text') on a specific resource ('the last Agent section in today's journal'). It clearly distinguishes this tool from sibling 'memory_log_conversation' by explaining this is for continuation/appending when a reply doesn't fit in one call.

  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?

  Explicitly states when to use ('Use after memory_log_conversation() when your full reply did not fit in one call') and includes repetition guidance ('Can be called multiple times'). It clearly references the sibling tool as the prerequisite/primary alternative.

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