Finewisdom 社媒与电商数据接口

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

No annotations are provided, so the description carries the full burden, and it discloses nothing: no auth requirements (despite the schema exposing a _token fallback), no rate limits, no read/write nature, no return shape. Four characters cannot cover a behavior profile.

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 description is a bare four-character fragment with no structure or front-loading of actionable information. It is not concise-but-complete; it is simply under-specified.

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 annotations, no output schema, and a two-parameter input including an auth token, the description should explain what details are returned and how authentication works. It supplies none of this, leaving the agent unable to call the tool confidently.

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%, with bv_id documented as 'BV号' and _token explained as a fallback auth token, so the schema does the heavy lifting and baseline 3 applies. The description adds no meaning beyond the schema.

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?

The phrase 'B站视频详情' identifies the resource (a Bilibili video) and implies a retrieval/detail operation, which is enough to distinguish it from siblings like bili-adjacent or other-platform video tools. However, it names no explicit verb and gives no scope (which fields, single vs. batch), so the purpose is only implied rather than stated.

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 alternatives such as channels_video, yt_video, or douyin_video. No prerequisites, no mention of required BV id usage context. The agent must infer everything from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no statement of read-only nature, no pagination behavior despite the last_buffer cursor parameter, no auth note despite the _token parameter, no rate limits. '评论列表' implies a read, but that is inference, not disclosure.

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?

A single short sentence with the resource named first and the parameter provenance in parentheses. Zero waste and ideally front-loaded for a tool of this simplicity.

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?

For a four-parameter list tool with no output schema and no annotations, the description covers the required parameter's origin but omits result shape, pagination semantics for last_buffer, and the role of comment_id (reply retrieval). The schema carries parameter documentation, so it is adequate but with clear gaps.

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%, so the baseline would be 3, and the description adds genuine meaning beyond the schema for the required parameter by explaining that object_id is the id returned from the work-detail response (the schema only says '作品ID'). The other three parameters (comment_id, last_buffer, _token) get no additional explanation, so it stops short of a 5.

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?

States a specific verb+resource: the comment list for a 视频号 (WeChat Channels) work. The 'channels_' prefix and '作品评论列表' wording separate it from the many sibling comment tools (weibo_comments, xhs_note_comments, douyin_video_comments), though the description itself does not call out that distinction explicitly.

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?

It does give one useful precondition — object_id must be taken from the id field returned by the work-detail call — which tells the agent this tool depends on a prior lookup. However, there is no guidance on when to use this tool versus the many other comment-listing siblings, nor on exclusions or ordering.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only states the input form. It does not disclose that this is a read-only fetch, what the response contains, whether auth is mandatory, or any rate limits, leaving most behavioral traits unstated.

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?

A single compact sentence with the key input requirement front-loaded in the parenthetical. Nothing is wasted, though the extreme brevity limits how much it can convey.

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?

