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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context — that missing/null fields are left unchanged rather than normalized, and that monetary values keep their original unit and runtime type — which warns the agent not to assume uniform units. It says nothing about result limits, coverage, or freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The opening sentence is generic and front-loads no actionable information, while the bulk of the text is a 30-item field dump in one sentence. The field list is arguably the most useful part, but it is undifferentiated and would be better as a return-shape summary than an alphabetical-looking enumeration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, listing known row fields is the right instinct and gives the agent a picture of returnable data. However, given 15 filter parameters the description omits how paging (page/pageSize max 10) and default sorting behave, and does not state that unmatched or unavailable fields come back absent — it only says nulls are left unchanged.

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

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

Schema description coverage is 100% across all 15 parameters, including enum values for country and the sort pattern, so the schema does the heavy lifting. The description contributes nothing about the filter semantics (e.g. how keyword vs category interact, or how the sort field must map to a returned field name), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Provider business records for TikTok Creator Search" essentially restates the tool title and never states a verb+resource pair like "search TikTok creators by keyword and metric range." The long field list does convey the shape of the returned creator records, so an agent can infer this is a creator-listing endpoint, but nothing separates it from siblings such as nexscope_chuhaijiang_tiktok_creator_detail or nexscope_tiktok_creator_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus nexscope_chuhaijiang_tiktok_creator_detail, the creator rankings tools, or the many other creator-search variants in the sibling list. The agent must infer usage from the name alone; no prerequisites, exclusions, or alternatives are named.

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