Server Quality Checklist

Tool Scores

• convert_textB
  3.2/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden of behavioral disclosure. It simply states the conversion without detailing how formatting, links, code blocks, or options are handled. Only a minimal behavioral statement is given.

  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 unnecessary words or repetition. It is directly informative and earns its place.

  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?

  The tool has a nested options object and no output schema, indicating some complexity. The description covers only the core function and omits behavioral context, such as how options affect the output or potential limitations. It is too sparse for full contextual 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?

  The input schema already describes the 'markdown' parameter and the sub-properties of 'options'. The description adds no additional parameter meaning. With 50% schema coverage (the top-level 'options' object lacks a description), the description does not compensate, but the schema provides adequate baseline 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 the action (convert), the input (markdown text), and the output (plain text). It distinguishes from sibling tools like convert_file and convert_url by specifying the input type as text rather than file or URL.

  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. It does not mention sibling tools, prerequisites, or exclusions, so the agent must infer usage from the name and minimal description.

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

• convert_urlB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden. It only states the basic operation and omits behavioral details such as network request implications, failure modes, or output format. The read-only nature is implied but not explicit.

  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 sentence with no redundant wording, efficiently conveying the core purpose. However, it is under-specified in other dimensions.

  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?

  The tool has a nested options object and sibling tools, yet the description doesn't address the conversion options, output expectations, or differentiation from siblings. This minimal description is insufficient for an agent to select and use the tool correctly in all contexts.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is at 50%, and the description does not explain how the options parameter affects conversion. It only restates the url concept without adding meaning beyond the schema's own field 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 action: 'Fetch remote URL markdown content and convert to plain text', using a specific verb and resource. It distinguishes from sibling tools like convert_text and convert_file by emphasizing the remote URL source.

  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 remote markdown URLs but provides no explicit guidance on when to prefer this over convert_text or convert_file. No alternatives or exclusion criteria are mentioned.

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

• convert_fileB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits. It states the conversion direction but does not mention whether it is read-only, how it handles edge cases (e.g., unsupported Markdown elements), or what the return format is. This is minimal for a tool with zero annotation coverage.

  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 one sentence, front-loaded with the verb, and zero wasted words. It is immediately clear and concise.

  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 moderate complexity (nested options), no annotations, and no output schema, the description is minimal but covers the core purpose. However, it lacks context about return values, error behavior, and option implications, though those are partially discoverable from the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 50% (path is described, options is not). The description adds no parameter semantics or context about the options object. While the schema's individual property descriptions exist, the description fails to compensate for the missing top-level parameter explanation.

  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 a specific verb ('Convert') with a specific resource ('local markdown file') and output ('plain text'). It distinguishes from sibling tools by explicitly targeting local files, unlike convert_text or convert_url.

  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 use for local markdown file conversion but does not explicitly mention when not to use it or name alternative tools. Sibling tools are listed in context, but the description itself provides no exclusions or alternatives, leaving the agent to infer based on the tool name.

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

• batch_convertA
  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 the full burden. It only states the action without disclosing whether files are modified in place, what output is returned, or any side effects. This is a significant gap for a conversion tool.

  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 sentence, front-loaded with the core action and scope, with no wasted words. It is perfectly concise for the information it conveys.

  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 annotations or output schema, the description leaves critical context unexplained, such as the output format, whether files are overwritten, and how options affect conversion. Given the tool's complexity (nested options, recursive flag), this is insufficient for an agent to invoke it confidently.

  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 provides descriptions for most parameters (75% coverage), including directory, pattern, recursive, and nested option properties. The description adds no parameter details, but the schema already covers the essentials, so the baseline of 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 'Batch convert markdown files in a directory' clearly uses a specific verb and resource, and the 'batch' and 'directory' modifiers distinguish it from sibling tools like convert_text, convert_file, and convert_url. It unambiguously states what the tool does.

  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 'in a directory' implies this tool is for directory-level batch conversion, providing clear context for when to use it over single-file or URL tools. However, it does not explicitly mention alternatives or when not to use it, stopping short of a full 5.

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