Server Quality Checklist

Tool Scores

• capture_thoughtA
  4.1/5.0
  Behavior3/5

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

  Without annotations, description carries full burden. It explains the store persists across sessions and is primarily for conventions. It also instructs agent to echo captured content back. However, it does not disclose potential side effects (e.g., overwrites or appends, storage limits, 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.

  Conciseness3/5

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

  Description is moderately concise; it front-loads purpose and usage but contains some redundancy (e.g., multiple examples of conventions). Could be trimmed without losing critical guidance. Still, every sentence serves a purpose.

  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 5 required parameters and no output schema, description covers purpose, usage, parameter classification, and post-call behavior. However, it lacks details on error conditions, duplicate handling, and storage limits, which would be needed for full completeness.

  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 covers all 5 parameters with descriptions, so baseline is 3. Description adds value by advising on classification based on conversation and emphasizing that content must be a clear, standalone statement. This goes beyond schema to guide agent on proper use.

  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 clearly states the tool saves coding conventions, instructions, corrections, and preferences for future reference. It provides specific examples and distinguishes itself from siblings (delete_thought, search_thoughts, thought_stats) by focusing on capture.

  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 guidance on when to call: 'whenever the user states a rule or preference...' and what not to do: 'don't wait to be asked to save it.' Also covers handling multiple rules: call once per rule. Distinguishes primary use from occasional non-coding notes.

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

• thought_statsA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavioral traits. It states what the summary includes but lacks details on performance, data freshness, or side effects. As a read-only tool, this is minimally adequate.

  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 a single, well-structured sentence that front-loads the purpose and lists key output components without unnecessary words.

  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 no input parameters and no output schema, the description adequately outlines what the tool returns. It could specify limitations like the number of top topics, but is sufficient for a simple aggregation 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?

  The tool has no parameters, and the input schema coverage is 100%. The description adds value by detailing the content of the summary, meeting the baseline expectation for zero-parameter tools.

  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 clearly states the tool provides a summary of captured data including totals, types, top topics, and scopes. It effectively distinguishes from sibling tools (capture_thought, delete_thought, search_thoughts) by focusing on aggregation and statistics.

  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 implies usage for obtaining an overview of captured conventions, but does not explicitly compare to alternatives or give exclusions. However, the purpose is straightforward with no parameters, making usage clear.

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

• search_thoughtsA
  4.3/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. Describes hybrid search (by meaning and exact keyword), which is key behavioral info. Lacks details on performance or return format, but adequate for a search tool.

  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?

  Two sentences: first defines purpose, second gives usage guidance. Concise and front-loaded. Second sentence is slightly long but still efficient.

  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?

  With two simple parameters and no output schema, description covers purpose and usage well. Lacks return format or parameter details, but overall sufficient for an agent to understand when and how to use.

  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 coverage is 50% (query has description, limit does not). Description adds no parameter-specific details beyond schema. Does not explain limit or query context further, so baseline 3.

  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?

  Clearly states verb 'look up' and resource 'previously stored coding conventions, standing instructions, and preferences'. Distinguishes from sibling tools like capture_thought (store) and delete_thought (delete).

  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 guidance: 'Call this proactively before starting unfamiliar coding work' and 'when the user references a past preference or rule'. Even advises against waiting for user request.

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

• delete_thoughtA
  4.7/5.0
  Behavior5/5

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

  Discloses that deletion is 'destructive and irreversible — no undo, no trash'. Since no annotations provided, description fully addresses behavioral traits.

  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?

  Two sentences, front-loaded with purpose, no wasted words. Structured effectively.

  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?

  For a simple tool with 1 param, no annotations, no output schema, the description covers all essential aspects: purpose, irreversibility, proper usage, and alternative actions.

  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 coverage is 100% and schema already explains the 'id' parameter well. Description adds no additional meaning for the parameter itself, staying at baseline.

  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?

  Clearly states 'permanently delete a specific captured thought by its ID' with specific verb and resource. Distinguishes from siblings by emphasizing destructive nature.

  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 (user asks to delete/remove/forget) and when not (proactively, as side effect, on guess). Provides alternative: use search_thoughts/list_thoughts first and confirm with user.

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