For a simple 3-parameter, no-output-schema detail fetch, the description plus fully covered schema is largely adequate. However, with no annotations and no mention of return content or auth expectations, it is only minimally complete.

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 coverage is 100%, so the baseline is 3, but the description adds real value by specifying the exact share_url format with a concrete example (https://weixin.qq.com/sph/xxxx), which the schema's terse '分享链接' does not provide.

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?

States a specific resource and action: retrieving details for a WeChat Channels (视频号) video work. This distinguishes it from platform siblings such as bili_video, douyin_video, and yt_video by naming the platform, though it does not explicitly call them out as alternatives.

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?

Usage is only implied: the parenthetical tells the agent a share_url is required, which hints at when the tool applies. There is no explicit when-to-use/when-not guidance and no named alternative among the many sibling video tools.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: not whether the call is read-only, what authentication is required (the that _token exists is only in the schema), whether there are rate limits, or what the response contains. For a bare detail-fetch tool this is a real gap.

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?

It is a single front-loaded phrase with zero filler, which is structurally clean, but it is under-specified rather than genuinely concise — there is simply nothing else in it.

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 annotations, no output schema and no title, the description would need to convey at least the basic read semantics and return shape; it instead provides only a resource label. The fully documented schema partially compensates for the parameter gap, but the description itself is thin for the tool's role.

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%, with seller_id ('商家ID') and _token ('备用鉴权...') fully documented, so the baseline of 3 applies. The description adds no extra meaning about the parameters beyond what the schema already states.

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?

The phrase '1688商家/公司详情' names a specific resource (a 1688 merchant/company) and implies a detail lookup, which distinguishes it from search_1688, item_1688 and reviews_1688 siblings. However, it never explicitly frames the verb or states that it resolves a single seller by ID, so it stops short of full sibling differentiation.

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 its siblings (item_1688, search_1688, ecommerce_shop), nor any stated precondition such as needing a seller ID obtained elsewhere. The agent must infer usage entirely.

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

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

With no annotations, the description carries the full burden, but it only discloses the returned data fields (followers, likes, works count) and does not mention read-only nature, authentication requirements, or rate limits. The schema covers token auth, but the description itself adds limited behavioral context beyond the return content.

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 description is a single, front-loaded phrase with no wasted words, making it highly concise. It could be slightly more structured (e.g., with a verb phrase) but it efficiently communicates the core purpose.

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?

For a simple read-only tool with full schema coverage and no output schema, the description adequately conveys the returned data. However, it is missing usage guidance and sibling differentiation, leaving an agent with gaps when deciding among similar Douyin tools.

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%, so the baseline is 3. The description does not add any parameter-level meaning beyond what the schema already provides (e.g., sec_user_id meaning, token alternatives).

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?

The description clearly identifies the resource (抖音作者主页) and the returned metrics (粉丝/获赞/作品数), making the tool's purpose immediately understandable. However, it lacks an explicit verb and does not distinguish itself from sibling tools like douyin_video or douyin_search, 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.

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

The description provides no guidance on when to use this tool versus alternatives, nor does it state any prerequisites or exclusions. Usage is only implied by the resource name, which is insufficient for a clear routing decision among the many sibling tools.

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

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 and delivers almost none. It does not say whether this is a read-only fetch, whether authentication is required, or what the response contains; the only auth hint lives in the _token schema description, not here.

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?

At four characters it is short, but this is under-specification rather than conciseness: it reads as a restated title with no front-loaded verb, scope, or return information that a caller could act on.

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?

For a simple single-item lookup with no output schema and no annotations, the description should at least state that it returns one product's detail by ID and mention auth expectations. Instead it leaves the agent to guess the return shape and the relationship to sibling product tools.

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% — both product_id and the fallback _token are documented in the schema itself. The description adds no parameter meaning beyond that, 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?

The phrase 抖音商品详情 identifies the resource (Douyin product) and implies a detail-fetch operation, which does distinguish it from siblings like douyin_video, douyin_author, and douyin_search. However, it is a noun phrase with no verb and no statement of scope (single item vs. list), so the purpose is only inferred rather than stated.

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 alternatives such as ecommerce_item or item_1688 for cross-platform product data, nor any stated prerequisites. The agent must infer usage entirely from the platform name in the title.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no rate limits, no pagination behavior, no auth requirement, no note on what the returned video list looks like. It cannot be said to contradict anything, but it adds no behavioral context at all.

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?

It is a single front-loaded phrase with no wasted words, which is good, but at eight characters it is more under-specified than concise. There is nothing to trim and also nothing to work with.

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?

For a 3-parameter search tool with no annotations and no output schema, the agent is left guessing about pagination semantics, result ordering, and the X-FW-Token vs _token auth trade-off that the schema hints at. The description does not fill any of those gaps.

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% (page, keyword, _token are each documented in the schema), so the baseline of 3 applies. The description adds no meaning beyond the schema — it does not clarify keyword syntax, escaping, or the page-zero default.

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?

The phrase '抖音关键词搜索视频' names a specific verb (搜索/search), resource (视频/videos), platform (抖音/Douyin) and the input (关键词/keyword), so the agent knows exactly what it does. It implicitly separates itself from douyin_video and douyin_author by platform and action, but it never names an alternative or draws the boundary explicitly, so it stops short of 5.

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 pick this over tiktok_search, xhs_note_search, or douyin_video, nor any mention of prerequisites. The agent must infer usage purely from the tool name.

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

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

No annotations are provided, so the description carries more burden. It usefully discloses returned content (title, engagement counts, author info, cover/music), which helps because there is no output schema. However, it omits authentication requirements and does not explicitly state read-only behavior, so it only partly covers the behavioral context.

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 description is a single compact, front-loaded phrase with a colon-separated field list and no filler. It is appropriately terse, though not structured enough to warrant a 5.

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?

For a simple video-detail tool with full parameter schema coverage and no output schema, the description gives a useful partial list of returned fields. It still omits usage guidance and authentication context, and the return values are only examples ending in 等, so it is minimally adequate rather than complete.

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%, and the schema already documents aweme_id as the video ID and _token as an alternate auth token. The description adds no additional parameter meaning, 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?

The description names a specific resource, 抖音视频详情, and lists return fields such as 标题/点赞/评论/分享数、作者信息、封面音乐, so an agent can identify it as video-metadata retrieval rather than comments. It does not explicitly distinguish itself from siblings like douyin_video_comments or douyin_search, 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.

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

There is no when-to-use guidance, no alternatives named, and no prerequisites. The label implies retrieving video details, but an agent must infer when to choose this over douyin_video_comments, douyin_search, or douyin_author.

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

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 implies a read-only list operation but gives no details about pagination behavior, authentication requirements, rate limits, or return format.

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 description is a single noun phrase with no structure or front-loaded guidance. While extremely short, it is under-specified rather than concise—it lacks the necessary context for an agent to properly use the tool.

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?

Given the simplicity of the tool and 100% schema coverage, the schema handles parameters adequately. However, with no annotations and no output schema, the description should explain return values or usage context; it does neither, leaving significant gaps.

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%, so all three parameters (page, _token, aweme_id) are already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, making a baseline score of 3 appropriate.

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?

The description '抖音视频评论列表' clearly names the platform (Douyin), the resource (video comments), and the operation (list). It is specific enough to distinguish from siblings like douyin_video or weibo_comments, but it does not explicitly differentiate itself from other comment-list tools within the suite.

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?

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states what the tool is, leaving the agent to infer usage context entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses essentially nothing: no pagination, sorting, result limits, rate limits, or auth behavior (the _token field is only explained in the schema). It also does not clarify what the returned list looks like or how many items come back.

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?

Extremely short and front-loaded, with no filler, which is good. But it is a sentence fragment that omits any actionable instruction, so brevity here reads more as under-specification than disciplined conciseness.

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, no annotations, and a two-parameter tool, the description should explain result shape, limits, and how the required id maps to a product, none of which is covered. It also leaves the phantom platform parameter unresolved.

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%, so the two real parameters (id, _token) are already documented, giving a baseline of 3. But the description introduces 'platform=淘宝 或 京东' as if a platform parameter existed, while the schema has no such field — this actively risks the agent passing an unsupported argument, so it falls below baseline.

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?

States a specific resource (商品评论列表 / product review list) and names the two platforms it covers (淘宝/京东), which distinguishes it from the 1688 review sibling. However, it is a noun phrase rather than a verb+resource statement, and the parenthetical implies a platform selector the schema does not contain.

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?

No indication of when to use this tool versus the many sibling comment tools (reviews_1688, douyin_video_comments, weibo_comments, etc.) or versus ecommerce_item/ecommerce_shop. The agent must infer that 'ecommerce' here means Taobao/JD product reviews only.

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

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing: no auth requirements, no rate limits, no return shape, no indication of whether the call is a safe read. The only auth hint lives in the schema, not the description.

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?

A single short line with the resource front-loaded and no filler. It is efficient, though its brevity comes partly from omitting needed information rather than from disciplined editing.

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?

For a multi-platform e-commerce lookup with no annotations and no output schema, the description should at minimum clarify how the platform is selected and what the result contains. Neither is present, and the phantom platform parameter leaves the calling contract ambiguous.

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 coverage is 100%, so 'id' and '_token' are already documented, giving a baseline of 3. But the description advertises a 'platform' selector that does not exist in the schema, which actively misleads the agent about the call signature and drops this below baseline.

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?

States a recognizable verb+resource ('商品详情' / product details) scoped to Taobao/JD, so the general purpose is inferable. However, it does not differentiate itself from near-siblings like item_1688, douyin_product, or ecommerce_shop, and it references a 'platform' selector that the agent must guess at.

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 the many sibling product/item tools, no prerequisites, and no exclusions. The parenthetical '(platform=淘宝 或 京东)' hints at a choice but never states how the caller exercises it.

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

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

No annotations are provided, so the description carries full behavioral burden. It implies a read-only search but omits auth requirements, rate limits, pagination, and return behavior. Additionally, the platform-specific parameter guidance conflicts with the schema, which only defines a single 'id' parameter.

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 description is a single, front-loaded sentence with no wasted words. The parenthetical parameter note is compact, though its mismatch with the schema reduces its practical value.

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 annotations and no output schema, the description should provide more behavioral and return context. The parameter guidance is inconsistent with the schema, leaving the agent without a clear way to map platform-specific IDs to the single 'id' field.

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 coverage is 100%, so the baseline is 3. However, the description introduces shop_id and seller_id parameters that do not exist in the schema (which only has 'id' and '_token'), creating confusion rather than adding meaningful semantic clarity.

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?

The description states a specific verb (search) and resource (on-sale products in JD/Taobao shops), which distinguishes it from item-level tools like ecommerce_item. It does not explicitly name a sibling tool, 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.

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

It gives platform-specific parameter instructions (JD uses shop_id; Taobao uses seller_id+shop_id), which is useful context. However, it does not explain when to choose this tool over alternatives like ecommerce_item or search_1688, leaving usage implied.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it delivers almost nothing: it does not state that this is a read-only lookup, what the response contains, whether authentication is required (the schema hints at a _token fallback), or any rate-limit/error behavior. Only the implied 'detail retrieval' framing gives any signal.

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?

It is a single front-loaded phrase with zero redundancy, so nothing needs trimming, but the terseness is under-specification rather than genuine conciseness — it conveys far less than an agent needs for an ambiguous platform-scoped tool.

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 annotations, no output schema, and a description that is only a title-like phrase, the definition is thin for a tool that must be distinguished from ~29 platform siblings. An agent can guess the intent from the name but has no support for calling it confidently or interpreting results.

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%: `code` is documented as the post shortcode and `_token` as an alternative auth token with a preferred header alternative. The description adds no parameter meaning at all, so the baseline 3 for fully documented schemas 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?

The description 'Instagram帖子详情' names the resource (an Instagram post) and implies retrieval of its details, which distinguishes it from sibling tools clearly scoped to other platforms (xhs_note, weibo_post, tiktok_video). However, it is a bare noun phrase with no verb and no scope qualifiers (which fields, single vs. bulk), so the purpose is only implied rather than stated.

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 alternatives such as xhs_note, weibo_post, or tw_post, nor any prerequisite (e.g., that a valid shortcode is required) or exclusion. The agent must infer platform routing purely from the tool name.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it only states the input mode (image URL, not file upload). It says nothing about result format, pagination, rate limits, or auth behavior, and the only auth hint lives in the schema's _token field rather than the description.

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?

A single compact sentence with the essential purpose and input front-loaded; no filler. It is arguably too terse, but conciseness itself is not the problem.

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?

For a simple one-required-param search tool with no output schema and no annotations, the description covers purpose and input type adequately. It remains thin on when to prefer it over the sibling search_1688 and on what the call returns.

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%, so the baseline is 3. The description adds marginal value by specifying the URL should point to a product image (商品图片URL) rather than an arbitrary image, but that is the only semantic enrichment over the schema.

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?

States a specific verb+resource: image-based search (以图搜图) on 1688, and clarifies the input is a product image URL. It implicitly separates the tool from text-based search_1688 by naming the search modality, though it does not explicitly reference the sibling.

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?

The phrase 以图搜图 implies you use this when you have an image rather than a keyword, so the usage condition is inferable. There is no explicit when-to-use guidance, prerequisite, or named alternative such as search_1688 for keyword queries.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about authentication (the _token param hints at it), rate limits, or return shape. For a details-fetch tool with zero annotation coverage, this is a serious gap.

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 description is a single terse phrase, which is short but reflects under-specification rather than effective conciseness. There is no structure to front-load because nothing meaningful is said.

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 annotations, no output schema, and a bare two-word description, an agent lacks everything needed to call this correctly beyond the schema's parameter names. Nothing about scope, auth handling, or result content is conveyed.

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%, so both item_id and _token are already documented in the schema. The description adds no meaning beyond the schema, which is the baseline 3 when the schema does all the work.

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?

The phrase '1688商品详情' names the resource (1688 product) and implies a read of its details, which is more than a tautology. However, it offers no differentiation from siblings like company_1688, reviews_1688, img_search_1688, or search_1688, so an agent cannot tell from the text alone why this tool rather than those.

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 statement of when to use this tool versus alternatives, nor any prerequisite or exclusion. Usage is only weakly implied by the word '详情' (detail), which the agent must infer.

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

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

No annotations are provided, so the description carries the full behavioral burden. '详情' weakly implies a read-only lookup, but there is no disclosure of auth requirements, rate limits, whether the call is safe/idempotent, or what the returned payload contains. For a zero-annotation tool this is a substantial gap.

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?

Four characters, no padding and fully front-loaded, which is efficient. But at this length the brevity reflects under-specification rather than disciplined conciseness, so it does not earn a top score.

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?

The tool is simple (2 params, no nesting, no output schema, no annotations), so a short description could suffice — but the agent still lacks any statement of what the response contains or how it differs from the ~8 sibling video-detail tools. Barely adequate for the complexity.

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% — both photo_id ('视频ID') and the fallback _token are documented in the schema itself, including the X-FW-Token alternative. The description adds no parameter meaning beyond that, so the baseline of 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?

The description names the resource (快手视频) and implies a retrieval ('详情'), so an agent knows this fetches Kuaishou video details. However it never states the verb explicitly nor distinguishes itself from the many sibling *_video tools (douyin_video, tiktok_video, yt_video, bili_video) beyond the implicit platform prefix in the tool name. Purpose is identifiable but generic.

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?

No guidance on when to use this tool versus the other platform video tools, no prerequisites, no mention that a video ID is required. The agent must infer everything from the name and schema.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only comment listing, but says nothing about pagination behavior, rate limits, auth requirements (only the schema mentions the _token), or what is returned. For a bare schema with zero annotation coverage this is a significant gap.

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?

A single short parenthetical that front-loads the resource and the required inputs; nothing is wasted. It is terse rather than padded, though brevity here borders on under-specification.

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?

For a 4-parameter tool with no annotations and no output schema, the description leaves out auth expectations, pagination semantics, and return shape. Only the bare minimum — what resource and which required params — is conveyed.

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%, so the schema already documents item_id, seller_nick, page (with default 1), and _token. The description merely restates that item_id and seller_nick are required, adding no meaning beyond the schema. 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?

The description names a specific verb+resource pair — 1688 product reviews — which is clearly distinguishable from siblings like item_1688, search_1688, or the generic ecommerce_comments. It is clear but does nothing to differentiate itself from ecommerce_comments beyond the platform name.

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?

It states the two required parameters but gives no guidance on when to choose this tool over ecommerce_comments or other review sources, and no prerequisites or context conditions. Usage must be inferred entirely from the tool name.

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

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

With no annotations, the description carries the full behavioral burden but only states the operation. It omits read-only/write nature, authentication behavior, pagination behavior, rate limits, and result format.

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 phrase is very short and front-loaded with the core purpose. However, it reads as a label rather than a structured description, and its brevity leaves important selection context unstated.

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?

Given no annotations, no output schema, and many similar siblings, the description is too thin. It does not explain when to choose this tool over img_search_1688 or item_1688, nor does it cover behavior an agent needs to invoke it confidently.

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%, so all three parameters are already documented. The description only echoes the keyword parameter and adds no further syntax, defaults, or constraints beyond the schema.

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?

States a specific action (搜索商品) on a specific resource (1688) with a keyword qualifier. It is clear, but does not explicitly differentiate itself from siblings such as img_search_1688 or item_1688.

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?

Provides no when-to-use guidance, no alternatives, and no conditions. An agent must infer that this is the keyword-based product search rather than an image search, item detail, or review tool.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about return format, rate limits, pagination, or auth beyond what the schema already states in the _token field. A read-only search's behavior is entirely undocumented.

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 description is a single five-character label. It is not verbose, but it is under-specified rather than concise — every sentence that would earn its place is absent.

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?

For a search tool with no output schema, the description should indicate what is returned (videos, users, posts) and how results are scoped. Nothing beyond the name is given, so an agent cannot predict the response shape from the definition.

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%, so both parameters (keyword and _token with its auth fallback note) are already documented in the schema. The description adds no syntax, format, or filtering semantics 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.

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

The phrase 'TikTok关键词搜索' names a verb (搜索/search) and resource (TikTok keyword), so the agent knows it queries TikTok by keyword. However it is a bare label with no scope detail and does not differentiate itself from the sibling tiktok_video tool, leaving the agent to guess what object type is returned.

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 when-to-use guidance, no mention of alternatives such as tiktok_video, and no prerequisites or exclusions. Usage is only implied by the name.

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

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, yet it says nothing about whether this is a read operation, what authentication is required (the _token param hints at auth but the description is silent), rate limits, or what is returned. It adds no behavioral context whatsoever.

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?

It is extremely short, but this is under-specification rather than conciseness. A single noun phrase with no verb and no front-loaded purpose statement does not earn its place as a description.

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?

For a two-parameter tool with no annotations and no output schema, the description should explain what 'details' are returned and any auth requirements. The bare phrase leaves the agent without anything needed to invoke the tool correctly.

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%: item_id ('视频ID') and the fallback _token parameter are both documented in the schema. The description adds nothing 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.

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

The phrase 'TikTok视频详情' identifies the resource (a TikTok video) and implies a detail-retrieval purpose, and the platform prefix does differentiate it from siblings like douyin_video, ks_video and yt_video. But there is no verb and no statement of scope, so the purpose is only vaguely conveyed.

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 tiktok_search or any other sibling. The platform name implicitly scopes it to TikTok content, but no conditions, prerequisites, or alternatives are stated.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure, yet it says nothing about read-only vs. mutating behavior, authentication requirements, rate limits, or what happens on an invalid tweet_id. A single noun phrase conveys no behavioral context at all.

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 description is extremely short with zero wasted words, so it is concise by default. But it is a fragment rather than a front-loaded sentence, and its brevity stems from under-specification rather than disciplined editing.

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?

For a tool with no annotations, no output schema, and a required identifier parameter, the agent needs to know what is returned, whether auth is required, and what errors look like. The description supplies none of this, leaving it incomplete for correct invocation.

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%, so both parameters (tweet_id and the optional _token fallback auth) are already documented in the schema, including the recommended HTTP header alternative. The description adds nothing beyond that, which is the expected baseline when the schema does the heavy lifting.

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?

The phrase 'Twitter/X推文详情' identifies the platform (Twitter/X) and the resource (a tweet's details), which does disambiguate the cryptic name 'tw_post' among non-Twitter siblings. However, it is a bare noun phrase with no verb and only the vague word 'details', so it does not state what operation is performed or what the details contain.

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, no prerequisites, and no mention of alternatives (e.g. comment-fetching siblings like weibo_comments or ig_post). The agent must infer usage entirely from the name.

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

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

With no annotations provided, the description carries the full behavioral burden, yet it discloses nothing about pagination semantics (despite a max_id cursor), rate limits, authentication requirements, or the shape of the result. Only the vague hint from the _token parameter suggests auth is handled, which is not stated in the description itself.

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?

It is a single short phrase with zero filler, but the brevity comes at the cost of substance rather than being earned concision — there is nothing front-loaded because there is almost nothing to front-load.

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?

For a tool with four parameters, no output schema, and zero annotations, a five-character description is inadequate; an agent cannot determine return format, pagination behavior, or auth handling from it.

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%, so all four parameters (post_id, count, max_id, _token) are already documented in the schema, establishing a baseline of 3. The description adds no parameter-level meaning beyond what the schema already supplies.

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?

The phrase '微博帖子评论列表' identifies the resource (comments on a Weibo post) and implies a list/retrieval operation, which distinguishes it from weibo_post. However it is a bare noun phrase with no explicit verb or scope, leaving the agent to infer that it returns comments rather than, say, metadata about them.

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 alternatives such as weibo_post or the other *_comments siblings, and no mention of prerequisites like needing a valid post_id or authentication token. Usage is only weakly implied by the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only retrieval ('详情'), but does not disclose authentication needs, rate limits, pagination, or return behavior beyond the schema's optional token parameter.

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 description is a four-character noun phrase. It has no wasted words, but it is under-specified rather than usefully concise, and it offers no structure for an agent to follow.

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?

For a retrieval tool with no annotations and no output schema, the description is too thin. It does not explain what details are returned, whether the operation is read-only, or how it relates to sibling tools, leaving important context absent.

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%, so the schema already documents both post_id and _token. The description adds no additional parameter meaning beyond the schema, making the baseline 3 appropriate.

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?

The phrase '微博帖子详情' identifies the resource (Weibo post) and that it returns details, so the agent can distinguish it from weibo_comments. However, it is still a vague noun phrase without a specific verb, scope, or explanation of what '详情' includes.

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 alternatives such as weibo_comments or other platform post tools. Usage is only implied by the tool name and description.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about authentication requirements, rate limits, or what the response contains. '详情' faintly implies a read-only fetch, but that is the only behavioral signal.

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?

At six characters it is certainly terse and front-loaded, but the brevity is under-specification rather than efficient conciseness — no sentence carries actionable information.

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 annotations and no output schema, the description should explain the read behavior and expected return shape, but it does neither. The schema covers parameters and the auth alternative, leaving a substantial gap the description never fills.

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%, with both note_id and the _token fallback auth documented in the schema, so the baseline is 3. The description adds no additional meaning about either parameter.

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?

The phrase '小红书笔记详情' identifies the resource (an Xiaohongshu note) and implies retrieval of its details, but uses a noun phrase instead of a verb, so the action is only inferred. It is loosely distinguished from siblings like xhs_note_search and xhs_note_comments, which is acceptable but not explicit.

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 statement of when to use this tool versus xhs_note_search, xhs_note_comments, or xhs_user. The only inference available is that a single note_id is required, which is weak guidance at best.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about pagination behavior (despite a cursor parameter), the auth requirement for the _token fallback, or rate limits. It only weakly implies a read operation by virtue of being a 'list'.

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?

It is a single short phrase with zero waste, but it is under-specified rather than concise—there is essentially no content to front-load. Size is appropriate only in the sense that nothing is padded.

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?

For a 4-parameter tool with no annotations and no output schema, a bare noun phrase is insufficient: nothing explains the cursor-based paging model, the auth path, or the sort strategies available. The structured fields cannot compensate because the description adds no coverage.

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% and all four parameters are documented in the schema, so the baseline of 3 applies. The description adds no syntax, format, or default details beyond what the schema already provides.

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?

The description is a direct translation of the tool name (xhs_note_comments → 'Xiaohongshu note comments list'), restating the name rather than stating what the tool does. It conveys the resource (note comments) but no verb or scope, and offers no differentiation from siblings like weibo_comments or douyin_video_comments beyond the platform name already present in the tool name.

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 when-to-use or when-not-to-use guidance, and no mention of the alternative xhs_note tool for the note itself versus its comments. The agent must infer applicability entirely from the tool name.

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

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

With no annotations provided, the description carries full behavioral burden but discloses nothing: no read-only indication, auth requirements (_token or header), rating limits, pagination behavior, or result format. It leaves the agent without essential behavioral context.

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 one-phrase description is front-loaded and waste-free, but for a six-parameter tool with no annotations or output schema it is under-specified rather than appropriately concise. It essentially restates the tool name without adding structure or useful detail.

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?

Given six parameters, no annotations, and no output schema, the description is incomplete. It omits return structure, pagination behavior, sort/time/type semantics, and authentication method, leaving an agent without enough context for reliable invocation.

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%, so all six parameters are already documented in the schema. The description adds no extra semantic detail about keyword handling, page, sort_type, note_time, note_type, or _token, so 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?

States a specific verb (搜索) and resource (小红书笔记) with the keyword qualifier, so an agent can identify it as a keyword-based note search on Xiaohongshu. It does not distinguish itself from siblings like xhs_note or xhs_user, 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.

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

No guidance on when to use this tool versus alternatives such as xhs_note, douyin_search, or xhs_user, and no prerequisites or exclusions are mentioned. Search intent is implied only by the phrase itself.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it provides none. Nothing is said about whether this is a read or write, auth requirements beyond the stray _token field, rate limits, or what data is returned.

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 single phrase is short but this is under-specification rather than conciseness; there is no front-loaded purpose or structure to speak of. Nothing about it earns extra credit.

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?

For a tool with no annotations, no output schema, and a bare two-word description, an agent has almost nothing to decide whether and how to call it. The definition is essentially incomplete.

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%, so both _token and user_id are already documented in the schema, giving a baseline of 3. The description adds no information beyond the schema, so it neither helps nor hurts.

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?

The description '小红书用户信息' (Xiaohongshu user info) is essentially a restatement of the tool name xhs_user; it names a resource but supplies no verb or scope, and it does not distinguish this from sibling tools like xhs_note or xhs_note_comments.

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 the many siblings (douyin_author, weibo_post, etc.). No prerequisites, alternatives, or exclusions are stated; the agent must infer usage entirely from the name.

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

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, and it discloses nothing: not whether this is a read-only fetch, what happens with an invalid ID, whether authentication is required (the _token parameter hints it is), or whether results are cached or rate-limited.

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?

It is a single short phrase with zero waste, but it is under-specified rather than concise; there is no front-loaded verb phrase or scope statement to earn the brevity.

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?

For a two-parameter tool with a fully documented schema and no output schema, the essentials are technically present, but the description omits every behavioral fact an agent needs: the required auth, what the response contains, and any failure or rate-limit behavior.

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%, so both parameters are already documented in the schema, including the _token auth parameter and its header alternative. The description adds no meaning 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.

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

The phrase names a resource (YouTube video) and an implicit verb (fetch details), and the platform prefix distinguishes it from the many sibling video tools (bili_video, douyin_video, tiktok_video). However, it never states what 'details' actually comprises or what operation is performed, so it is vague beyond platform scoping.

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 the 29 siblings, no prerequisites, and no exclusions. The description offers nothing an agent can use to route between yt_video and, say, channels_video or tiktok_video beyond guessing from the name.

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

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

No annotations are supplied, so the description carries the full disclosure burden, yet it says nothing about pagination behavior, required authentication (the _token param hints at this but the description is silent), or rate limits. 'List' weakly implies a safe read, but for a tool with zero annotation coverage this is a substantial gap.

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 description is a single front-loaded fragment with no wasted words, but its extreme brevity reflects under-specification rather than disciplined conciseness. It is neither misleading nor bloated.

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?

For a 4-parameter tool with no annotations and no output schema, the description should convey scope, auth, and pagination expectations; it conveys none of these. The tool is left almost entirely documented by its name and schema alone.

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%, so every parameter (limit, offset, _token, answer_id) is already documented in the schema, including defaults. The description adds no parameter meaning beyond what the schema provides, so the baseline of 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?

The phrase '知乎回答评论列表' identifies the resource (comments on a Zhihu answer) and implies a list operation, so the agent can grasp the general intent. However, it is a bare noun phrase with no explicit verb and no differentiation from the many other *_comments siblings (weibo_comments, xhs_note_comments, douyin_video_comments).

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 the numerous sibling comment-listing tools, nor any prerequisite or exclusion stated. The agent must infer usage entirely from the name.

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

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 only says '详情' and does not mention read-only nature, authentication needs (despite _token in schema), rate limits, or returned fields. Minimal implied retrieval behavior earns a 2.

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 description is a single front-loaded phrase with zero waste and is appropriately sized for a simple lookup tool. Structure is minimal but effective, keeping it from a full 5.

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?

For a simple detail lookup with 100% schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it omits any mention of return values or behavioral context, leaving clear gaps.

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%, with both answer_id and _token documented in the input schema. The description adds no parameter meaning beyond the schema, so the baseline score of 3 is appropriate.

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?

States the resource '知乎回答/帖子详情' (Zhihu answer/post details), which clearly implies retrieving post details and distinguishes from sibling zhihu_comments by focusing on posts rather than comments. It lacks an explicit verb and does not name alternatives, 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.

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

No when-to-use conditions, prerequisites, or alternatives are provided. The description does not tell an agent when to choose this tool over zhihu_comments or other Zhihu endpoints; usage is only implied by the tool name.

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