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

No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as data source, update frequency, pagination, error conditions, or rate limits. The description is purely descriptive of the content type without any indication of side effects, performance implications, or data retrieval specifics.

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 concise and efficiently conveys the core purpose in one line followed by a parameter list. It is front-loaded with the main content description. The parameter documentation is minimal but sufficient for basic understanding. No extraneous 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?

The tool has a simple input (2 parameters) and an output schema exists (though not shown in detail). For a data retrieval tool like this, the description gives the essential purpose and parameter meanings. It lacks guidance on typical use cases or output interpretation, but with an output schema available, the agent can infer the return structure. The main gaps are usage guidelines and behavioral disclosures.

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?

With 0% schema description coverage, the description must compensate, but it only provides 'Args: symbol: 股票代码, count: 取最近几笔，最多 50'. This clarifies that symbol is a stock code and count is the number of recent trades (max 50), which adds meaning beyond the bare schema. However, it does not explain the format of symbol (e.g., exchange prefix), the default behavior if count is omitted, or the meaning of 'recent' in terms of time periods.

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 '大宗交易明细' (block trade details), specifying the resource. It mentions 成交价 (transaction price), 折溢价率 (discount/premium rate), and 买卖双方营业部 (trading departments of both parties). However, it does not provide explicit differentiation from sibling tools like get_quote or get_capital_flow, though the specific details mentioned distinguish it sufficiently.

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. There is no mention of scenarios, prerequisites, or exclusions. Sibling tools like get_capital_flow and get_quote might be alternatives for different types of trading data, but no such comparisons are made.

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 must carry behavioral disclosure. It reveals the A-shares limitation and the content of the return (product/region split), but it does not state whether it is read-only, require authentication, or mention any edge cases (e.g., companies with no breakdown). Since this is a simple data-fetch tool, the risk is low, but the description does not explicitly cover these traits beyond the core functionality.

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 concise: one content line for purpose and two short argument definitions with no redundancy. It front-loads the core purpose and immediately follows with parameter docs. Every sentence 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?

Given the tool's simplicity (2 parameters, no nested objects) and the existence of an output schema, the description covers the essentials: what the data is, for which market, and how to parameterize the call. It could mention data availability caveats, but they are not critical for an agent 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?

The Args section adds essential meaning: symbol is described as a stock code, and count is '取最近几个报告期' (number of recent reporting periods) with a max of 8. This is far beyond the bare schema (which has no descriptions), compensating for the 0% schema coverage with clear, practical parameter semantics.

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 it provides a business breakdown (主营构成) with revenue, cost, and gross margin split by product and region, and scopes it to A-shares only. This is a specific verb+resource (get breakdown) and distinguishes it from financial statement or profile tools by its explicit domain.

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 implies usage for when detailed revenue/cost/margin segmentation is needed, and the A-shares restriction is a de facto usage constraint. However, it does not explicitly mention alternatives (e.g., 'use get_financial_statement for consolidated figures') or any when-not-to-use guidance, leaving the selection partly 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It does disclose a key constraint: the API returns at most about 20 trading days, which is useful. However, it does not mention any side effects, required permissions, or rate limits. For a read-only data tool, this is acceptable but thin; more context about the data's reliability or update frequency would help.

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 minimal and front-loaded with the core purpose, followed by a clean parameter list. There is no fluff, and every sentence adds value. It is immediately clear what the tool does and what arguments it needs.

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 tool's simplicity (2 params, one required), the description covers the essentials: purpose, parameter meanings, and a key limit. The presence of an output schema means return values do not need to be spelled out. The only gap is the lack of usage guidance, which is already low on the usage dimension. Overall, it is nearly complete for a straightforward data-retrieval 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?

