SocialDataX 百度贴吧 MCP

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: it requires an exact forum name and points to a fallback tool when the name is uncertain, which prevents a common failure mode. It does not cover failure behavior for a wrong-but-plausible name or any rate-limit/auth considerations, so it falls short of a 5.

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?

Front-loaded purpose in sentence one, followed by two tight conditional sentences that each route the agent to a specific sibling. No filler, no repetition of schema content.

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?

An output schema exists, so return-field detail is not required, and annotations already carry the read-only/open-world profile. What remains necessary for correct invocation — exact-name input plus fallback routing for name discovery and post browsing — is fully present.

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 single forum_name parameter already carries rich constraints (no trailing '吧', no URL or numeric ID, no URL encoding). The description only restates the 'exact name' requirement without adding syntax or format detail beyond the schema, 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 first sentence names a specific verb (获取) plus resource (贴吧) and enumerates exactly what is retrieved: 简介、标语、建吧日期、关注人数、帖子统计、友情链接贴吧. It also distinguishes itself from two named siblings (baidu_tieba_search_posts_in_forum, baidu_tieba_get_forum_posts), so an agent can separate it from the adjacent tools without opening any schema.

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?

Explicit conditional routing: if the exact forum name is unknown, call baidu_tieba_search_suggestions first to obtain forum_name; for keyword-based post lookup use baidu_tieba_search_posts_in_forum; for keyword-free browsing use baidu_tieba_get_forum_posts. Both the precondition (accurate name) and the 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?

Annotations only declare readOnly and openWorld, so the description adds real behavioral value: featured-only mode is restricted to default order with no category filtering, and summaries/media may be incomplete in returned posts. These caveats are not recoverable from the annotations and directly affect how the agent interprets results.

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?

Front-loaded first sentence gives the core capability, second paragraph handles exclusions and caveats. Every sentence carries routing or constraint information with no filler.

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 annotations covering read-only safety, a full output schema covering return shape, and 100% schema description coverage, the only remaining burden is routing and caveats, both of which the description supplies. Nothing needed to call this correctly is missing.

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% and the property descriptions already explain forum_name format, sort_type enum behavior, page_token continuation semantics, and the featured_only/default coupling. The description largely restates these constraints, so the 3 baseline for high schema coverage 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: browse ordinary and pinned posts by exact forum name, without keywords, with pagination and sorting. It also names two siblings and the exact boundary that separates them (keyword search vs. forum detail), so the agent can disambiguate without opening schemas.

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?

Explicitly routes the agent: keyword-based in-forum lookup goes to baidu_tieba_search_posts_in_forum, and forum bio/statistics goes to baidu_tieba_get_forum_detail. It also gives a local usage rule (featured-only supports default order only, no category option), which is exactly the kind of when-to-use guidance that prevents wrong calls.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new traits beyond them: pagination support and the notable absence of sorting, which affects how an agent should interpret results.

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?

Two short sentences, purpose front-loaded, followed by the disambiguation rule. No filler; every clause earns its place.

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 an output schema present and 100% param coverage, the description need only convey scope, pagination, and routing — all of which it does. It is complete enough to call correctly, missing only minor operational detail like page size limits.

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 thread_id, comment_id provenance, and page_token usage in detail. The description essentially restates the comment_id sourcing rule, so it adds little beyond the schema — baseline 3.

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 (读取楼中楼回复) scoped by thread ID and first-level comment ID, which is exactly what distinguishes it from the sibling baidu_tieba_get_post_comments_by_thread_id. It also explicitly points to the comment-list tool for first-level comments, so an agent can route without opening a schema.

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?

Explicitly states when NOT to use this tool ("读取帖子一级评论使用评论列表工具") and how to obtain the required comment_id from the first-level comment list. Clear context and an explicit alternative, though it doesn't cover the by_url retrieval variants among siblings.

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?

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower. The description adds meaningful scope context the annotations cannot convey: it is ID-based, returns only first-level comments, and supports sorting/pagination – all relevant to interpreting results.

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, tightly packed sentence that front-loads the resource and ID scoping, then appends capabilities and the key exclusion. No filler.

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?

An output schema exists, so return-shape explanation is unnecessary. For a read-only, ID-scoped list endpoint with 100% schema coverage and clear exclusions, the description provides everything an agent needs to select and invoke it 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%, so all three parameters are already documented in detail (enum values for sort_type, token handling for page_token, ID pattern for thread_id). The description only echoes 'sorting and pagination' generically and adds nothing 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?

