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

With no annotations provided, the description must carry the full behavioral disclosure burden, but it only states that the tool screens stocks. It does not describe the return format, whether filters are combined with AND/OR logic, data source, or any limitations, leaving significant ambiguity for a tool with 12 optional filters.

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

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

The description is a single, front-loaded sentence that efficiently communicates the tool's core purpose. It contains no unnecessary padding or repetition, although the word '智能' (intelligent) is slightly promotional.

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?

Despite a fully documented schema, the tool lacks an output schema and annotations, and the description is too sparse to provide adequate context. It omits key details such as how the filters combine, what the response contains, and when the tool should be chosen over the many siblings, making it incomplete for a complex 12-parameter screener.

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 100% coverage with descriptive parameter definitions, so the baseline is 3. The description's mention of PE/PB/technical indicators/MA alignment loosely aligns with the schema but adds no new semantic detail beyond what the schema already provides.

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

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

The description clearly states the tool's function: screening A-shares based on PE/PB, technical indicators, and moving average alignment. It uses a specific verb ('筛选' / screen) and resource ('A股'), and it is distinct from sibling tools that retrieve quotes, klines, or fundamentals.

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 exclusions or refer to sibling tools like get_realtime_quote or get_fundamentals, leaving the agent to infer usage solely from the tool's name and generic screening purpose.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states that it fetches quotes, with no mention of return format, maximum number of codes, error handling, or rate limits. This is a significant gap for a batch 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 a single concise sentence that efficiently conveys the core purpose with no redundant words. It is well-structured and immediately understandable.

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 no output schema and no annotations, the description should provide more context about expected results, limits, or usage constraints. It only states the action, leaving the agent to guess about response structure and practical usage considerations.

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 already provides 100% coverage with a clear description of the 'codes' parameter, including an example. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

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

The description '批量获取多只股票实时行情' (batch get real-time quotes for multiple stocks) clearly states a specific verb (get), resource (real-time quotes), and scope (multiple stocks). It inherently distinguishes from sibling get_realtime_quote by explicitly indicating batch functionality.

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 use case is implied by the word '批量' (batch): it should be used when multiple stock quotes are needed at once. However, there is no explicit guidance on when to prefer this over get_realtime_quote, nor any mention of limits or alternatives.

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 lists data fields and does not explain whether the tool returns historical or current values, how missing or invalid codes are handled, or what the output structure looks like. '获取' implies a read, but the description lacks meaningful behavioral context.

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

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

The description is a single, front-loaded sentence that immediately states the tool's purpose and lists example metrics. It contains no wasted words and is appropriately compact for a one-parameter tool.

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

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

For a simple one-parameter fundamental data getter, the description gives a minimum viable picture by naming key fields, but it does not explain the return format or possible time-series behavior. Since there is no output schema, the description should provide more detail about what the agent can expect in 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?

The schema fully describes the single required parameter 'code' with an example ('600519'), so the description does not need to add parameter details. This hits the baseline of 3 for full schema coverage; the description itself adds no specific parameter semantics beyond the schema.

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

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

The description uses a specific verb ('获取') and clearly identifies the resource ('A股基本面数据') with concrete examples of the metrics returned. This effectively distinguishes it from sibling tools like get_kline, get_technical_indicators, and get_realtime_quote, which target market, technical, or price 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 that this tool is for fundamental data rather than real-time quotes or technical indicators, but it does not explicitly state when to use it or when to choose alternatives. There is no direct comparison to sibling tools or exclusion criteria, so guidance is only implicit.

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 behavioral transparency falls on the description. It discloses the asset type (A-shares), supported periods, and forward-adjustment, but does not mention output format, default date range behavior, or any limits. This is honest but incomplete.

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

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

The description is a single, compact sentence that front-loads the core purpose and includes the most important qualifiers. No filler or redundant wording.

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?

Although simple, the tool has no output schema or annotations, so the description should explain at least the expected return values or default date range. It captures core use but omits these completeness elements, making it adequate yet gapped.

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 baseline is 3. The description adds value beyond the schema by explicitly stating that data is front-adjusted and limited to A-share K-lines, which helps interpret the 'code' and 'period' parameters meaningfully.

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 specifies the verb '获取' (get) and a clear resource: 'A股历史K线数据' (A-share historical K-line data), while explicitly noting periods and front-adjustment. This clearly differentiates it from sibling tools like get_realtime_quote and get_technical_indicators.

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 use for historical K-line data by its name and content, and sibling names suggest alternatives, but it does not explicitly state when to use this tool vs alternatives or mention exclusions. The guidance is adequate but relies on 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 burden. It discloses the type of data returned (main/retail net inflow, order size distribution) but omits details about return format, units, date behavior, or any potential side effects. It is not misleading, but transparency is average.

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 conveys the core purpose and data categories without redundant phrases. It is front-loaded and every word 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?

The tool is relatively simple with well-defined parameters, but there is no output schema and the description does not clarify the return structure or units. While adequate for selection, the absence of result-shape information leaves some ambiguity for an agent.

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% for both parameters (code and days), including an example and constraints. The description adds no additional parameter context, but since the schema is self-sufficient, the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as retrieving A-share money flow data, specifying key sub-components (main/retail net inflow and large/medium/small order distribution). This provides a specific verb+resource+scope that distinguishes it from sibling tools like get_realtime_quote or get_kline.

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

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

