Server Quality Checklist

Tool Scores

• search_ide_historyA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It does not disclose if the tool is read-only, whether it requires authentication, rate limits, or other behavioral traits. The return value is only briefly mentioned.

  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 concise, front-loading the purpose, then listing parameters in a structured Args section. No unnecessary sentences, though the Args section could be more compact.

  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 7 parameters, no output schema, and no annotations, the description covers purpose and parameter meanings but lacks details on pagination behavior, response format, or error handling, leaving some gaps.

  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%, so the description adds value by listing all parameters with brief explanations and defaults. The descriptions (e.g., 'Filter to messages on/after this date (ISO 8601)') are adequate but not highly detailed.

  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 verb 'Search' and the resource 'Kiro IDE conversation history', and explicitly limits to IDE sessions, distinguishing it from sibling tools like search_cli_history.

  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 implies usage for IDE history but does not explicitly state when to use versus alternatives or provide exclusion criteria. Context from sibling names helps but is not in the description itself.

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

• search_cli_historyA
  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 explains the search scope and parameter effects but does not mention side effects, idempotency, authentication needs, or rate limits. It adds some value but lacks comprehensive transparency.

  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 well-structured with a clear purpose statement, usage note, parameter list, and return description. It is concise, though the first two sentences are slightly redundant ('Search Kiro CLI conversation history only.' and 'Use this to find...').

  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 7 parameters and no output schema, the description covers most needed context: parameter meanings, defaults, and a basic return description. Missing details include pagination behavior (offset interaction with max_results) and result ordering, but it is largely sufficient for a search tool.

  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 description coverage is 0%, yet the description includes an 'Args' section that explains each parameter (query, after, before, etc.) with defaults and brief descriptions. This fully compensates for the schema's lack of semantic information.

  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 it searches 'Kiro CLI conversation history only,' using strong verbs and resource specificity. It effectively distinguishes from siblings like search_global_history by narrowing to CLI conversations.

  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 advises using this tool for Kiro CLI sessions, providing clear context. However, it does not explicitly mention when not to use it or reference sibling tools, though sibling names are available.

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

• search_global_historyA
  4.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 describes the search behavior across all workspaces and details parameter defaults, but lacks disclosure on performance implications, rate limits, or error handling. The transparency is adequate but not exhaustive.

  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 concise and well-structured: a clear purpose sentence, a usage context sentence, a bulleted list of parameters with defaults, and a return summary. Every sentence adds value with no extraneous content.

  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 7 parameters, no output schema, and no annotations, the description covers parameter semantics thoroughly and gives a brief return overview. It lacks details on result structure or edge cases, but is sufficient for a search tool with good defaults.

  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 description coverage is 0%, but the description provides detailed explanations for all 7 parameters, including acceptable values (e.g., ISO 8601 for dates), defaults, and purpose for each. This adds significant value beyond the bare 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 'Search conversation history across ALL WORKSPACES', which is a specific verb+resource combination. It distinguishes itself from sibling tools like search_cli_history and search_project_history by emphasizing the global scope.

  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 advises using this tool for cross-project knowledge discovery, listing examples like user preferences and coding patterns. It does not explicitly exclude scenarios, but the sibling tools' scopes provide implicit guidance on when not to use this tool.

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

• search_project_historyA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses the scope (current workspace) and parameter behavior but does not explicitly state read-only nature. The behavior is clearly a search operation without side effects.

  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: a concise intro sentence, a usage guidance paragraph, and a clear Args list. Every sentence adds value, with no fluff or repetition.

  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, the description mentions return structure (messages, scores, context, pagination info). Parameter documentation is complete. However, it could be slightly more detailed about the return format, but it is sufficient for an agent.

  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%, so the description compensates fully with an explicit Args section explaining each parameter's purpose, type, and default. This adds substantial meaning beyond the bare 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 searches conversation history for the current workspace only. The verb 'search' and resource 'project history' are specific, and it distinguishes from siblings like search_global_history by emphasizing workspace scope.

  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?

  It explicitly says to use for workspace-specific context and implies not for global searches. It names sibling tools but does not explicitly tell when to use alternatives. However, the scope restriction is clear.

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