States a specific verb+resource (读取百度贴吧一级评论) scoped to a numeric thread ID, and explicitly narrows the result set with '不包含楼中楼回复'. This cleanly distinguishes it from the two nearest siblings: get_post_comment_replies (nested replies) and get_post_comments_by_url (URL-based lookup).

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 exclusion of 楼中楼 replies clearly signals when an agent should instead reach for get_post_comment_replies, and '按主题帖数字 ID' signals the URL-based variant is different. However, it never names the alternative tools explicitly, leaving a small inference step.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds genuinely useful behavioral scope by stating the result contains only first-level comments and that sorting/pagination are supported. It does not mention rate limits, auth requirements, or what happens on an invalid/private thread.

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?

One front-loaded sentence that names the input (主题帖链接), the output (一级评论), and the key limitation (不包含楼中楼回复), with no filler or redundancy.

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 an output schema present and 100% parameter coverage, the description need not explain return values or param formats; the main residual gap is not distinguishing this tool from the near-identical _by_thread_id sibling, which an agent selecting among 18 siblings would benefit from.

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% — url, sort_type, and page_token all carry detailed inline descriptions covering format, enum meaning, and pagination-token reuse rules. The description's mention of sorting and pagination merely restates what the schema already documents, 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?

States a specific verb and resource (读取一级评论) scoped by 百度贴吧主题帖链接, and explicitly excludes 楼中楼回复, which is exactly what separates it from the sibling baidu_tieba_get_post_comment_replies. An agent can distinguish it from the replies tool without opening a schema.

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 '不包含楼中楼回复' clause implies that nested replies require the sibling tool, giving implicit routing, but neither that sibling nor baidu_tieba_get_post_comments_by_thread_id is named, and no condition for choosing URL-based vs thread-ID-based retrieval is given. Usage is implied rather than 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds a meaningful scope caveat: the post detail excludes the full reply list. That goes beyond the annotations, though it says nothing about pagination, auth, or rate limits.

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 action and keying method front-loaded and the scope limitation tacked on at the end; nothing is redundant or 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?

With one fully documented parameter, an output schema, and read-only/open-world annotations, the description covers what an agent needs to select and call the tool. The only gap is the absence of explicit routing to the reply/comment siblings.

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 single required parameter is already fully documented in the schema, including the numeric pattern and the warning not to pass a post link. The description only restates '数字 ID', adding no new semantic detail, which matches the baseline 3.

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 (读取/read), resource (百度贴吧主题帖详情), and the keying mechanism (数字 ID), which separates it from the URL-keyed sibling baidu_tieba_get_post_detail_by_url. It also bounds scope with '不包含完整回复列表', distinguishing it from the comment/reply tools.

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 closing clause implies replies must be fetched with the separate comment/reply tools, but no sibling is named and there is no explicit guidance on choosing the ID variant over the URL variant. Usage is inferable but not spelled out.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a genuine scope boundary ('不包含完整回复列表'), but does not say what the detail payload actually contains or how to get the replies, leaving a gap for an open-world read tool.

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 no waste, and the scope exclusion is appended where it reads naturally. Very terse but every clause carries 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Combined with the stated scope exclusion, an agent has enough to call this correctly; only the missing routing hint to the thread_id sibling keeps it from a 5.

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 spells out '完整链接, 支持 /p/数字ID/, 不要传纯 ID', which is richer than anything in the description. Baseline 3 is appropriate since the description adds no parameter meaning.

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 (读取详情 / read thread detail) plus the input medium (链接/URL), which distinguishes it from the thread_id sibling. However, it never explicitly names that alternative, so the differentiation relies on the reader noticing the '链接' qualifier.

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?

Use is implied: call this when you hold a full thread URL. There is no explicit when-to-use statement and no mention of the obvious sibling baidu_tieba_get_post_detail_by_thread_id or when the thread_id variant would be preferred.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds the pagination behavior and the failure mode (未提供列表时返回错误), which annotations do not convey. It stops short of describing rate limits or the next_page_token lifecycle in behavioral terms.

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?

Three front-loaded sentences, each doing distinct work: capability + return fields, sibling routing, and scope/exclusion plus error behavior. No redundancy with the name or schema.

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 an output schema present, return values need not be re-explained, and the description still covers the error path, pagination, scope exclusions, and the alternative tool. Nothing needed to invoke it correctly is missing.

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 page_token and profile_url are already fully documented in the schema (including the accepted URL form and token reuse rules). The description only echoes that pagination is supported, adding no syntax 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?

