Server Quality Checklist

Tool Scores

• xhs_note_detailA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It lists return content and ID source but does not mention whether the operation is read-only, requires authentication, has rate limits, or how errors are handled. This is a significant gap for a data-fetching 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?

  Two succinct sentences: the first defines the tool's purpose, the second provides a usage tip. No redundant wording or unnecessary detail; every sentence earns its place.

  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?

  Despite lacking annotations or an output schema, the description enumerates the return contents (content, images, engagement metrics, author info, tags) and specifies the input source. For a simple one-parameter tool, this provides sufficient operational context, though edge cases and error handling are not covered.

  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 describes note_id fully ('Xiaohongshu note ID (from search results or URL)') with 100% coverage. The description only repeats this, adding no new semantic meaning. Baseline of 3 is appropriate since the schema carries the burden.

  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?

  Description clearly states the action ('Get full detail') and resource ('specific Xiaohongshu note by ID'), distinguishing it from sibling tools like xhs_search or xhs_user_profile. The verb+resource combination is specific and unambiguous.

  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?

  Provides explicit guidance on where to obtain the note_id ('Use note IDs from xhs_search results'), giving practical usage context. Does not formally enumerate alternatives or exclusions, but sibling tools have distinct purposes, making the intended use clear.

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

• xhs_searchA
  3.8/5.0
  Behavior3/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 of behavioral disclosure. It describes the return contents (titles, engagement metrics, author info, URLs) but doesn't mention authentication needs, pagination behavior, rate limits, or explicitly state that it is read-only. The search semantics imply non-destructiveness, but the description adds minimal behavioral insight beyond the output.

  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, front-loaded with the action ('Search notes on Xiaohongshu'), then efficiently covers return values and use cases. Every sentence earns its place with no redundancy or fluff.

  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?

  With no output schema, the description compensates by specifying the core return values (titles, engagement metrics, author info, URLs) and suggesting use cases. It doesn't describe response shape or error handling, but for a straightforward search tool with well-documented parameters, this is reasonably complete.

  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% description coverage for all 4 parameters, including enums for sort and note_type. The tool description adds no extra parameter semantics, so it stays at the baseline of 3 without compensating for any gaps.

  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 it searches notes on Xiaohongshu and lists the returned data types (titles, engagement metrics, author info, URLs), giving a specific verb and resource. However, it doesn't explicitly differentiate from sibling tools like xhs_note_detail, xhs_user_profile, or xhs_explore, so it falls short of a 5.

  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 use cases ('market research, trend analysis, and competitor monitoring'), giving context on when to use the tool. It lacks explicit exclusions or naming of alternative tools for different scenarios, so it doesn't earn a 5.

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

• xhs_exploreA
  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 behavioral disclosure burden. It does communicate that the tool returns a real-time, platform-level feed, which is useful. But it does not mention any behavioral details such as authentication requirements, rate limits, pagination, or output format. For a read-only feed tool, this is acceptable but not exemplary.

  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 concise: two sentences that lead with the action, then describe the benefit. Every sentence earns its place, with no 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?

  Given the tool's simplicity (single optional parameter, no output schema), the description covers the essential purpose and usage context. It could be improved by mentioning the return format or pagination behavior, but it is largely complete for a trending-feed retrieval 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 schema fully describes the single parameter 'category' with examples, giving 100% coverage. The description does not add extra meaning about the parameter's effect beyond the schema, so the baseline of 3 applies.

  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 fetches the current trending/explore feed from the Xiaohongshu homepage, using a specific verb ('Get') and resource ('trending/explore feed'). It distinguishes itself from sibling tools like search, note detail, and user profiles by focusing on platform-wide trends rather than specific user or search-driven content.

  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 for when to use the tool: 'Great for trend spotting and understanding what resonates with Chinese consumers.' This implies usage for high-level market/trend analysis. However, it does not explicitly mention alternatives or when not to use it, so it falls 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.

• xhs_user_notesA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the return includes 'content portfolio with engagement metrics', which is useful, but it does not mention pagination behavior or that 'all' notes may require multiple calls via the cursor parameter. This is a minor transparency gap.

  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, front-loaded with the core purpose, followed by a use case. There is no unnecessary verbiage or repetition; every word adds value.

  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 list tool with two parameters and no output schema, the description is reasonably complete. It describes the return content (notes with metrics) and mentions a use case. The lack of explicit pagination instructions is a minor gap, but the schema covers it, and the tool is not highly complex.

  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 100% coverage for both parameters (user_id and cursor) with clear descriptions. The tool description adds minimal value beyond what the schema already says, just confirming the resource is a specific user. Since schema coverage is high, a 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 clearly states the action ('Get all published notes') and the target resource ('a specific Xiaohongshu user'), which is precise and unambiguous. It also distinguishes itself from sibling tools like xhs_user_profile (profile info) and xhs_note_detail (single note), making its purpose unique.

  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 use case ('analyzing a creator's content strategy') but does not explicitly state when not to use it or mention alternatives. It offers implied guidance for when this tool is appropriate, but lacks explicit exclusions.

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

• xhs_user_profileA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It makes the read-only nature apparent through 'Get' and lists returned fields, but does not mention authorization requirements, rate limits, or data freshness. For a simple profile lookup this is acceptable, though not exhaustive.

  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: the first states the core purpose and return fields, the second provides practical use cases. There is no filler or redundancy, and 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?

  With only one required parameter and no output schema, the description compensates well by naming key profile fields and a use case. It does not cover error cases or edge conditions, but for a straightforward profile retrieval it is sufficiently complete.

  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 single parameter user_id is fully described in the schema, including its source ('from note details or search results'), so schema coverage is 100%. The description adds no further parameter-specific detail, which is unnecessary given the schema already handles it.

  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 identifies the resource (Xiaohongshu user profile) and specific data points (follower count, total likes, number of notes, bio). It naturally distinguishes from siblings like xhs_note_detail and xhs_user_notes by focusing on the profile-level resource.

  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 explicitly states usefulness for influencer research and competitive analysis, providing clear context for when to use this tool. It does not explicitly rule out alternatives or provide when-not-to-use guidance, but the use cases are informative enough.

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