Server Quality Checklist

Tool Scores

• everything_search_advancedC
  2.1/5.0
  Behavior1/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'filtering and sorting options', which are already visible in the schema. It does not state whether the tool is read-only, whether it requires specific permissions, how it handles network or service dependencies, or what the return format is. This is a significant gap for a tool with multiple configuration options.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

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

  The description is only one sentence, which is concise but not appropriately sized for a tool with seven parameters. It lacks any structure or front-loading of key information, and the brevity primarily reflects under-specification rather than efficiency. It does not 'earn its place' by adding substantial value.

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

  Completeness1/5

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

  This is a complex tool with seven parameters, an enum, and no output schema. The description provides almost no context beyond the word 'advanced', failing to explain why one would choose this tool, what the results contain, or any constraints (e.g., default behavior, performance considerations). Given the tool's complexity and the absence of annotations, the description is severely incomplete.

  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?

  The schema description coverage is 100%, so all seven parameters are individually documented. The description's mention of 'filtering and sorting' adds a high-level summary but does not provide any additional meaning beyond what the schema already provides. It meets the baseline but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Advanced search with filtering and sorting options', which clearly indicates a search operation and distinguishes it from the sibling 'everything_search' by the 'Advanced' qualifier. However, it does not specify what resource is being searched (e.g., files, folders, the Everything index), relying on the tool name for context. The verb is present but the object is vague, making it clear yet not fully precise.

  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?

  There is no guidance on when to use this tool versus its sibling alternatives. It does not mention that basic search should be used for simple queries, nor does it explain the advantage of the advanced version beyond its name. No exclusions or alternative recommendations are provided.

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

• everything_searchC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It does not disclose whether the operation is read-only, any dependencies, or potential side effects. The phrase 'using Everything search engine' hints at an external service but lacks explicit behavioral details.

  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 concise sentence that accurately states the tool's purpose. It is appropriately sized with no unnecessary words.

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

  Completeness2/5

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

  Given the absence of an output schema and annotations, the description is too brief to fully convey what results are returned or how the search behaves. It also fails to mention the presence of sibling tools or when to use them.

  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?

  The schema already provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema offers.

  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?

  Description clearly states it searches for files and folders using the Everything search engine. However, it does not explicitly differentiate itself from the sibling tool everything_search_advanced.

  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?

  No guidance is provided on when to use this tool versus alternatives like everything_search_advanced. The description only states the basic function, leaving usage context to the user.

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

• everything_search_docsA
  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 responsibility for behavioral disclosure. It only restates the search action and adds a vague 'optimized' qualifier, with no detail on scope, limitations, return format, or side effects. This leaves the agent with little understanding of the tool's behavior beyond the literal verb/resource.

  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, front-loaded sentence with no filler. Every word adds meaning: 'Search', the resource list, and the 'SpecStory' qualifier all contribute to understanding the tool's purpose.

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

  Completeness2/5

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

  With no output schema and no annotations, the description should compensate by explaining what the tool returns or any operational constraints. It does neither, only stating the search categories. For a specialized search tool with 5 parameters, this is incomplete.

  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 each parameter already has a description. The tool description adds no extra meaning about parameter usage beyond the general 'SpecStory workflows' hint, which does not clarify any specific parameter. Baseline 3 is appropriate.

  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 a specific action ('Search') and resource ('documentation, specifications, and requirement files'), and distinguishes it from the generic sibling 'everything_search' by adding the 'optimized for SpecStory workflows' qualifier. This gives a clear, non-tautological purpose.

  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 phrase 'optimized for SpecStory workflows' provides clear context for when to use this tool, implying it is the docs-focused variant compared to siblings. However, it does not explicitly mention alternatives or when NOT to use it, so it falls short of a 5.

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

• everything_tui_launchA
  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 behavioral burden. It states the tool launches an interactive TUI but doesn't disclose potential side effects such as blocking until exit, requiring user input, or modifying state beyond opening the interface.

  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 immediately conveys the tool's purpose with no wasted 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?

  For a simple launcher with one optional parameter and no output schema, the description adequately covers the core functionality. However, it could mention that the TUI is interactive and may take over the terminal, which would make it more complete.

  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?

  The input schema fully describes the 'mode' parameter with an enum and default value, and schema coverage is 100%. The description adds no additional parameter meaning, so it meets the baseline but doesn't exceed it.

  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 identifies the action ('Launch') and the resource ('Terminal User Interface'), and mentions interactive project management and search. This distinguishes it from sibling tools like everything_search and everything_search_advanced, which are likely non-interactive search functions.

  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 this tool is for interactive use, but it doesn't explicitly state when to use it instead of the sibling search tools or provide exclusions. Users are left to infer that it's for launching a TUI rather than performing a one-off search.

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

• everything_check_serviceA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It clearly states the check behavior but doesn't disclose return format, error handling, or side effects. For a read-only health check, this is a gap but not severe.

  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 with clear structure and no wasted words: verb, resource, and condition. Perfectly concise and front-loaded.

  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?

  For a simple no-parameter tool with no output schema, the description sufficiently conveys the tool's core purpose. It could add return value semantics, but the simplicity of the operation makes this largely adequate.

  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 zero parameters, so baseline is 4. The description adds no parameter-specific details, but none are needed given the empty 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 uses a specific verb 'Check' and a specific resource 'Everything service' with a clear outcome 'running and accessible'. This directly distinguishes the tool from its siblings, which are all search- or launch-related.

  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 is for verifying service status but provides no explicit when-to-use or alternative guidance. Sibling tool names suggest context, but the description itself doesn't state when to prefer this over other tools.

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