The schema has no descriptions (0% coverage), so the description must explain the parameters. It does: symbol is the stock code, days is the lookback period, and it adds the critical bound that the API provides at most ~20 trading days. This goes well beyond what the schema offers, giving agents actionable semantics.

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 the tool returns capital flow data: net inflow trend and order size breakdown for the day. The verb 'get' plus the resource 'capital flow' is specific, and it distinguishes itself from siblings like get_quote (price) and get_kline (price history) by focusing on money flow. A single, concise line conveys the purpose unambiguously.

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 states what the tool does but gives no explicit guidance on when to use it versus alternatives. It does not mention sibling tools like get_quote or get_kline, nor does it specify scenarios where capital flow data is appropriate. The usage context is only implied from the name and description, not 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?

With no annotations provided, the description carries the full burden. It discloses the A-share scope and the data fields but says nothing about performance, errors, data freshness, or whether the call is read-only. The description is too sparse to inform an agent about side effects or constraints beyond the scope.

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 concise: a single sentence listing the returned fields and the scope, followed by an Args section. It is front-loaded with the core purpose and avoids any filler, making it highly efficient.

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 description covers the tool's purpose, scope, and parameter meaning, and an output schema exists to define the return structure. However, it omits details like symbol format, behavior on invalid symbols, and any prerequisites (e.g., authentication). For a simple tool, this is borderline adequate but leaves several practical questions unanswered.

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 schema provides no description for the 'symbol' parameter (0% coverage), so the description's 'symbol: 股票代码' adds essential meaning—identifying it as a stock code. However, it does not specify the expected format (e.g., sh/sz prefix, 6-digit code) or any validation rules, leaving ambiguity for edge cases.

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 the tool fetches company profile data (introduction, main business, actual controller, employee count, industry, concept sectors) and explicitly limits to A-shares. This distinguishes it from siblings like get_quote or get_financial_statement, making its purpose unambiguous.

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 explicit guidance on when to use this tool versus alternatives. It does not mention related tools or conditions for selection, leaving an agent to infer from the field list alone. This is a significant gap given the large number of 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?

With no annotations provided, the description bears the full burden. It discloses that the tool retrieves historical dividend data with ex-rights dates and the A-share restriction. It does not explicitly state that it is read-only or describe error handling, but for a data query tool the behavior is clear enough.

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 compact one-line purpose plus a two-line parameter list. It is front-loaded and wastes no words. Slight structure improvement could separate the Args block visually, but it is already concise and scannable.

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 an output schema exists, no return-value explanation is needed. The description covers parameter meaning and the A-share constraint. It is complete for a simple query tool, though it could mention the 'count' default behavior (already in schema) or any sorting order of 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 0%, but the description's Args section fully documents both parameters: 'symbol' as stock code and 'count' with a maximum of 50. This compensates completely for the lacking schema descriptions.

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 the exact resource (historical dividend/bonus plans and ex-rights/ex-dividend dates) and limits to A-shares. This is specific and distinguishes it from all sibling tools, none of which cover dividends.

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 clearly states the scope (A-shares only), which tells the agent when this tool is appropriate. Since no sibling tool covers dividends, explicit alternatives are unnecessary, but the description could have noted when this tool should not be used (e.g., for Hong Kong stocks).

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. It discloses that fields are translated to Chinese and units are converted, and that output is arranged for cross-period comparison. It also specifies the maximum of 20 periods for the count parameter. While it does not mention error conditions or read-only status, the disclosed output formatting and data processing behavior exceed the minimum expectation for a read-only financial data 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?

The description is front-loaded with the core purpose and then provides a structured Args list. It is slightly verbose but each line is informative and no sentence is wasted. The layout is logical and easy to parse, though it could be tightened slightly without losing 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?

