Server Quality Checklist

Tool Scores

• wechat_get_draftA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare read-only and non-destructive behavior. The description adds that this operates on WeChat draft content, but doesn't mention error conditions, return shape, or external dependencies like auth/tokens.

  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?

  One concise sentence, front-loaded with the action and resource, with no filler or redundancy.

  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 one-parameter read operation, the description plus annotations are sufficient for basic selection. It could mention return value or failure behavior, but those are not critical for understanding what the tool does.

  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 for the parameter is 0%; the description only repeats 'media_id' without explaining its source, format, or lifecycle. It adds minimal meaning beyond the parameter name.

  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 ('read') and the resource ('draft content from WeChat') with an explicit parameter ('media_id'), which distinguishes it from sibling tools like create/validate/check.

  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 intended use is obvious: retrieve a draft using its media_id. It doesn't explicitly contrast with alternative tools, but the reading/retrieval context is clear.

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

• wechat_validate_article_bundleA
  4.1/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false, and the description adds valuable behavior beyond them: local execution, no upload, and image preprocessing. It also clarifies that bundle_path refers to an article folder inside the official-account working directory rather than an arbitrary path.

  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 short, purposeful sentences: the first identifies the operation and exclusions, the second defines the sole parameter. There is no filler, repetition of schema, or unnecessary detail.

  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?

  The definition covers local/no-upload behavior and the parameter, which is adequate for a one-parameter tool, but it does not describe what the tool returns on success/failure or what 'preprocess' entails. Since there is no output schema, an agent is left without knowledge of the validation result format.

  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 description coverage is 0%, so the description must carry the parameter meaning. It explains bundle_path as '公众号工作目录内的文章文件夹路径' (article folder path within the official-account working directory), which is far more useful than the bare string type. It does not specify relative vs. absolute formatting, but is sufficient for invocation.

  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 verb, 'validate', and a concrete operation, 'preprocess images', with a clear scope: local only, '不上传' (no upload). This distinguishes it from siblings like wechat_create_draft_from_bundle without requiring schema inspection.

  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 phrase '本地校验...不上传' gives useful context that this is a local pre-upload step, but it never names alternatives or explicitly says when to use this tool versus checking access or creating a draft. The usage conditions are implied rather than stated.

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

• wechat_create_draft_from_bundleA
  4.3/5.0
  Behavior5/5

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

  The description adds significant behavioral context beyond the annotations: the tool is idempotent ('相同内容重复调用返回既有草稿'), requires explicit user consent, and will not publish. These are important operational traits that the annotations alone do not convey.

  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?

  Three short sentences cover the action, the prerequisite, the non-publish guarantee, and idempotency. Every sentence adds distinct value, and the most important information is 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 single-parameter tool with no output schema and informative annotations, the description is nearly complete: it defines the operation, the user-consent requirement, the non-publishing scope, and duplicate-call behavior. It could be slightly more complete by mentioning what the tool returns (e.g., draft ID), but this is a minor gap.

  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?

  With 0% schema description coverage, the schema provides only a required string 'bundle_path' with minLength 1. The description mentions 'article bundle images' but does not clarify what bundle_path should point to, what format is expected, or how it relates to validation tools. The description does not adequately compensate for the missing parameter documentation.

  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: uploading article bundle images to WeChat and creating a draft. It clearly differentiates itself from siblings like wechat_validate_article_bundle and wechat_get_draft, and explicitly notes that it will not publish, so an agent knows exactly what this tool does and does not do.

  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 gives an explicit precondition: the user must clearly request uploading the article. It also explains that the tool creates drafts only and will not publish, which helps the agent choose it over publishing or validation tools. However, it does not explicitly mention when to prefer sibling tools such as wechat_get_draft or wechat_validate_article_bundle.

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

• wechat_check_accessA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context by stating that the result does not include secret keys or Access Tokens, which is valuable security-relevant information beyond the 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?

  The description is a single, focused sentence. It front-loads the action and resource, then adds a useful security caveat without any redundancy or filler.

  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 zero-parameter, read-only validation tool, the description is sufficiently complete. It explains what is checked and what is intentionally omitted from the result. Minor absence: it does not describe the exact success/failure output shape, but that is not critical for such a simple check.

  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 parameter-level explanation is unnecessary. Per the baseline for zero-parameter tools, a score of 4 is appropriate, and the description appropriately avoids inventing parameter details.

  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 ('验证' / validate) and names concrete resources: WeChat Official Account credentials and API IP whitelist. This clearly identifies the tool's function and distinguishes it from the sibling tools, which all deal with article bundles or drafts.

  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 makes the tool's context clear: it is a pre-flight access check for credentials and IP whitelist. It does not explicitly name alternatives or when-not-to-use conditions, but the sibling tools are so different that the intended usage is evident.

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