States a specific verb (读取) and resource (用户公开可读取的关注贴吧列表) plus the entry-point constraint (按主页链接), and explicitly names the sibling used when only a numeric user ID exists. An agent can distinguish it from baidu_tieba_get_user_followed_forums_by_user_id without opening either schema.

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?

Gives an explicit routing rule (profile_url 时优先使用本工具, 数字用户 ID 时使用…by_user_id) and an explicit exclusion (不查询关注的用户或用户发帖). The error condition for a missing list is also stated, so when-not-to-expect-results is covered.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds pagination support, the returned field set, and an explicit error condition, which is meaningful behavioral context beyond the annotations, though it omits rate-limit or result-cap behavior.

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?

Three tightly packed sentences: purpose front-loaded, then alternative routing, then exclusions. No redundant or filler text; each clause carries distinct 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 an output schema present, return values need not be enumerated, but the description does so anyway and also covers pagination and the empty-list error case. Combined with the annotations, an agent has everything needed to call this 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%, so both parameters (user_id, page_token) are fully documented in the schema, including the portrait/tieba_uid disambiguation and the token-reuse warning. The description adds only that pagination is supported, so the baseline 3 applies rather than a higher score.

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 and resource ('读取...关注贴吧列表' = read the user's followed-forums list) scoped to a numeric user ID, and it names the sibling it is not — the by_profile_url variant. An agent can distinguish this from baidu_tieba_get_user_followed_forums_by_profile_url without opening either schema.

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 explicitly routes the agent: when a profile_url already exists, prefer baidu_tieba_get_user_followed_forums_by_profile_url. It also states what it does not do (followed users, user posts) and the failure condition (error when no list is provided), leaving essentially nothing to inference.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context beyond that: the exact set of returned profile fields and the negative disclosure that post/reply lists are not returned. It does not mention auth requirements or rate limits, so it is strong but not exhaustive.

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

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

Three compact sentences with the core verb and returned fields front-loaded, followed by routing guidance. Dense but every sentence carries routing or scope value; nothing is redundant padding.

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 an output schema present, the description need not explain return values, and annotations cover safety. Along with the routing rules and URL sourcing, an agent has everything needed to call it correctly; only minor operational details (auth, limits) are 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% and the schema itself documents the expected URL form and rejects numeric IDs, nicknames, and post links. The description goes further by telling the agent where to obtain a valid profile_url (search, post detail, or comment author fields), adding source guidance 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 verb (读取) and resource (百度贴吧用户主页资料) and enumerates exactly which fields are returned (资料、签名、粉丝数、关注数、累计获赞、吧龄、IP 属地). It explicitly contrasts itself with baidu_tieba_get_user_info_by_user_id, so an agent can distinguish it from the sibling without opening either schema.

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?

Gives explicit when-to-use ('已有 profile_url 时优先使用本工具'), where the URL can be sourced from (搜索、帖子详情或评论作者的 profile_url 字段), and names the alternative plus its triggering condition (仅有数字用户 ID 时使用 by_user_id). It also states a scope exclusion (不返回发帖或回复列表).

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and network profile is known. The description adds only that the result includes homepage statistics plus the ID-type precondition; it does not mention rate limits, auth, or failure modes for a nonexistent ID. Adequate but thin against an already-covered annotation set.

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 that front-loads the positive case (numeric ID present) before the routing rule to the sibling. No filler, no repetition of the tool name's obvious meaning.

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 an output schema present, return values need no explanation; with annotations covering safety, behavior is covered. The description supplies exactly the two things structured data cannot: the ID-type precondition and the sibling routing rule.

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 single parameter is fully documented there, including the regex pattern and the explicit warning that portrait/tieba_uid are not valid. The description only restates the 'numeric ID' precondition, adding nothing the schema lacks. 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+resource ('read user profile and homepage stats') and explicitly names the sibling it is not, distinguishing it from baidu_tieba_get_user_info_by_profile_url. An agent can select it without opening either schema.

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?

Gives an explicit when: only when you hold the numeric user ID. Gives an explicit alternative: use baidu_tieba_get_user_info_by_profile_url when a profile_url is available. This is textbook when/when-not/alternative guidance.

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?

Annotations only cover readOnly/openWorld, but the description adds genuine behavioral context beyond them: pagination is supported, replies are not included, no sorting is offered, lists and media are not guaranteed complete, and an empty page token signals the end of the readable list. These caveats materially affect how an agent should interpret results.

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?

Three short lines, each front-loaded with purpose, then routing, then caveats. No sentence is redundant against the others or against the schema.

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 a full output schema, 100% parameter coverage, and annotations already declaring the safety profile, the description covers what remains: routing between siblings and the incompleteness/termination semantics of the result set. Nothing an agent needs to call this correctly is missing.

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 page_token and profile_url are already fully documented in the schema (format, first-call-empty rule, token reuse constraints). The description reinforces pagination but adds no new syntax or format detail, 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?

States a specific verb and resource (按主页链接读取该用户发布的主题帖) plus explicit scope boundaries: excludes reply activity and provides no sorting. This cleanly distinguishes it from the by_user_id sibling and from the comment/post-detail tools in the sibling list.

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?

Explicitly routes the agent: prefer this tool when profile_url is available, use baidu_tieba_get_user_posts_by_user_id when only a numeric user ID exists. The condition that selects the alternative is named outright, leaving nothing to inference.

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?

Annotations supply the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower, and the description still adds real context: no reply activity, no sorting support, and an explicit caveat that lists and media are not guaranteed complete. The empty-token end-of-list semantics are useful, though result-shape details are left to the output schema.

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?

Two dense sentences: purpose and scope first, then the sibling alternative and the completeness/end-of-list caveats. No filler, and the most decision-relevant routing information is front-loaded.

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?

Output schema exists, so return formatting need not be described. Combined with the pagination termination rule, the completeness caveat, and the explicit alternative tool, the description is sufficient for an agent to invoke this 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% and both parameters are richly documented there (the user_id pattern/portrait exclusion and the page_token carry-over rules). The description only restates 'by numeric user ID' and 'supports pagination,' adding essentially no parameter meaning beyond the schema, 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?

States a specific verb+resource (read this user's published theme posts by numeric user ID) and immediately bounds scope: pagination supported, replies excluded, no sorting. It also distinguishes itself from the closest sibling by naming baidu_tieba_get_user_posts_by_profile_url, so an agent can pick between them without opening either schema.

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?

Explicit routing rule: prefer baidu_tieba_get_user_posts_by_profile_url when a homepage link is already available. It also states what is out of scope (reply activity, sorting) and how to recognize list termination via an empty token, leaving little to inference.

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?

Annotations only declare readOnlyHint/openWorldHint; the description adds real behavioral context — result scope excludes forums/users/topics/suggestions, ordering is preserved, and media fields come only from search results and may be incomplete (so media counts cannot be trusted). No mention of auth, rate limits, or failure modes beyond the empty-page case, so it stops just short of 5.

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 short sentences, each carrying a distinct fact (purpose, exclusions/routing, pagination edge case, media caveat). The core purpose is front-loaded in the first sentence and nothing is redundant.

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?

An output schema exists so return fields need no explanation, yet the description still covers the higher-value gaps: which result categories are absent, how pagination terminates, and the unreliability of media data. An agent has everything needed to call it and interpret the response.

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 both keyword and page_token are already documented with examples and constraints. The description reinforces the page_token continuation semantics but adds no syntax or format detail beyond the schema, so baseline 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 a specific verb+resource+scope: "按关键词获取百度贴吧综合搜索中的帖子" with the explicit qualifiers that order is preserved and pagination is supported. It also names what it does NOT cover (吧、用户、话题、搜索建议), which lets an agent separate it from the other search siblings without opening the schema.

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?

Routes the agent explicitly: use 帖子搜索 when latest/earliest/relevant sorting is needed, and use the detail tool when a post link or ID is given. It also states the pagination continuation rule (empty page still judged by next_page_token), which is exactly the when-to-use guidance an agent needs.

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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely non-obvious context: images/videos only originate from search results and may be incomplete, and it clarifies pagination-token continuity requirements. Not rich enough on rate/coverage limits for a 5.

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?

Front-loads the core action and packs the routing rules plus the data-completeness caveat into a compact block with no filler. Dense but every clause carries routing or caveat 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?

An output schema exists so return values need no explanation, and the description covers purpose, routing, pagination handling, and a result-completeness caveat. Adequate for a 3-parameter search tool with full schema 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%, so the schema already documents keyword, sort_type, and page_token semantics. The description only restates that sorting and pagination are supported, adding no syntax or format detail 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?

States a specific verb and resource (search Baidu Tieba public posts) qualified by keyword, and explicitly distinguishes itself from the general-search, in-forum-search, and detail-link siblings. An agent can route to it without opening the schema.

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?

Gives explicit routing rules: use general search when post ordering matters, the detail tool for specific post links, and baidu_tieba_search_posts_in_forum when the scope is a specific forum. When-to-use and alternatives are both named.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior: it does not cover comments, and it returns summaries with potentially incomplete image/video data, setting expectations about result completeness.

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?

Two tightly written sentences: the core action and scope come first, the alternative-search routing and return caveat follow. No filler.

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 an output schema present, return values need not be explained, and the description still adds a useful completeness caveat. Combined with full schema coverage and annotations, an agent has everything needed to invoke this 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 coverage is 100% and each parameter is well documented (enum values, page token handling, forum name format), so the schema does the heavy lifting. The description only alludes to sorting and pagination at a high level, adding no syntax or format detail 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 verb (search) and resource (topic threads within a forum) qualified by the exact inputs (forum name + keyword), plus scope constraints (supports sorting/pagination, does not search comments). An agent can distinguish this from the general post search without opening the schema.

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?

Explicitly says to use the site-wide post search when not restricting to a forum, and clarifies that comments are out of scope. The alternative is described by function rather than exact sibling name, so the routing is clear but not maximally precise.

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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds meaningful behavior beyond that: no pagination support, and that items and forums are two independent result groups not guaranteed to correspond one-to-one — non-obvious output behavior an agent needs to reason correctly.

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?

Two densely packed sentences, front-loading what the tool does and what it does not, followed by output-group and routing notes. Efficient with no filler, though the second sentence carries several distinct ideas.

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?

Output schema exists so return values needn't be explained, and the description still flags the important structural caveat about the two result groups. Purpose, exclusions, limitations, and follow-up routing are all present for a one-parameter read tool.

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 single keyword parameter is fully documented in the schema (forum-name keyword/prefix, with explicit anti-patterns). The description adds no syntax or format detail beyond the schema, 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?

States a specific verb and resource: fetch forum-name autocomplete suggestions from the Tieba search box. It explicitly disambiguates from siblings by stating it does NOT search posts or users, so an agent can distinguish it from baidu_tieba_search_posts without opening any schema.

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?

Gives clear scope and two exclusions (no posts/users, no pagination), plus explicit next-step routing to baidu_tieba_get_forum_detail and baidu_tieba_search_posts_in_forum using the returned forum_name. It does not explicitly contrast against baidu_tieba_search_general for actual searching, so it stops short of full when/when-not guidance.

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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavioral context beyond that: results are a single page with no pagination, and profile_url is a usable handle for downstream tools. It stops short of describing matching behavior or result volume limits.

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?

Two sentences, front-loaded with the core purpose followed by the downstream-usage note and the no-pagination constraint. Nothing is redundant, though the second sentence could be marginally tighter.

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?

An output schema exists, so return-value explanation is not required, and the description correctly focuses on the non-pagination constraint and the profile_url handoff. Given a single-parameter read-only tool, this is essentially complete, with only matching semantics left implicit.

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 single keyword parameter is already fully documented in the schema, including the negative cases (no profile links, numeric IDs, or pagination tokens). The description adds no parameter-level detail, 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 verb and resource (按关键词查找百度贴吧用户) and quantifies the result shape ('精确匹配和相关用户的单页结果，不支持分页'), which immediately separates it from the post/forum search siblings. An agent can tell what this tool returns without opening the schema.

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 concrete routing guidance: when a user homepage link already exists, use the user-profile or user-posts tools instead, and it flags that pagination is not supported. However it does not contrast itself with the other search siblings (search_general, search_posts, search_posts_in_forum), so the selection context is clear but not fully enumerated.

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?

Annotations already declare readOnlyHint=true, and the description reinforces that this is a read-only balance query. It adds useful context by tying the balance to the current API Key and pointing to the billing dashboard for recharges. No contradictions or hidden side effects are indicated.

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 two short sentences: the first states the core purpose, and the second provides an actionable billing link. Every word earns its place without unnecessary 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?

For a zero-parameter, read-only balance query with an output schema, annotations, and a billing link, the description is fully sufficient. No additional information is needed for an agent to select and invoke it 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?

The tool has zero parameters Belarusand schema coverage is 100%, so parameter semantics are not a burden on the description. The description still adds value by explaining what the returned balance represents.

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 states a specific action (query) and resource (current API Key account's SocialDataX points balance), including Chinese and English terms. It is unambiguous and obviously distinct from the YouTube-focused sibling tools.

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 identifies the exact context: querying the balance for the current API Key accounttons. It also provides a relevant follow-up URL for recharging. There are no competing sibling tools for balance checking, so no explicit alternatives are needed.

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