Given the complexity of the tool (5 parameters, multiple markets, and various statement types), the description covers the key usage context: supported regions, unit conversion, and output layout. The output schema exists, so return structure is not fully described in text, which is acceptable. The description is sufficient for an agent to call the tool correctly for most use cases.

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 0%, so the description must compensate, and it does thoroughly. Each parameter (symbol, statement, report_type, count, detail) is explained with its purpose and acceptable values. Statement and report_type get explicit enumerations (e.g., indicator/income/balance/cash_flow and all/Q1/Q2/Q3/Q4), which the schema lacks. This fully bridges the gap left by the schema's missing descriptions.

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 that the tool retrieves financial statements and core indicators, supports A/HK/US stocks, and organizes output by indicator × reporting period. It distinguishes itself from siblings like get_quote and get_kline by focusing on statement-level data. The purpose is specific and immediately understandable.

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 explains what the tool does but does not explicitly state when to use it over alternatives or when not to use it. There is no mention of competing tools or conditions that would route the agent to a different sibling. However, the purpose is clear enough that an agent can infer appropriate usage based on the need for financial statements.

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 bears full responsibility for behavioral disclosure. It only mentions a count limit ('最多 30') in the args section, but doesn't disclose return format, sorting, pagination, or any side effects. This is a read operation by implication, but nothing explicit is stated.

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 concise: one sentence stating purpose plus an args line. It front-loads the main purpose without any filler. The structure is efficient and easy to scan, earning a high score for 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?

The description covers the basic purpose and parameter constraint, which suffices for a simple retrieval tool. An output schema exists (though not shown) to cover return details, so that gap is mitigated. Still, it lacks context on ordering, recency, or what constitutes 'hot', making it 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 0%, so the description must compensate. It adds 'count: 条数，最多 30' which explains the parameter means number of items and caps it at 30—helpful beyond the schema's integer type and default. However, it doesn't elaborate on valid ranges or formatting, leaving gaps.

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 the resource (Xueqiu homepage hot discussions) and its purpose (understand current market-wide topics). It distinguishes this from siblings like get_hot_stocks by focusing on discussions/posts rather than stocks. However, it uses a noun phrase ('雪球首页热门讨论') rather than an explicit verb like 'get' or 'fetch', though the intent is unmistakable.

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. It doesn't mention alternatives like get_hot_stocks, get_stock_discussions, or search_posts, nor does it give conditions for selection. The description simply states what it is without any contextual usage direction.

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 states that results are sorted by attention heat and include heat change. It discloses nothing about data freshness, pagination, auth requirements, or whether this is a safe read operation. The description is thin for a tool with zero annotation coverage.

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 purpose is front-loaded in one clear line, followed by a tight Args block. No wasted sentences. It's appropriately compact for a two-parameter tool, though slightly terse given it's the sole carrier of behavioral 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 and only two optional parameters, the description adequately documents the parameters and purpose. However, the absence of any usage guidance or behavioral context (read-only nature, heat-change semantics) leaves gaps an agent needs to invoke it confidently. Adequate but not thorough.

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 0%, so the description must compensate, and it does. It maps both parameters to real meaning: 'market: CN A股 / HK 港股 / US 美股' explains valid values the schema only carries as a default string, and 'limit: 取前多少名，最多 100' documents the upper bound. This is genuine value beyond the input 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 description states the resource precisely: a Xueqiu popularity leaderboard of stocks ranked by user attention, including heat change. It clearly distinguishes from siblings like get_hot_posts (posts, not stocks) and search_stock (search, not ranking). It lacks an explicit verb but 'get' is in the name, so purpose is unambiguous.

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 Args block documents parameters but provides no when-to-use guidance and no exclusions or alternatives. An agent isn't told when to choose this over search_stock, get_quote, or screen_stocks, nor what scenarios favor a popularity ranking. The market parameter values hint at coverage but don't substitute for routing 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 are absent, so the description carries the full disclosure burden. It discloses the core behavior well: returns historical K-lines, optionally enriches each bar with PE/PB/PS/market cap, enforces a 500-bar cap, and exposes adjustment modes (前复权/后复权/不复权). It does not disclose result ordering, pagination, or rate limits, but for a read-only lookup tool the disclosed traits are reasonably adequate, so a mid score is appropriate.

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 one-sentence intro front-loads the essential purpose, followed by a clean Args block. There is no wasted prose and the structure is scannable. Minor inefficiency: the Args block restates parameter names that already exist in the schema, but since the schema carries no descriptions, the repetition 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?