Usage context is only implied through the tool name and description; it does not explicitly state when to prefer this over alternatives or mention any exclusions. The description makes clear it is for money flow analysis, but lacks direct comparison with 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 carries the full burden for behavioral disclosure. It only lists output fields and mentions 'A股' scope, but does not disclose data freshness, error handling, rate limits, or response structure. The exchange auto-detection note appears only in the schema, not the tool description.

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

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

The description is a single concise sentence, front-loaded with the core action ('获取A股实时行情') followed by a parenthetical list of returned fields. Every word earns its place, with zero 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?

For a one-parameter tool with no output schema, the description adequately enumerates the returned data fields, giving a solid sense of what to expect. However, it does not specify response structure or nesting, and lacks caveats about real-time data reliability, which would make it fully complete.

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

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

Schema description coverage is 100%, and the parameter description already explains the code format with an example and exchange auto-detection. The tool description adds no additional parameter-level meaning beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states the tool fetches real-time A-share quotes and lists key fields (current price, change %, volume, PE/PB, market cap). This distinguishes it from tools like get_kline or get_technical_indicators, but it does not explicitly contrast with get_batch_quotes or mention single-stock scope, so sibling differentiation is implicit rather than explicit.

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

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

The description provides no guidance on when to use this tool versus alternatives like get_batch_quotes or get_kline. It merely describes the output without mention of use cases, prerequisites, 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?

With no annotations, the description carries the full burden for behavioral disclosure. It only states that rankings are fetched, omitting whether the data is real-time, how the ranking is computed, what the output format looks like, or any safety hints such as read-only nature. The ambiguity of '行业板块/概念板块' (whether both or either is returned) is also unaddressed.

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

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

The description is a single, concise, and front-loaded sentence that clearly states the tool's purpose with no filler. It earns full marks for efficiency.

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

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

For a tool with no output schema and no annotations, the description is too sparse. It does not explain default behavior (e.g., top=10), sort order, or return value structure, leaving critical gaps for an agent to use the tool correctly. The completeness is inadequate given the tool's complexity and missing structured 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 descriptions cover 100% of parameters (top and type), so the baseline is 3. The description adds no meaningful parameter semantics beyond what the schema already provides; it simply echoes the sector type concept.

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 function: retrieving gain/loss rankings for A-share industry and concept sectors. It uses a specific verb (获取) and a distinct resource type, differentiating it from sibling tools that focus on individual stocks, quotes, or klines.

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 scenarios where sector-level performance is needed, nor does it compare with sibling tools. Usage is only implied by the tool's name and context, which is insufficient.

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, but it only states the basic function. It does not describe return format, sorting, pagination, or any limitations.

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

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

The description is a single, clear sentence with no superfluous words. It is concise and 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?

Despite having only two parameters and no output schema, the description does not explain what the returned news/announcements contain, how they are ordered, or any additional context needed for effective use. Minimal for a tool that could return varied data.

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 descriptions cover 100% of parameters (code and limit), so the baseline is appropriate. The tool description adds no extra parameter context beyond what the schema provides.

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

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

The description clearly states the tool retrieves news and announcements for individual stocks, distinguishing it from sibling quote/data tools. However, it omits that a specific stock code is required, though the schema makes this evident.

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 is provided about when to use this tool vs. alternatives. The description does not mention sibling tools, exclusions, or scenarios where this tool is 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It does not mention whether the tool is read-only, what happens if insufficient data is available, or how the calculated indicators are returned. The schema's period note mentions a 30-data-point requirement, but that is in the schema, not the description.

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

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

The description is a single, concise sentence that front-loads the core purpose and list of indicators. Every word is informative, with no redundant or filler 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 no output schema, and the description only lists the indicator names without explaining the return format, data structure, or any edge cases (e.g., unsupported codes, data sufficiency). This leaves meaningful gaps for an agent invoking the tool, though the listed indicators provide some clarity.

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 parameters (code and period) are already fully documented. The description adds no extra meaning about parameters, such as how they affect indicator calculations, but the baseline 3 applies because the schema handles the details.

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 function: calculating A-share technical indicators, and enumerates specific indicators (MACD, RSI, KDJ, Bollinger Bands, moving averages). It uses a specific verb ('calculate') and a clear resource, but does not explicitly distinguish itself from sibling tools like get_kline or get_realtime_quote, which could also provide related 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?

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without indicating scenarios (e.g., 'use for trend analysis') or exclusions (e.g., 'not for real-time pricing'). Sibling tools are not mentioned.

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 burden of behavioral disclosure. It adds value by mentioning fuzzy search across code, name, and pinyin, but it does not disclose return format, result limits, or any operational nuances. 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 a single, concise sentence that is front-loaded with the primary action and immediately conveys the key capabilities. No wasted words.

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

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

For a simple search tool with one well-described parameter and no output schema, the description is largely complete. It explains what is searched and the supported matching modes. Minor omissions like result count or ordering prevent 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 coverage is 100% because the parameter keyword includes a description with examples. The tool description reinforces the search scope but does not add much beyond the schema. 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?

The description clearly states the tool searches A-share stocks with a specific verb and resource, and specifies supported search methods (code, name, pinyin fuzzy search). This distinguishes it from sibling tools like get_realtime_quote or get_kline.

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 context of use is implied: it is a search tool to find stocks before retrieving quotes or other data. However, there is no explicit guidance on when to use it versus alternatives, nor any exclusions or conditions.

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