Server Quality Checklist

Tool Scores

• convert_markdown_to_wechat_htmlA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the output HTML includes inline styles and is intended for copy/paste workflows, which are behavioral traits. It does not mention potential limitations or details about the conversion process, but for a pure conversion tool, it adequately describes the core behavior.

  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 starts with the main verb 'Convert.' It wastes no words and immediately communicates the essential purpose and a key detail (inline styles).

  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?

  The tool has a simple parameter set, and the schema covers parameters. There is no output schema, but the description implies the output is HTML. It does not mention the return format in detail, but for this straightforward conversion tool, the description is sufficient given its simplicity.

  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 has 100% coverage with descriptions for all three parameters (markdown, theme, title). The description itself adds no additional parameter information, so the baseline of 3 is appropriate. The schema already explains the parameters sufficiently.

  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?

  The description clearly states that the tool converts Markdown to WeChat-friendly HTML, with a specific verb ('Convert') and resource ('Markdown to WeChat-friendly HTML'). It also mentions inline styles and publishing workflows. However, it does not explicitly differentiate from sibling tools like open_wechat_html_in_browser, though the distinct action implies differentiation.

  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 provides a clear context: 'for copy/paste publishing workflows,' indicating when to use this tool. It does not mention alternatives or exclusions, but the use case is well implied. No explicit 'when not to use' is provided, but the stated purpose is clear enough.

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

• list_wechat_themesA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It states the tool lists available themes, implying a read-only operation, but does not describe the output format, any side effects, or security considerations. It adds minimal behavioral context beyond the name.

  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, directly stating the action and subject. It contains no filler or redundant information.

  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 simplicity of the tool and lack of parameters, the description is adequate. However, it does not describe what the returned theme list looks like (e.g., array of strings) or how these themes relate to the sibling tools, leaving some room for ambiguity.

  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 zero parameters, so the baseline of 4 applies. The description does not need to explain parameter semantics, and it correctly conveys that the tool requires no input.

  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 'list' and resource 'available rendering themes', clearly distinguishing it from sibling tools that open HTML or convert Markdown to HTML.

  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?

  No explicit guidance on when to use this tool vs alternatives is provided. The usage is implied by the name and description—when you need to see available themes—but there is no mention of exclusions or alternative tools for related actions.

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

• open_wechat_html_in_browserA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It states that the tool opens a file in a browser, which implies a read-only, non-destructive action, but it does not mention potential side effects like launching an external application, whether the browser will block, or what happens if the file path is invalid. The workflow instruction adds context, but some behavioral details remain implicit.

  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 two sentences with no wasted words. The first sentence front-loads the core action, and the second provides essential workflow guidance. Every word earns its place, making it highly concise and well-structured.

  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 single-parameter tool, the description covers the purpose, the workflow, and the necessary context (cached file from conversion). It doesn't elaborate on error handling or return values, but given the tool's simplicity and the schema already documenting the parameter, the description is sufficiently complete. A brief note about the file not existing would be a minor enhancement, but it's not critical.

  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 covers the single parameter (cache_path) with a clear description stating it is returned by convert_markdown_to_wechat_html. The tool description adds the word 'cached' and the workflow context, but this is largely redundant with the parameter description. Baseline 3 is appropriate since the schema already provides the essential meaning.

  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 (open), the target resource (cached WeChat HTML file), and the destination (default browser). It also includes the follow-up workflow (select all, copy, paste), making the tool's purpose unambiguous and distinct from the sibling tools that convert or list themes.

  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 provides clear context: it is used after converting Markdown to WeChat HTML, as it references the cached file. The second sentence explains exactly what to do next, effectively telling the user when to use this tool (as an intermediate step) and what actions follow. It doesn't explicitly mention alternatives, but no real alternatives exist for this specific open-and-copy workflow.

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