An output schema exists, so return-value shape need not be explained. The description adequately covers purpose, all parameter semantics, and the valuation option. Gaps remain: no guidance on overlap with get_minute for intraday periods, no statement about result ordering, and no mention of the default values (count=60, adjust='before') that live only in the schema. Adequate but with clear missing context.

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 0%, so the description bears full responsibility and compensates well. All 5 parameters are documented: symbol as 股票代码, period with the full 12 valid values, count with the 500 max, adjust with the before/after/normal semantics, and with_valuation with its effect. Because the schema defines no enums, the explicit value lists in the description are genuinely valuable additions.

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 resource ('历史 K 线' - historical K-line) and an optional feature (including PE/PB/PS/market cap per bar). The verb 'get' in the name plus the resource makes the purpose clear. However, it doesn't differentiate itself from the sibling get_minute, which may also cover intraday bars given the period options include 1m/5m/.../120m, so an agent gets no help choosing between 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?

No when-to-use or when-not-to-use guidance is provided. No alternatives are named, no exclusions are stated, and there is no mention of how this relates to get_minute or get_quote for intraday needs. The only hint is '适合做估值分位分析' (suitable for valuation percentile analysis) attached to with_valuation, which is a use-case note but not guidance about selecting this tool versus 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states the data scope (balance, buying, net buying) and parameter constraints (max 90 days), but does not mention side effects, auth requirements, rate limits, or any other behavioral traits. It never explicitly states it is read-only, though the nature implies it. The description provides minimal behavioral context beyond the data fields.

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 parts: a one-line purpose and a concise Args list. The purpose is front-loaded and the parameter explanations are terse and informative. Every sentence serves a function, 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?

Given the simple nature of the tool and the presence of an output schema, the description provides the essential context: the data scope, the eligible-stocks constraint, and parameter meanings. It lacks details on the response structure, but that is handled by the output schema. Possibly could mention the time series nature, but it's implied by '回溯交易日数'. Overall it's quite complete for this 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?

The schema provides only types and defaults with 0% description coverage. The description fills the gap by explaining that symbol is a stock code and days is the lookback trading days with a max of 90. This adds crucial semantic meaning that allows correct invocation, and it also clarifies the limit on days.

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 the tool returns margin trading balance, margin buying, and net buying for margin-eligible stocks. It uses a specific verb and resource and adds a scoping constraint (仅两融标的), distinguishing it from generic quote or kline tools. This is a clear, specific purpose.

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 implies when to use this tool—when margin trading data is needed—but gives no explicit guidance on alternatives. There is no mention of when not to use it or which sibling tool to choose instead. The constraint '仅两融标的' hints at eligibility but doesn't guide selection.

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. It does disclose the automatic sampling to ~40 points, which is useful. However, it omits details such as data latency, timestamp format, error behavior, or rate limits. The description adds some transparency but leaves meaningful gaps.

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 exceptionally concise: a single front-loaded sentence stating the core purpose, followed by a compact args list. There is no filler or redundancy; every word serves to clarify usage.

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 tool has an output schema (which explains the return format), the description covers the essential aspects: purpose, parameter meanings, and a behavioral note about sampling. It lacks explicit sibling comparison and potential error conditions, but for a simple read-only tool with a short parameter list, it is sufficiently complete 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?

The schema has 0% parameter description coverage, so the description must compensate. It does so by explaining that 'symbol' is a stock code and defining the enum-like 'period' options ('1d' for current day, '5d' for past five days). This goes well beyond the bare schema and clarifies both parameters effectively.

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 the tool's purpose: fetching intraday (minute-level) trend for the current day or past five days, with a specific behavioral note about auto-sampling to ~40 points. This is a specific verb-resource pairing and effectively differentiates it from siblings like get_kline (which likely provides daily K-line data).

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 implies usage context (when minute-level data for today or the past five days is needed) but does not explicitly mention alternatives or conditions for choosing this tool over get_kline or get_quote. There is no guidance on when not to use it or which sibling to prefer under specific circumstances.

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?

