Server Quality Checklist

Tool Scores

• remind_resumeA
  4.5/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 discloses what the tool does (resolve and output command, cwd, git branch) but does not explicitly state that the operation is non-destructive or read-only. Despite this minor omission, the behavior is clear.

  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 clear sentences for the main action, followed by a short usage paragraph. No redundant information, front-loaded with the core purpose.

  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 one parameter and no output schema, the description is complete. It explains the tool's output (command, cwd, git branch) and its relationship to siblings, fulfilling all informational needs.

  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 the description adds only the detail '8-char prefix' which is already implied in the schema description. Baseline of 3 is appropriate as the description does not significantly add beyond the schema.

  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 that the tool resolves a session ID into a command and additional context (cwd, git branch). It distinguishes itself from siblings by noting that remind_search already returns resumeCommand, so this tool is for cases with only the sessionId.

  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 use' section: only when you have a sessionId and need the resume command; prefer remind_search otherwise. Also gives concrete examples like user pasting bare sessionId or tool flow storing only the id.

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

• remind_searchA
  4.7/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. It discloses the search algorithm (BM25), return fields (snippet, solvedHint, messageUuid, resume command), cost per call, and format options. Does not mention rate limits or token budgets, but for a search tool this is sufficient.

  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?

  Information is front-loaded with the core purpose, then usage guidelines, query tips, and cost details. Every sentence adds value; no redundancy or filler. Well-structured into clear sections.

  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 lack of output schema, the description thoroughly explains return values and actionable follow-up (call remind_message). It covers all aspects an agent needs: when to use, query formulation, format options, and cost awareness. Complete for a search 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 coverage is 80%, and the description adds significant value beyond schema: explains query tips (specific terms to use/avoid), defines enum values for format (compact=400 chars, etc.), and suggests project substring matching usage. The description compensates well for the remaining undocumented parameter aspects.

  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 searches past Claude Code sessions for solutions, with a specific verb and resource. It effectively distinguishes itself from siblings like remind_message (for reading full content) and remind_resume (likely resuming sessions).

  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 use: at task start or when user mentions a problem. Advises one call is sufficient, and provides query tips with good/bad examples. Clearly tells the agent when not to re-call unnecessarily.

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

• remind_sessionA
  4.7/5.0
  Behavior4/5

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

  Mentions the operation is cheap (~1 KB) and provides summary content. No annotations provided, so description carries burden; it could explicitly state read-only/no side effects, but the nature is implied.

  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 concise paragraphs: first states purpose and content, second provides when-to-use. No waste, front-loaded with essential info.

  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 1-param tool without output schema, the description covers purpose, usage context, and parameter details completely. Sibling references are included.

  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 sessionId with description; description adds practical guidance that prefix is enough, which adds value beyond schema.

  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 the tool retrieves a structured summary of a past session with specific content (title, message count, tool names, etc.). Differentiates from sibling `remind_message` for message bodies.

  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 advises using after a `remind_search` hit to get the bigger picture, and directs to `remind_message` for message bodies. Also clarifies that an 8-char prefix sessionId is sufficient.

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

• remind_messageA
  4.9/5.0
  Behavior5/5

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

  Despite no annotations, the description discloses return size limit (~10 KB), the isFocus flag, and behavior when messageUuid is omitted (capped at 50 messages). No contradictions with annotations.

  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 well-structured into three concise paragraphs: what it does, when to use (with siblings), and alternative usage. Every sentence adds value and is front-loaded.

  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 no output schema, the description effectively covers return content and behavior for both modes (specific message and entire session). It addresses sibling tools and provides sufficient context for an AI agent to select and invoke correctly.

  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%, but the description adds extra context beyond schema, such as the 10 KB limit and the 50-message cap when omitting messageUuid. This adds meaningful value beyond the schema's parameter descriptions.

  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 fetches the full text of a specific past message with optional surrounding turns. It distinguishes from siblings like remind_search and remind_session by specifying when each should be used.

  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 provides when-to-use guidance: only after remind_search returns a promising but truncated uuid, and notes not to call for every hit. Also clearly states when to use remind_session instead, providing an alternative.

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