Server Quality Checklist

Tool Scores

• hasdata_tiktok_profile_getTikTokProfileA
  3.9/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 clearly states the operation is a fetch of public data and enumerates the response fields, but it does not mention behavior around errors, non-existent handles, rate limits, or data freshness. For a benign read operation this is acceptable but has gaps.

  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 core behavior and return fields are packed into a single dense sentence, followed by a concise list of use cases. The opening line 'Get TikTok Profile' is somewhat redundant with the title, but the overall description is lean, informative, and 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 a single well-documented parameter and no output schema, the description compensates by listing the contained fields. It gives enough context for an agent to construct a correct call and interpret the result. It could optionally cover failure cases or input validity expectations, but the essentials are present.

  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%, so the sole required parameter 'handle' is fully documented in the schema, including the '@' detail. The description repeats 'username (handle)' without adding significant new meaning. Baseline 3 is appropriate when the schema already carries the weight.

  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 ('Fetches'), resource ('public TikTok profile'), and identifier ('username (handle)'). It also explicitly lists the returned fields, making the tool's function unmistakable. Sibling names like comments/posts/search make this profile-focused tool clearly distinct.

  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 concrete use cases: enriching CRM/lead records, verifying influencer reach, watching competitor accounts, and building metadata datasets. It clearly implies this tool is for profile-level lookups, though it does not explicitly state when to use alternative sibling tools.

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

• hasdata_tiktok_comments_getTikTokCommentsA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries more behavioral burden. It discloses that the video must be public, describes what each returned comment contains, and mentions nextPageToken-based pagination. It could additionally mention rate limits, auth requirements, or error behavior, but it is already substantially transparent for a GET tool.

  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 front-loaded and each sentence contributes something useful: scope, return fields, pagination, or intended use. It is slightly longer than minimal, but the extra detail is justified because there is no output schema to explain return values.

  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 tool with three parameters and a meaningful output shape, the description covers request behavior, both comment modes, pagination, and the main response fields. The main gap is operational detail such as rate limits, response envelope, and failure modes, but the available context is already strong.

  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 documents all three parameters at 100% coverage, including commentId's reply-switching behavior and nextPageToken's purpose. The description reinforces but does not meaningfully extend the schema, so the baseline 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 uses a specific verb ('Fetches') with a clear resource: TikTok video comments. It distinguishes two distinct modes — top-level comments by videoId and replies by commentId — and clearly separates this from the sibling profile, posts, and search tools.

  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?

  It gives concrete use cases ('sentiment analysis, engagement research, building comment datasets') and situates the tool in a workflow ('a video discovered via the posts or search APIs'). It does not explicitly say 'when not to use', but the context is sufficient for an agent to select it correctly among siblings.

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

• hasdata_tiktok_posts_getTikTokPostsA
  4.1/5.0
  Behavior4/5

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

  With no annotations available, the description carries the behavioral disclosure burden. It accurately conveys read-only intent, reports the approximate page size, and clearly explains pagination via nextPageToken to walk the account history. It does not mention credential boundaries or rate limits, but those are not central to this read-only API.

  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 only three sentences and is front-loaded with the main action, followed by return fields, pagination, and use cases. The returned-field enumeration is slightly long, but each clause adds factual value, making the description efficient rather than padded.

  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 small parameter count and the absence of an output schema, the description provides a strong, actionable mental model of the tool's behavior: input handle, page size, returned video fields, and pagination. It does not show an explicit response example or error conditions, but those are not necessary for a basic fetch-and-paginate workflow.

  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 already documents both parameters completely (100% coverage), so the description does not need to add detailed parameter semantics. It does add the useful note about passing the nextPageToken back for pagination, but this is a modest enrichment rather than a fundamental 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 the action and resource: fetching a page of videos for a public TikTok account by username, then enumerates the returned content fields. This distinguishing account-scoped focus separates it from the sibling tools focused on comments, profile info, or search.

  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 names intended use cases, such as monitoring competitor content, tracking creator engagement, and building datasets for analytics. It does not explicitly state when not to use it or how it compares to the sibling tools, so it misses out on the top score.

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

• hasdata_tiktok_search_getTikTokSearchA
  4.1/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral transparency burden. It fully explains what the search returns, mentions pagination via nextPageToken, and even notes that authors and users carry links to profile and posts endpoints. It does not mention rate limits or auth, but it clearly establishes a read-oriented search behavior and pagination model.

  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 organized and front-loaded with the main purpose: Search TikTok. The following sentences add necessary details about return fields, linked data, pagination, and intended use cases without excessive filler. It could be slightly tighter, but 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?

  For a three-parameter tool with no output schema, the description covers the result shape, pagination behavior, and use cases well. It gives enough information for an agent to invoke the tool with a keyword and interpret the response, though it does not cover edge cases or error conditions.

  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 documents all three parameters with 100% coverage. The description adds some context around pagination and result types, but it does not significantly enrich parameter meaning beyond what the schema already provides. Therefore, the baseline 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 that this tool searches TikTok by keyword and returns either videos or users, enumerating the key result fields for both. This is a specific verb+resource description and is easily distinguished from the sibling profile, posts, and comments tools.

  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 explicit context for when to use it: content discovery, trend research, influencer discovery, or building datasets from a keyword. It does not explicitly list when-not-to-use scenarios or name alternative tools, but it provides enough usage context to guide selection.

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