There are no annotations, so the description must carry the full burden of disclosing behavior. It states it fetches full text and comments, implying a read operation, but it doesn't explicitly confirm read-only, mention any authentication requirements, or note limitations like failure modes or rate limits. It also doesn't explain what happens with the 'with_comments' toggle beyond the schema default. Given no annotation coverage, this is a notable 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 concise and well-structured: a one-sentence overview followed by a clear Args list. No fluff or redundant information. The main purpose is immediately stated, and parameters are explained in a compact bullet-like format. Every sentence adds 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?

There is an output schema, so return-value details are not needed in the description. The description covers the core function and parameter semantics, but it lacks guidance on when to choose this tool over sibling tools, nor does it mention any side effects or prerequisites. For a relatively simple fetch tool, this is adequate but not comprehensive, especially given the many sibling tools in the context.

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 schema description coverage is 0%, so the description must compensate, and it does well. The Args section explains post_id can be a numeric ID or a full link, with_comments controls whether comments are included, and comment_count has a max of 30 – none of this is in the schema. This provides critical semantic guidance that the schema alone lacks, so a high score is warranted.

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 the function: '按帖子 ID 取全文及热门评论' (get full text and popular comments by post ID). It identifies the resource (post), the operation (fetch), and the scope (full text + comments). While it doesn't explicitly contrast with siblings like get_hot_posts or search_posts, the name and the description are unambiguous enough that an agent can infer its role, especially with the hint that IDs come from discussion or hot-post lists.

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 implicit usage context: it says the ID can be obtained from a discussion list or hot-post list, which suggests when one might have a post ID at hand. However, it doesn't explicitly state when to choose this over alternatives like search_posts or get_user_posts, nor does it give exclusions. This is more than no guidance but less than explicit recommendations, so a 3 is appropriate.

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. While 'real-time snapshot' hints at read-only behavior, it does not explicitly declare it read-only or disclose any constraints like rate limits, pagination behavior, or that it returns only current values. There is no mention of error handling or data freshness limitations. The description adds minimal behavioral context beyond the tool name.

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 concise and front-loaded with the primary purpose. It efficiently covers the key asset classes and parameter details. No filler words. The structure separates the main description from parameter docs, which is clear.

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?

There is an output schema, so return values are covered. The description explains both parameters and the supported scope. However, it lacks explicit mention of the read-only nature or any operational constraints (e.g., number of symbols allowed per call, rate limits). For a tool with no annotations and only two simple parameters, this is adequate but not 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 0%, so the description must explain parameters. It does this well: 'symbols' is explained with concrete examples (e.g., '600519' or '600519,00700,AAPL') and supports multiple types; 'detail' is described as returning full fields including pledge ratio and goodwill. This adds meaningful semantics beyond the schema's bare titles.

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 the tool fetches a real-time market snapshot with specific fields (price, change, volume, market cap, PE/PB, dividend yield, etc.). It explicitly mentions multi-symbol support and asset classes (A-shares, HK, US, indices, ETFs, convertible bonds). This distinguishes it from siblings like get_kline (historical data) and get_minute (intraday bars).

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 implies usage context by saying 'real-time snapshot' and lists the asset types it supports, but it does not explicitly state when to use this tool instead of alternatives like get_kline or get_minute. It could be clearer about avoiding this for historical data or comparison with 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does state that the tool returns shareholder count trends, top 10 circulating shareholders, and institutional holdings, and restricts to A-shares. This gives basic insight into data scope and content. However, it does not mention any side effects, rate limits, data freshness, or that it is read-only (though that is implied). The description adds some behavioral context but is not thorough.

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 concise and front-loaded: the main purpose is stated first, followed by the Args section for parameters. It is two short lines of Chinese plus an argument list. Nothing is redundant, and the structure is clear. It could arguably be slightly more polished but is efficient and well-organized.

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 that an output schema exists (though its content is not shown here), the description does not need to explain return values. It covers purpose, scope (A-shares only), and parameters with meaning. The only minor gap is that it does not mention any pagination or limits beyond top_n, but that is likely covered elsewhere. For a data-retrieval tool, this is fairly 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?

