Server Quality Checklist

Tool Scores

• china_wholesale_pricing_queryA
  4.1/5.0
  Behavior4/5

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

  Beyond the readOnly, idempotent, openWorld annotations, the description discloses a behavioral detail: the tool settles ~0.01 USDC per query via x402. It also outlines the output fields. This adds useful context without contradicting 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.

  Conciseness4/5

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

  The description is composed of four short sentences, each delivering a distinct piece of information (purpose, output, usage, cost). It is efficient with no redundant phrasing, though it could be slightly more compact by merging the usage and cost sentences.

  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 description covers the core aspects: what it does, what it returns, when to use it, and the associated cost. Given the simple query nature and the presence of an output schema, this is sufficiently complete. Minor omissions like pagination or error handling are not critical for a straightforward search/pricing tool.

  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 JSON schema already provides 100% coverage with clear descriptions for all three parameters (keyword, max_price, category_id). The tool description does not add significant additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify formats or edge cases), so it meets the baseline for complete schema coverage.

  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 searches for factory-direct wholesale pricing samples by product keyword, specifying the catalog style (1688/Yiwu) and the return fields (MOQ, unit price USD, factory location, supplier verification flags). This is a specific verb-resource-scope combination that distinguishes it from sibling tools (which handle social media notes or payment status).

  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 usage context ('Use for China sourcing research') and mentions the settlement cost (0.01 USDC). It does not explicitly name alternative tools, but the sibling tools are unrelated domains, so no ambiguity arises. A slight deduction for not stating when not to use the tool.

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

• agentpay_payment_statusA
  4.7/5.0
  Behavior5/5

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

  Annotations already indicate readOnly and idempotent, but the description adds the key behavioral detail 'without charging' and clarifies the purpose of returning configuration data. No contradiction 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?

  Two clear sentences: the first lists the returned fields and the charging behavior, the second gives usage context. No redundant words or filler.

  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 read-only tool with one optional parameter and no need to explain return values beyond what is listed, the description is complete and self-sufficient.

  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 coverage is 100% (the only parameter 'include_wallet' has a description). The tool description itself does not add extra explanation beyond the schema, 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?

  States a specific verb ('Return') and resource ('AgentPay payment configuration'), lists the specific fields returned, and distinguishes itself from paid tools by noting it does not charge. The sibling tools are unrelated, so no ambiguity.

  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 gives when to use it: 'Call this before paid tools to verify the wallet is configured, or after a payment error.' This covers both proactive and reactive use cases, leaving no room for misapplication.

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

• xhs_get_user_notesA
  4.9/5.0
  Behavior5/5

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

  Beyond annotations (readOnly, openWorld, idempotent), the description discloses that each page settles ~0.01 USDC via x402, which is critical for agents to anticipate costs. It also states returns note summaries and next_cursor, making pagination behavior transparent. 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?

  The description is compact, covering purpose, output, usage, and cost in three sentences. No fluff or redundant wording; information is front-loaded.

  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 simple two-parameter paginated list operation and presence of an output schema, the description provides all necessary guidance: what it does, when to use it, what it returns, and how pagination/costs work. No critical context is missing.

  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 coverage is 100% with both user_id and cursor clearly described. The description reinforces pagination behavior but does not add significant new parameter meaning beyond the schema. Slightly above baseline because the description ties the cursor to the prior response's next_cursor.

  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 lists posted notes for a Xiaohongshu user_id and returns note summaries with pagination. It distinguishes itself from sibling xhs_get_note_detail by focusing on listing all notes for a user rather than retrieving a single note's detail.

  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 says 'Use when the user asks for a creator's recent posts,' providing a clear trigger condition. It also mentions pagination via next_cursor and the cost per page, which helps agents decide whether to call this tool.

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

• xhs_get_note_detailA
  5/5.0
  Behavior5/5

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

  Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds a critical behavioral detail: settlement of ~0.01 USDC per successful call via x402, which is not covered by the annotations and is essential for the agent to disclose to the user. No contradiction 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?

  The description is efficient—two sentences that cover purpose, trigger, and cost. It is front-loaded with the primary action and resource, and every sentence adds necessary information without verbosity.

  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 readOnlyHint, openWorldHint, and idempotentHint annotations, plus the explicit description and parameter schemas, the agent has enough context to invoke the tool correctly. The return fields are stated in the description, and sibling tools are clearly distinct by resource and purpose.

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

  Parameters5/5

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

  Both parameters are well-described. 'note' includes an explicit example URL and notes the 24-character hex format. 'note_type' explains its purpose as an optional media hint. Schema coverage is 100%, so nothing is left undefined.

  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 specific resource (Xiaohongshu note), the action (fetch by URL or note_id), and the return fields (title, description, author, engagement stats, images, video URL). It distinguishes the tool from siblings such as xhs_get_user_notes by naming the exact input types.

  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 trigger conditions: 'Call this when the user pastes an xiaohongshu.com/explore link or a note id.' This gives clear direct guidance for when to use the tool and implies when not to (e.g., when a user ID is provided, use xhs_get_user_notes).

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