Server Quality Checklist

Tool Scores

• check_textA
  4.6/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint=true, openWorldHint=false), the description adds that the tool is read-only, stateless, never stores text, returns a plain-text report with line/column details, and has a character limit error.

  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 dense but every sentence adds value. It could be more structured (e.g., bullet points) but remains concise and front-loads the main 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?

  Given the complexity (3 params, nested objects, no output schema), the description covers output format, error conditions, sibling usage, and behavioral traits. No obvious gaps.

  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 already covers all parameters with descriptions (100% coverage). The description adds minor context (character limit, output format) but doesn't significantly enhance understanding of schema-defined parameters like config or format.

  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 analyzes text for specific writing style issues, listing them explicitly. It also differentiates from sibling tools by specifying when to use check_text vs check_file and mentions follow-up with fix_duplicates.

  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: use for text in conversation, use check_file for files, and follow up with fix_duplicates for auto-removal. Also notes that texts over 100k chars return an error.

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

• list_word_listsA
  4.7/5.0
  Behavior4/5

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

  The description states it is read-only (consistent with readOnlyHint annotation), takes no parameters, and returns the same catalog per release (constant behavior). This adds context beyond annotations, though it could mention potential dataset size or caching.

  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 that front-load the purpose and key features with zero waste. Every sentence serves a clear function.

  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 fully enumerates what the tool returns (entry count, config key, sample entries, link). For a zero-parameter read-only catalog tool, this is complete and clear.

  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 description confirms this ('takes no parameters'). Per the rubric, 0 parameters earns a baseline of 4; no additional value needed.

  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 specifies a clear verb ('return') and resource ('every detector word/phrase list') with detailed output fields (entry count, config key, sample entries, link). It distinguishes from siblings check_file, check_text, and fix_duplicates, which are for checking and fixing.

  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?

  The description explicitly states when to use the tool ('before tuning a config for check_text or check_file') and when not needed ('not needed for ordinary checking'), providing clear guidance relative to sibling tools.

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

• check_fileA
  4.9/5.0
  Behavior5/5

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

  Annotations set readOnlyHint=true, and the description reinforces 'Read-only: the file is never modified.' It adds important details like Markdown masking for code blocks/tables, auto-discovery of config, and error conditions for unreadable/oversized files. 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?

  Concise at approximately 100 words, every sentence serves a purpose. Front-loaded with the core action, then adds behavioral semantics and usage guidance without redundancy.

  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 adequately explains the return format (same line-and-column report as check_text) and error conditions. Covers config auto-discovery, file size limit, and Markdown masking, making the tool's behavior fully understood.

  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 both parameters with descriptions (100% coverage). The description adds value by explaining path must be UTF-8 and that setting config disables auto-discovery, which enriches the schema 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?

  Explicitly states the tool reads a file from local disk and analyzes for writing style issues, directly distinguishing it from check_text for inline text. The verb 'read and analyze' clearly specifies the action on the resource.

  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: 'Use when the text lives on disk; use check_text for text already in the conversation.' This clearly defines appropriate use cases and the alternative tool.

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

• fix_duplicatesA
  4.9/5.0
  Behavior5/5

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

  Annotations already set readOnlyHint=true and openWorldHint=false. The description adds that the fix is returned in the response with no side effects, reinforcing the read-only nature and adding context beyond 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?

  Two concise sentences front-loading the action and key details, with no unnecessary words. Every sentence earns its place.

  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 provides complete context: what it does, what it returns, when to use it, and behavioral constraints. Annotations cover safety aspects.

  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 schema has 100% coverage for the single parameter 'text' with a basic description. The tool description adds global context (case-insensitive, across line breaks) that goes beyond schema, enhancing understanding.

  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 removes duplicate adjacent words case-insensitively, including across line breaks, and returns cleaned text plus removed words list. This distinguishes it from siblings like check_text and check_file which only report issues.

  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 instructs to use after check_text or check_file reports duplicate words, and notes that other issue types are report-only. Provides clear when-to-use guidance.

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