The input schema has 0% description coverage, so the description must compensate. It does: 'symbol' is explained as the stock code, and 'top_n' is described as the number of top circulating shareholders to display, with a max of 20. This adds meaning beyond the schema's type and default. Both parameters are given usable semantics, making the description a strong compensator for the schema gap.

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 the tool's purpose: shareholder structure, including shareholder count trends, top 10 circulating shareholders, and institutional holdings (fund/social security/QFII). It is specific and distinct from siblings like get_quote or get_financial_statement, though it does not explicitly name alternatives. It also mentions the A-share-only constraint, narrowing scope.

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. It does not mention any prerequisites, exclusions, or link to sibling tools. The only hint is the 'A-shares only' constraint, which implicitly limits usage but does not help an agent decide between this and other shareholder-related tools (if any). Sibling tools like get_company_profile or get_financial_statement might overlap, but no comparison is offered.

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?

There are no annotations, so the description must carry the full burden. It only states what data is returned and implies read-only behavior but does not disclose any side effects, auth needs, rate limits, or pagination behavior. This is a significant gap for a tool with no annotation coverage.

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 concise and front-loaded with the core purpose, followed by usage context and parameter explanations. Every sentence adds value, with no redundancy or 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?

Given the tool's moderate complexity, an output schema exists, and parameters are well-explained in the description, it is largely complete. It slightly lacks explicit disambiguation from similar post-fetching tools (e.g., search_posts, get_hot_posts), but the usage context partially covers that.

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 0%, but the description's Args block explains each parameter: symbol (stock code), sort (hot/time with definitions), count (max 30), page (page number). This adds meaningful semantics beyond the schema's default values, fully compensating for the coverage gap.

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 the tool fetches stock-specific discussion posts with author, follower count, likes/comments, and content. It distinguishes itself from sibling tools by specifying '个股讨论区' (individual stock discussion) and mentioning market sentiment and retail/whale opinions, which is a specific resource and purpose.

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 provides explicit usage context: '想了解市场情绪、散户与大 V 观点时使用' (use when wanting to understand market sentiment, retail and big-V opinions). This guides when to use it, though it does not mention alternatives or exclusions, so it falls short of a 5.

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 full responsibility. It states the tool returns a news/announcement feed but does not disclose whether it is read-only, any rate limits, pagination behavior beyond the page parameter, or what happens with invalid symbols. Minimal behavioral disclosure beyond the obvious read operation.

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?

Description is concise with a clear Args list, front-loaded with the purpose. No redundant sentences, each parameter is explained efficiently. Minor formatting choice (code block) is acceptable.

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 tool's moderate complexity (4 params, one required) and the presence of an output schema (so return format is covered elsewhere), the description covers the essential invocation details. Missing are edge-case behaviors or example usage, but overall sufficient for a straightforward data-retrieval 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 coverage is 0%, so the description must compensate. It explains each parameter: symbol as stock code, kind distinguishing news vs. notice, count with max limit of 30, and page for pagination. This adds meaning beyond the bare schema (which only has defaults and types), though it could be more detailed about possible values for kind.

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?

Description clearly states the tool retrieves individual stock news or announcements (个股新闻或公告流), with parameters distinguishing news vs. notices. It is specific about the resource (stock news/announcements) and distinct from sibling tools like get_stock_discussions or get_hot_posts, though it does not explicitly differentiate itself.

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. The description only lists parameters and their meanings, leaving the agent to infer usage context. Does not mention prerequisites, alternative tools, or exclusions.

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. It only says 'view' (查看), implying a read operation, but it discloses no further behavioral traits such as authentication needs, pagination behavior, rate limits, or how it handles non-existent users. The description is too thin on side effects and constraints.

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 brief and to the point, with the core purpose in the first line and parameter details listed cleanly. Every sentence earns its place; there is no fluff or repetition of schema defaults.

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 it is a simple read/list tool with an output schema present (per context signals), the description covers the essential parameters and purpose. It could mention pagination behavior or ordering, but these are not critical for an agent to invoke the tool correctly. It is sufficiently 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 0%, so the description must compensate. It does: it explains user_id is a numeric ID (with format hint from the URL example), count has a maximum of 30, and page is a page number. This adds meaningful context beyond the bare 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 description states a specific action ('查看' / view) and a precise resource ('某位雪球用户的发帖动态' / a particular XUEQIU user's post activity), and even adds a use case ('用于跟踪特定作者的观点' / for tracking a specific author's opinions). This clearly distinguishes it from sibling tools like get_post (single post) and search_posts (keyword search).

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

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

