Server Quality Checklist

Tool Scores

• get_conversationA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description must disclose all behavioral traits. It explains the output format and context usage, but it omits important details about parameters like max_messages, include_tools, and include_reasoning, as well as any side effects, permissions, or rate limits.

  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 three sentences, front-loaded with the core purpose, followed by guidance on output usage and format options. Every sentence adds value 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 tool has 6 parameters, no annotations, and no output schema, the description covers the main purpose and format guidance but does not elaborate on the behavior of parameters like max_messages, include_tools, and include_reasoning, leaving gaps in completeness.

  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 description coverage is 100%, so baseline is 3. The description adds value for the 'format' parameter by explaining use cases for 'summary' and 'json', but it does not enhance meaning for the other five parameters 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 the tool loads a past conversation by source and id as a readable Markdown transcript, with the specific purpose of continuing it. The verb 'Load' and resource 'past conversation' are precise, and the tool's function is distinct from siblings like list_conversations or search_conversations.

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

  Usage Guidelines3/5

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

  The description provides guidance on when to use different format options (summary for compact handoffs, json for structured models), but it does not explicitly contrast with sibling tools or state when not to use this tool versus alternatives like summarize_conversation.

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

• list_conversationsA
  4/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 describes the output fields and ordering but does not disclose potential side effects, rate limits, authentication needs, or behavior when no conversations exist. For a read operation, this is adequate but not exceptional.

  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 three sentences, front-loaded with the main purpose, and contains no unnecessary words. Every sentence adds value.

  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 simple list structure, 4 optional parameters, and no output schema, the description covers the key aspects: what it lists, ordering, return fields, and use case. It lacks details on pagination limits or empty results, but the limit parameter covers pagination implicitly.

  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 description coverage is 100% for all 4 parameters, so the baseline is 3. The tool description does not add additional meaning beyond what the schema already provides for each parameter.

  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 lists past AI coding conversations across specific tools, sorted most recent first, and identifies the return fields. It distinguishes itself from sibling tools like search_conversations by implying a broader, chronological listing.

  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 explicitly states a use case: 'let the user pick a conversation to continue.' It doesn't explicitly exclude alternatives like search_conversations, but the context of a broad listing versus searching provides implicit guidance.

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

• search_conversationsA
  4/5.0
  Behavior3/5

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

  No annotations provided. Description discloses search scope and returns snippets, but does not mention pagination, ordering, case-sensitivity, or performance characteristics. Adequate but lacks some behavioral details a read-only search tool should disclose.

  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 sentences, front-loaded with action, no redundant words. Every sentence adds value.

  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 output schema and 3 params, description covers search scope, return type (snippets), and links to get_conversation. Missing details like default limit, source enumeration reference, and potential pagination, but overall adequate.

  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 67% (query described, source limited enum in description). Description adds context that query searches across titles, bodies, and results, but does not explain limit's default or behavior. Adds some value but not full compensation for missing 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?

  Clearly states full-text search across conversations including titles, message bodies, and tool results/args. Distinguishes from sibling tools like get_conversation (loads one) and list_conversations (likely lists without search).

  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?

  Explicitly says to use this tool to search and then load with get_conversation. Implies not for loading full content, but does not explicitly mention when to use alternatives like list_conversations.

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

• summarize_conversationA
  4/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 states the summary is 'extracted deterministically without an LLM,' which is a useful behavioral trait. However, it does not explicitly state whether the tool is read-only or has side effects, leaving some ambiguity. For a tool that likely only reads data, mentioning it does not modify the conversation would improve transparency.

  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 consists of two concise sentences. The first sentence defines the output format (handoff card with five fields). The second sentence provides usage guidance and comparison to sibling. No extraneous information; every sentence earns its place.

  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 2 parameters, no output schema, and no annotations, the description adequately explains the return format (a structured handoff card) and the deterministic extraction method. It also guides usage in context of long sessions. However, it could be more complete by mentioning what the tool does NOT include (e.g., full conversation text) to set expectations further.

  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 description coverage is 100%, so the baseline is 3. The description does not add any additional meaning about the parameters beyond what the schema already provides. The schema's descriptions ('conversation id from list_conversations' and the list of allowed sources) are sufficient, and the description doesn't need to repeat them.

  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 a specific verb 'Return' and describes the output as a compact 'handoff card' with five deterministic fields (目标/已完成/卡点/待办/最后状态). It explicitly distinguishes from sibling tool 'get_conversation' by noting it is for long sessions, making purpose clear.

  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 states 'Prefer this over get_conversation for long sessions' and explains why (carries intent/next-step at fewer tokens). This provides clear guidance on when to use the tool vs the sibling, though it does not explicitly mention when not to use it.

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

• list_sourcesA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: it lists configured sources and checks availability. No hidden or destructive actions are implied, and the description is transparent about the read-only nature.

  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?

  A single sentence that front-loads the action and necessary detail. No wordiness; every part is essential.

  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?

  Despite no output schema, the description sufficiently describes what the tool returns (list of sources with availability). For a parameterless tool, this is complete and actionable.

  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?

  There are no parameters, so per the baseline rule (0 params = baseline 4). The description does not need to add parameter details since schema coverage is 100% trivially.

  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 lists configured conversation sources and their availability, with specific examples (claude, codex, cursor, glm). It clearly differentiates from sibling tools that deal with conversations themselves, not sources.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives or provide any usage context. It is straightforward but lacks guidance for the agent.

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