The description explicitly identifies the purpose: tracking a specific author's views, which tells an agent when to use this tool over generic search or post retrieval. However, it does not mention alternatives or when not to use it, so it stops short of full routing 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions a list of industries and the encode field, but does not describe whether the operation is read-only, the scope of returned industries, potential pagination, or any limitations. Essential behavioral context is missing.

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 concise, with the purpose and a crucial usage hint front-loaded, followed by a clear parameter specification. No redundant words or 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?

Given that an output schema exists (covering return fields) and the tool is a simple listing with one optional parameter, the description covers the essential integration context (use for screen_stocks) and parameter values. It is adequate, though it could note that market defaults to CN (already in schema) and there is no mention of any additional behavior like pagination.

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 schema description coverage is 0%, and the schema only states type and default. The description explicitly lists allowed values (CN/HK/US) for the market parameter, filling a critical gap and making the parameter meaningful.

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 it lists Shenwan industry classifications, and explicitly ties the returned encode to the industry parameter of screen_stocks. This distinguishes it from sibling tools and gives a specific verb-resource combination.

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 implies the primary usage (obtain industry codes to feed into screen_stocks) but does not state when not to use it or mention alternatives. Given the tool's specialized nature, this is adequate, though not fully explicit about exclusions.

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?

描述披露了无 keyword 时返回内容约为带 keyword 时的 9 倍，提示性能影响。但没有提及返回结构、分页或数据量上限。无注释信息，描述承担部分行为披露责任，但本工具为只读元数据列表，风险较低。没有与注释矛盾。

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?

描述简洁，先说明用途和调用时机，再用建议强调 keyword 的重要性，最后列出参数含义。没有冗余信息，但参数部分重复了 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?

有输出 schema（未展示但存在），描述解释了工具用途、参数含义和使用建议。对于列出元数据的工具，已足够让代理正确调用。缺少对返回格式的显式说明，但输出 schema 已提供，因此不算关键缺失。整体完整。

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 描述覆盖率为 0%，但描述对两个参数给出了明确含义：market 指定市场（CN/HK/US），keyword 用于按中文名或指标名过滤。描述补充了 schema 未提供的信息，但未说明 market 的枚举或默认值的具体行为，虽有默认值但未描述。覆盖了关键语义，略有不足。

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?

明确说明该工具列出选股器支持的指标及其中文名（雪球官方元数据），并提及在 screen_stocks 前调用以确认指标名。动词+资源+具体内容都清晰，与兄弟工具区分度高（screen_stocks 执行筛选，此工具提供元数据）。

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?

明确说明应在 screen_stocks 前调用，且建议总是带 keyword 以避免返回大量数据。虽未明确提及何时不用，但上下文已提供足够的使用时机。与兄弟工具的关系通过引用 screen_stocks 暗示。

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 are absent, so the description carries the full behavioral burden. It explains the filters format extensively, including an example, the '_l' suffix meaning, and that columns exclude null values. However, it does not disclose how results are ordered by default, what happens if filters are omitted, or the exact output structure (though an output schema exists). These gaps mean it's adequate but not comprehensive.

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 well-structured: a one-line summary, a detailed explanation of the filters parameter with an example, then a clean parameter list. Every sentence has purpose; no fluff or redundant statements. It's slightly long but appropriate for a tool with 9 parameters and complex filtering syntax.

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?

This is a complex tool with 9 parameters, a filter syntax, and cross-references to two sibling tools. The description covers the essential usage: filter format, parameter meanings, and routing to helper tools. With an output schema present, not describing return values is acceptable. Some edge cases (e.g., empty filters) are not covered, but overall the information is sufficient 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 0%, so the description must compensate. It does so well: each parameter is explained with examples or allowed values (e.g., market: CN/HK/US, exchange: sh_sz/sh/sz/bj). The order_by field lists common metrics. This significantly clarifies the schema, which otherwise provides only names and types. Minor missing details like precise limit bounds are already in the schema defaults.

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 starts with '选股器' (stock screener) and clearly states it filters and sorts stocks by valuation, financial, and market indicators. This is a specific verb (screen/sort) and resource (stocks), and it differentiates from siblings like get_quote, get_kline, and search_stock which target individual stocks or quotes. The purpose is unambiguous.

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 does not explicitly mention alternatives, but it clearly implies usage contexts: when you need to screen stocks by criteria. It also proactively directs the user to list_screener_metrics and list_industries for metric/industry codes, which is valuable guidance. It does not state when not to use this tool, but given the breadth of the screener functionality, the omission is minor.

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. It does add useful constraints: it notes the maximum count is 30 and that pagination is supported via the page parameter. It also clarifies the scope as 'all posts.' However, it does not state whether the operation is read-only, whether any authorization is required, or describe any side effects. While these are typical for a search tool, they are not explicitly disclosed. Given the absence of annotations, this is a moderate gap, so a 3 is appropriate.

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 concise: a one-sentence purpose statement followed by a compact parameter list. It front-loads the core purpose and uses a clear list format for parameters. Every sentence earns its place—there is no filler or redundancy. This is an exemplary model of 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?

Given the existence of an output schema, the description need not explain return values. The description covers the essential aspects: the action (search all posts), the key parameters with examples and constraints, and the pagination mechanism. It does not mention potential edge cases or advanced filters, but for a simple post search tool, the provided details are sufficient. The description is complete enough for an agent to invoke it correctly without further clarification.

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 0%, so the description must compensate. It does so effectively: it explains the query parameter with examples (e.g., 「宇树」「红利策略」), states the count limit of 30, and clarifies that page is a page number. These details go well beyond the schema's bare type definitions and defaults. The only slight weakness is that the page parameter is only described as '页码' without indicating default behavior or range, but the default is already in the schema. Overall, it adds substantial 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?

The description states a clear and specific verb-resource pair: 'search all Xueqiu posts' (全站搜索雪球帖子). It explicitly indicates the scope as '全站' (all site), distinguishing it from sibling tools like get_post (specific post), get_user_posts (user-specific posts), and search_stock (stock search). An agent can immediately infer what this tool does and how it differs from similar 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 provides clear context for when to use the tool—whenever a search across all posts is needed—but it does not explicitly mention alternative tools or exclusion conditions. It lacks explicit statements like 'use this instead of get_user_posts when you need all posts' or 'do not use for specific post retrieval.' The implied usage is clear, but no formal guidance on alternatives is given, so it falls just short of a 5.

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 disclosure burden. It mentions it returns the standard code, implying a read operation, but does not explicitly state side-effect-free behavior, rate limits, authentication, or error handling. This is adequate but not rich.

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 compact and well-structured: a one-line purpose, a usage condition, and a parameter list. Every sentence serves a purpose, with no redundant text.

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 description covers the main use case, parameter semantics, and return type (standard code). Since an output schema exists, the exact response structure is not required here. Minor gaps include error handling and behavior when no matches are found, but these are not critical for a search 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 coverage is 0%, so the description fully compensates by explaining each parameter: query accepts names, pinyin initials, or codes (with examples '茅台', 'gzmt', '600519'), and limit specifies return count with a maximum of 20. This adds substantial value beyond the raw 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 description states a specific action (search) on a specific resource (stock) with a clear method (by name, pinyin, or code) and a defined return (Xueqiu standard code). It distinguishes itself from siblings like search_posts and screen_stocks by focusing on individual stock lookup rather than screening or post search.

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

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

It explicitly states when to use: '当用户给的是公司名称而不是代码，且需要确认具体标的时使用' (when the user gives a company name instead of a code and needs to confirm the specific target). This is a clear condition, but it does not mention when not to use or name alternative tools, so it falls short of full exclusionary guidance.

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