Wudao A-Share Stock Data MCP

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

Annotations already declare readOnly/idempotent/non-destructive, setting a low bar. The description adds genuinely useful behavioral context absent from annotations: automatic threshold differences by board type and automatic switching of the 主板风险警示口径 by rule effective date. It does not mention rate limits or data freshness, but the board-switching detail is a meaningful addition.

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 core rule sentence is dense and front-loaded, but the trailing 【链接】 instruction about markdown link formatting is a presentation rule rather than tool semantics, and the description packs regulatory exceptions into one long sentence that risks losing the agent's attention.

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

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

With annotations covering safety and an output schema covering return values, the description supplies the domain-specific rule knowledge (thresholds, board differentiation, effective-date switching) that an agent cannot infer from structured fields. It is complete enough for correct invocation, though sibling disambiguation is still missing.

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

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

Schema description coverage is 100%, and the schema itself documents code/date/format/detailLevel and the requirement of at least one of date/code. The description adds no parameter-level detail beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource (按交易所规则检测个股价格偏离基准指数的异动) and details the exact detection thresholds (±20%/±30% for 主板/双创, 10日严重异动). This precisely distinguishes it from price-movement siblings like limit_up_filter or approaching_limit_up.

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 a '何时使用' tag pointing to 监管口径异动和风险提示, but does not contrast with any of the numerous sibling tools (e.g., limit_events, broken_limit_up) or specify when *not* to use it. Usage context is implied rather than explicitly routed.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is a real-time-only feed, rejects historical dates, and degrades to an explicit status on pre-market/non-trading days. It also mandates an output link format, though it does not describe pagination or rate behavior.

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

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

The purpose is front-loaded in the first sentence, followed by usage conditions and output link rules. It is information-dense with little waste, though the markdown-link formatting instruction is somewhat tangential to tool selection and lengthens the block.

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

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

With an output schema present, the description needn't enumerate return fields, and it correctly avoids doing so. It covers the critical date constraint and the real-time-only limitation, and adds output link-formatting guidance. Only minor gaps remain around result volume or pagination, which the maxRowsPerLevel schema already partly addresses.

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

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

Schema description coverage is 100%, so all six parameters (date, format, detailLevel, maxRowsPerLevel, includeFirstBoard, includeReasonInfo) are already documented in the schema. The description's 【链接】 note concerns output rendering rather than parameter meaning, so it adds little param-level value. Baseline 3 is appropriate when the schema carries the load.

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

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

The description states a specific verb and resource: real-time monitoring of stocks whose gain is nearing the limit-up price but has not yet sealed the board, framed as intraday capture of potential limit-up opportunities. This is a distinct concept from siblings like limit_up_ladder or broken_limit_up, and an agent can reasonably tell it apart. It stops short of explicitly naming the sibling it is not (e.g. broken_limit_up for stocks that failed to seal).

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

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

The '何时使用' clause gives clear context: only for same-day intraday sprint-to-limit monitoring, historical dates unsupported, and pre-market/non-trading days return an explicit status rather than an empty error. It also names a companion tool (minute_data). It lacks explicit alternatives for adjacent queries (e.g. when to use limit_up_ladder or broken_limit_up instead), so it is strong but not exhaustive.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description is not burdened with that. It adds value by disclosing the content of the payload and by stating a required-input constraint that annotations do not carry. It stops short of behavior like rate limits or pagination, keeping it at a 4.

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?

Content summary is front-loaded before the usage/routing guidance, and the routing arrows are compact. It is slightly dense with multiple field names packed into the first clause, but no sentence is wasted.

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-format explanation is unnecessary. Between the annotations, full schema coverage, and the routing guidance, an agent has enough to invoke correctly; only minor behavioral detail is absent.

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

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

Schema coverage is 100%, so the schema documents each parameter, giving a baseline of 3. The description adds meaning beyond the schema by asserting that code/codes is mandatory for this tool even though the schema lists zero required parameters, clarifying the key parameter relationship.

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

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

States a specific verb and resource (集合竞价阶段逐笔数据) and enumerates the returned fields (历史分位、量比、涨停委买额、20分后涨停委买额). It explicitly differentiates itself from sibling tools by naming specific alternatives and their scope, so an agent can route without opening any schema.

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

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

Provides an explicit '何时使用' block with the trigger condition (单股/多股集合竞价明细) plus a hard constraint (必须传 code/codes). It also routes three distinct use cases to their correct alternatives: auction_market_scan, auction_theme_strength, and auction_opening_snapshot.

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

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive/openWorld), yet the description adds substantive behavior: non-trading-day fallback via the trading calendar with the actual date annotated, early-snapshot caveats (virtual matching amount must not be treated as final, coverage/time noted in dataTiming), and the AUCTION_DATA_NOT_READY state. These are non-obvious traits beyond structured 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?

Content is dense and mostly front-loaded, but the sibling routing ('昨涨停/昨炸板今表现请用 auction_opening_snapshot') and the snapshotTime 09:15/09:20/09:25 default are each stated twice, making the description noticeably redundant.

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

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

With 27 zero-required params at full schema coverage and an output schema present, the description only needs to cover routing, edge cases, and timing semantics, all of which it does. An agent has everything required to invoke it correctly, including non-trading-day and early-snapshot handling.

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

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

Schema description coverage is 100%, so the schema already carries per-parameter meaning and the baseline is 3. The description restates the snapshotTime enum/default and adds the 'virtual matching amount' caveat, but contributes little parameter meaning beyond what the rich schema already documents.

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

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

States a specific verb and resource: full-market auction scanning sorted/filtered by auction amount, limit-up buy orders, seal amount, change and volume ratio. It explicitly names the sibling tools it is not (auction_opening_snapshot, auction_theme_strength), so an agent can disambiguate without opening schemas.

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

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

The 何时使用 block declares the tool's role as the primary auction scanner and routes two adjacent use cases to named alternatives ('昨涨停/昨炸板今表现请用 auction_opening_snapshot；题材聚合用 auction_theme_strength'). When-to-use, when-not, and alternatives are all explicit.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world. The description adds real behavioral context beyond them: trade-date fallback for non-trading days, the AUCTION_DATA_NOT_READY condition, dataTiming coverage, and that early-second indicators are unavailable at 09:15/09:20. That is substantive operational disclosure.

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

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

The description is long and repetitive: it lists the fixed views twice with inconsistent counts (six then eight), duplicating the same enumeration. This redundancy wastes tokens and creates confusion rather than front-loading key constraints.

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

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

With an output schema present, return values need not be explained. The description covers date resolution, non-trading-day fallback, readiness errors, timing caveats, and a link-format instruction — enough for an agent to call it correctly for a complex multi-parameter tool.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters, establishing the baseline of 3. The description restates snapshotTime and limit behavior but adds little syntax or format detail beyond the schema, and its 'six buckets' framing conflicts with the eight-view list.

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

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

States a specific verb+resource: returning a fixed set of opening-auction snapshot views with full auction fields. An agent knows it is the 'panorama' auction snapshot, distinct from auction_data or auction_market_scan. But the description internally contradicts itself, first claiming six fixed views and later eight, which muddies exactly what the tool returns.

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

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

Provides a '何时使用' line framing it as the panorama snapshot and lists the supported snapshotTime values with their data-availability caveats. However, it never names an alternative sibling (auction_data, auction_market_scan, auction_theme_strength) or states when NOT to use it, leaving routing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the non-trading-day fallback to the previous trading day with the actual date annotated, and that explicit dates are not auto-rolled. It does not cover rate limits or error conditions like AUCTION_DATA_NOT_READY (only the schema does).

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

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

Front-loaded with the core behavior, then usage and date-edge handling in a logical order with no filler. It is dense and slightly repetitive (the aggregation scope is restated in the 何时使用 sentence), keeping it just under a 5.

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

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

With an output schema present and annotations covering safety, the description does not need to explain returns and doesn't. It covers source selection, watchlist scoping, and the trading-calendar edge case, leaving only minor gaps like error-state messaging. Complete for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, making 3 the baseline. The description reinforces key semantics (codes restricts aggregation to a watchlist, themeSource defaults to kpl, limit is top-N), but adds little that the schema does not already state, especially the minBidAmount/minMemberCount thresholds.

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?

It states a specific verb+resource: aggregating 集合竞价表现 by theme, with the default source (开盘啦题材) and switchable alternatives (CLS 概念/行业), plus the output fields (竞价额、平均涨幅、高开数量、龙头候选、一致性). This clearly separates it from market-wide siblings like auction_market_scan, though it stops short of naming those siblings explicitly.

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

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

An explicit 何时使用 block gives concrete scenarios and even the questions it answers ("今天竞价资金打哪条主线"、"我的自选股里哪个方向最强"). It lacks explicit when-not or named-alternative routing against auction_data/auction_market_scan, so it lands at 4 rather than 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?

Annotations already declare readOnlyHint/openWorldHint/idempotentHint/destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds semantics for the returned signals (sentimentSignal=cooling/neutral/warming as a 退潮信号) which is useful, but otherwise largely restates field names rather than disclosing new behavioral traits like data freshness or coverage limits.

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

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

Heavily redundant: the panel purpose, the trigger questions, the return fields (breakRate, avgBrokenPctChg, sentimentSignal, highBoardBroken, statusBreakdown) and the focus enum are each stated twice across the two paragraphs. The front-loaded summary is good, but the duplication bloats the definition and dilutes the signal.

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

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

With an output schema present, the return values need not be explained, yet the description still covers inputs, focus/minStreak/theme filters, and the analytical meaning of the results. It is complete for an 8-param optional-input analysis tool; only minor gaps around data scope/freshness remain.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters, making 3 the baseline. The description re-states focus/minStreak/theme usage but adds no format or syntax detail beyond what the schema already explains (e.g. accepted date formats are only in 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 names a specific cross-analysis (昨涨停 × 今日行情交叉) and enumerates the exact questions it answers (断板/续板/高标杀/退潮vs修复), plus the output fields it produces. This is far more specific than siblings like broken_limit_up or limit_up_ladder and lets an agent route correctly without opening the schema.

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

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

Contains an explicit 何时使用 section with concrete trigger phrasings ('昨天涨停今天断板的有哪些', '高标(≥3板)有没有被杀', '昨日连板淘汰率'), which is strong 'when to use' guidance. However it never states when NOT to use it or names an alternative sibling, so it stops 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds two genuine traits beyond that: the content is AI-generated (a provenance/quality caveat) and it spans four session variants. It says nothing about latency, rate limits, or authoritativeness of the generated data, so it adds some but not rich 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 text is short and the resource/session scope is front-loaded. However, the second sentence is essentially a verbatim restatement of the first with '何时使用' prefixed, so it does not earn its place.

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

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

With a full annotation set, a published output schema, and 100% schema description coverage on all four optional parameters, the description does not need to explain return values or defaults. It conveys scope adequately; only the missing usage/routing guidance keeps it from a 5.

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

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

Schema description coverage is 100%, including defaults for date (today), type (all), format, and detailLevel, so the baseline is 3. The description adds no parameter-level information whatsoever beyond what the schema already documents.

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

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

States a specific resource (AI-generated daily market briefing) with the covered sessions (opening/midday/closing/evening) and the payoff ('quickly grasp the day's key points'). It is clear what the tool produces, but it never distinguishes itself from adjacent siblings such as market_overview or market_replay_workflow, so it stops at a 4.

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 '何时使用' sentence ('AI-generated daily morning/midday/closing/evening briefing') merely restates the first sentence rather than stating a triggering condition. No alternatives, no when-not-to-use, no comparison to market_overview or news-oriented siblings is offered, so the agent gets no routing help.

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

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

Annotations already cover safety (readOnly, non-destructive, idempotent, openWorld). The description adds real behavioral value: real-time sourcing, the returned fields, and a hard output-formatting requirement (列股必须用 [name(code)](...) markdown 链接) that the agent must honor. No pagination or rate-limit detail, but the output schema covers shape.

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

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

Front-loaded with purpose, then usage, then the output/link requirement in three tight segments. Dense but every clause earns its place; the markdown-link rule is a necessary constraint rather than filler.

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

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

An output schema exists, so return values needn't be re-explained, and the description still clarifies the rows/items/nested-stock shape plus the link mandate. Slight ambiguity remains between the 实时/当日 framing and the required date parameter, but overall it is complete enough to call correctly.

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

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

Schema description coverage is 100%, so all six parameters (date, format, detailLevel, maxRowsPerLevel, includeFirstBoard, includeReasonInfo) are already documented. The description adds no syntax or meaning beyond the schema, so this sits at the 3 baseline.

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

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

States a specific verb+resource: 实时获取当日曾触及涨停但未能封住的炸板股列表, and names the fields it carries (最高封单、开板次数). This distinguishes it from sealed-limit siblings like limit_up_ladder, but it never distinguishes itself from the potentially overlapping board_break_analysis / limit_events.

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

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

Explicitly states 何时使用: 炸板池，判断市场分歧, and routes the agent to combine it with limit_stats. Clear context is given, but there is no explicit when-not-to-use guidance or exclusion against the near-synonym siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety behavior is covered. The description adds the 'linkage' requirement about markdown link formatting for stock mentions, which is behaviorally relevant output formatting guidance. However it doesn't disclose return structure details beyond what the output schema would carry. With annotations covering safety, 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 repetitive: the 何时使用 block restates the same routing information given in the first sentence almost verbatim (板块资金请优先 theme_intraday_capital / 盘中个股主力用 intraday_main_flow appear twice). The markdown-link instruction is buried at the end. This is bloated and not 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?

For a complex 10-param tool with an output schema, the description covers routing, scope, and the important output formatting requirement (markdown links). Since a schema exists it needn't explain return values, and safety annotations cover the rest. The redundancy means the information is present, just not efficiently structured.

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 baseline is 3. The description's narrative about flowType=sector compatibility and sectorSource=dongfang aligns with but largely restates schema enum descriptions. It adds context on the compatibility path but doesn't introduce 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 states a specific verb+resource: fetching capital flow data, with coverage scope (个股/大盘/北向 as 东财日频四档). It explicitly names sibling tools (intraday_main_flow, theme_intraday_capital) and identifies this tool's scope vs. them. Not quite a 5 because the purpose statement is densely embedded in routing guidance rather than cleanly front-loaded.

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

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

Explicit when-to-use rules with named alternatives: 盘中个股主力用 intraday_main_flow, 板块资金优先 theme_intraday_capital, and this tool's flowType=sector exists only for compatibility. It specifies the exception condition (sectorSource=dongfang) for East Money sector data. This is textbook 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?

The annotations already carry the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description adds genuinely non-structured behavior: every result carries a 'ref' field in markdown-hyperlink form and the agent is told to inline it rather than emit a References section. That is a real output-handling convention not derivable from annotations or schema. It does not cover pagination or rate/limit behavior, keeping it at 4.

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

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

The opening sentence ('实时电报快讯原文，支持按关键词、股票、消息级别、时间范围过滤') is repeated almost verbatim in the '何时使用' section, which wastes a large fraction of the text. The citation guidance is valuable and appropriately front-loaded, but the duplication prevents a higher score.

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

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

For an 11-parameter read tool, the description plus a 100%-covered schema, existing output schema, and rich annotations leave little ambiguity: filters, usage scenarios, and the ref-citation output convention are all covered. The only gap is that it never clarifies its boundary against other news/disclosure siblings, so 4 rather than 5.

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

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

Schema description coverage is 100%, so every one of the 11 parameters is already fully documented with examples (e.g. keyword='华为', hoursAgo semantics, date/hoursAgo precedence). The description only restates the filter categories at a high level and adds no parameter detail beyond the schema, which is the baseline-3 case.

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?

Names a specific resource ('实时电报快讯', real-time news flashes) with concrete filter dimensions (keyword/stock/level/time) and three concrete use scenarios. It is unambiguous what the tool returns and where it fits. It stops short of naming the adjacent siblings it must be distinguished from (news_hotlist, official_announcements), so it lands at 4 rather than 5.

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

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

An explicit '何时使用' section maps the tool to real workflows: pre-market news review, intraday catalyst tracking, per-stock news verification. That is clear context for selection. However, it never states when NOT to use it or points to a preferred alternative (e.g. official_announcements for filings vs. this for rolling flashes), so no exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds only the asset-class caveat and mode list, with nothing on caching, rate limits, or the cache-bypass nuance that the schema mentions. Useful but thin beyond the annotations.

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 core capability list and the '何时使用' section repeat the same enumeration ('转债搜索、正股映射、实时快照、涨幅/成交额排行、日线、分钟线和转股溢价率' appears twice), wasting space. The asset-class warning is valuable, but the duplication means not 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?

Covers the tool's scope and asset-class boundaries, and with an output schema present it needn't explain return values. For a 14-parameter multi-mode tool with annotations covering safety, it is nearly complete, though it could clarify how modes interact with the optional filters.

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 14 parameters are each documented, including mode enum behavior, defaults and sortBy fields. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific resource (可转债) with concrete capabilities: search, underlying-stock mapping, realtime snapshot, gain/turnover ranking, daily and minute bars, conversion premium rate. It explicitly distinguishes itself from siblings by warning '可转债是独立资产，不要当作股票涨停或股票筛选工具使用', clearly separating it from limit_up and stock_screener.

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

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

Gives explicit when-to-use (可转债行情工具) and a clear when-not ('不要把可转债当股票涨停工具使用'), routing the agent away from the stock limit-up/screening tools. The misuse exclusion is stated up front rather than left to inference.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond them: the BranchTag reverse-lookup that auto-expands a 游资 name to its constituent 营业部, the date-range scan behavior, and a mandatory markdown-link output convention. No contradictions.

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 branchSearch-vs-stockName warning is repeated three times in slightly different wording, and the BranchTag expansion is explained twice. The core instruction is front-loaded, but the redundancy inflates length without adding information an agent 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?

For a 10-parameter, zero-required tool with a full output schema, the description covers the key selection paths (branch/stock/date-range), output formats, and the link-formatting requirement, so the agent can invoke it correctly. Return values are rightly left to the output schema. No critical gap remains.

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 branchSearch schema field already documents the BranchTag reverse-lookup and keyword types, so the description largely restates it. It adds only marginal meaning (pairing branchSearch with startDate/endDate, stockCode vs stockName), which justifies the baseline-3 rather than a higher score.

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

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

States a specific resource and scope: '龙虎榜买卖席位详情' (dragon-tiger list buy/sell seat details), and explicitly distinguishes its two search modes (游资/营业部 via branchSearch vs 个股 via stockCode). The intent is clear, though the point is buried inside dense, repetitive prose rather than a crisp opening line.

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

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

Explicitly covers when to use ('何时使用: 龙虎榜席位和机构/活跃资金'), when NOT to use a parameter ('按游资名/营业部追踪必须用 branchSearch，不要用 stockName'), and names an adjacent sibling ('配合 limit_up_ladder'). Worked examples ('炒股养家最近一周操作', '三亚迎宾路上榜没') make the selection criteria unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only the domain fact that ETFs are an independent asset class; it discloses nothing about caching, rate limits, or freshness behavior (that detail lives in the forceRefresh param description instead).

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

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

Front-loading is good, but the description duplicates itself: the list of query modes appears twice, and the 'don't put ETFs in stock_screener' warning is repeated twice with different wording. That redundancy costs space without adding information.

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

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

For a 14-parameter, zero-required multiplexer with an output schema and full schema coverage, the description only needs to convey scope and routing, which it does. The mode-to-parameter interactions (e.g. startDate/endDate only matter in daily) are left entirely to the schema, which is acceptable here.

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 every parameter is self-documented, so the baseline is 3. The description restates the mode list that the mode enum already documents and adds no syntax, default, or interaction detail beyond the schema.

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

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

It names a specific verb and resource (query ETF search, real-time snapshot, gain/turnover rankings, daily and minute bars) and explicitly carves the ETF asset class out from stock_screener, which is the main source of ambiguity among siblings. However, it does not distinguish itself from other bar-data siblings such as kline, minute_data, or index_market, and the same mode list is restated verbatim later in the text.

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 '何时使用' block gives an explicit use condition and an exclusion — don't route ETF conditional queries to stock_screener — which is exactly the routing decision an agent faces here. It stops short of saying when to prefer this over kline/minute_data or index_market for the overlapping time-series modes.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scope of aggregation (which statements feed the summary), but discloses nothing about permissions, rate limits, or response behavior, so with annotations carrying the burden a 3 fits.

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?

Compact and front-loaded: the aggregation scope comes first, followed by a labeled 何时使用 line. Every clause carries information with no filler.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety. The description gives purpose and usage conditions adequately for a complex 8-parameter tool; only the absence of sibling routing keeps it from a 5.

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

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

Schema description coverage is 100%, so all eight parameters (code, limit, format, dates, sections, embedStock, detailLevel) are already documented in the schema. The description adds no syntax or format detail beyond that, making the baseline 3 appropriate.

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

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

States a specific verb (聚合/aggregate) and enumerates the exact resources combined (income statement, balance sheet, cash flow, financial indicators, audit opinions, main business composition) to produce an individual-stock fundamental summary. This makes it clearly identifiable against siblings like sec_company_facts or valuation_snapshot without opening a schema.

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

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

Explicitly gives when-to-use (revenue/profit/cash flow/ROE/audit/main business composition) and a when-not-to-use exclusion ('纯短线问题不用'). It stops short of naming specific alternative sibling tools for fundamental or short-term data, so it lands at 4 rather than 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered; the description adds real behavioral context beyond that — real-time snapshot, rank and intraday minute modes read continuously persisted site data and will not cold-fetch on a single call, and forceRefresh bypasses cache but still cannot trigger a live refresh. It stops short of documenting rate limits or latency expectations.

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 and mode list are front-loaded and the description is organized into a scope statement followed by a 何时使用 block. However, the turnover guidance ('两市成交额及量能变化… marketTurnoverSeries') is stated twice, which is wasted space in an already dense paragraph.

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

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

An output schema exists, so return values need not be re-explained; the description instead covers the things structure cannot — data freshness semantics, mode selection, sibling routing, and the amountScope caveat. For a zero-required-param, 14-parameter tool this is complete enough to invoke correctly.

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

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

Schema description coverage is 100% with all 14 params documented, so the schema carries the baseline. The description still adds value by scoping which mode each input belongs to (daily/minute 建议显式传入 symbols, snapshot/rank keyword as filter) and by warning against mixing rows of differing amountScope, which is a semantic constraint not expressed in 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 states a specific verb+resource (查询指数：搜索、实时快照、排行、日线、分钟线) and enumerates the five modes mirroring the schema enum, so an agent knows exactly what surface it covers. It also explicitly distinguishes itself from siblings index-adjacent tools by naming market_overview and short_term_emotion as the wrong choices for breadth/emotion questions.

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 contains a dedicated 何时使用 section giving the trigger conditions (三大指数/宽基/行业指数点位、涨跌幅、成交额排行、日线分钟线) and the exclusions ('不要用 market_overview 或 short_term_emotion 代替', '不要自行混加不同 amountScope 的指数行'). It also routes two-market turnover questions to summary.marketTurnover / marketTurnoverSeries, which is an actionable alternative.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so safety is covered. The description adds real behavioral value by defining the measurement caliber (开盘红 main-net, not the traditional four-tier order flow) and the required markdown link format for listed stocks — context not present in structured fields. Pagination/rate behavior is not discussed, but the output schema exists.

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?

Purpose is front-loaded, but the caliber clause ("开盘红...不是传统四档大/中/小单资金流") is stated twice — once in the opening and again inside 何时使用 — which is redundant. The link-format note is useful, yet the overall text could be tightened 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?

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description still conveys purpose, trigger conditions, the key alternative to avoid, and the caliber distinction, leaving little essential information missing apart from minor efficiency/detail notes.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters (codes, limit, order, format, sortBy, keyword, tradeDate, detailLevel). The description echoes the codes filter use case but adds no per-parameter syntax or defaults beyond the schema, making this the baseline 3.

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

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

The description gives a specific verb+resource ("查询盘中个股主力资金快照") plus an explicit scope qualifier ("口径为开盘红盘中主力净额"). It directly contrasts itself with the sibling capital_flow, so an agent can disambiguate without opening either schema.

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

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

There is an explicit "何时使用" section naming the trigger scenarios (盘中主力净额、大单净额、竞价主力净额) and a when-NOT clause ("不要改用 capital_flow"). The routing instruction is unambiguous.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds real behavioral nuance beyond them: qfq is computed from a local 昨收参考价 factor定基于截止日, covers dividends/配股 without pulling in post-endDate corporate actions, and warns the agent to inspect qualityWarnings and watch for global response-budget truncation on large batches.

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

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

Front-loaded with the core verb+resource before the 何时使用 block, and every section carries actionable content. The trailing 【链接】 paragraph is a slightly jarring tack-on and the whole text is dense, but nothing is padding.

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

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

With an output schema present the description needn't explain return shape, and it correctly focuses on batching constraints, adjustment caveats and quality warnings. It is nearly complete for a 9-param tool; only the exact interplay of days vs maxRows (must be passed together) is left mostly to the 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 description coverage is 100%, so baseline is 3; the description's adjust/codes/days remarks largely restate what the schema already documents. The one addition with real value is the output-formatting requirement that listed stocks use `[name(code)](...)` markdown links, which hints at handling rather than parameter meaning.

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

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

Opening line states a specific verb+resource: 获取个股日K线数据, with the scope modifiers that matter (盘中实时融合, 自定义天数, adjust). It also positions itself as the 日K线原子工具, implicitly separating it from minute_data and admission/auction siblings.

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

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

Explicit '何时使用' with concrete target workloads (区间涨幅、阶段高低点、价格分位、放量倍数等窗口型条件) and batch guidance (多股分析优先用 codes 而不是逐股调用). No explicit when-not or named sibling alternative, so it stops short of 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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's added value is real: it discloses real-time retrieval, the embedded data fields, and a mandatory output-format rule (stocks in lists must be rendered as markdown links `[name(code)](url)`). That formatting constraint is behavioral guidance not derivable from annotations or schema, though no rate limits or pagination behavior are described.

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?

Purpose is front-loaded, which is good, but the description crams purpose, usage, and an output-format mandate into dense run-on clauses, and the 【链接】 block sits awkwardly apart from the rest. It is compact but not cleanly structured.

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

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

An output schema exists, so return values need no explanation, and all parameters are schema-documented. The description supplies purpose, analytical use, and the markdown-link rendering rule, which is enough for a 6-param read-only tool. It could still note how it relates to adjacent limit-down tools to be 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 all six parameters (date, format, detailLevel, maxRowsPerLevel, includeFirstBoard, includeReasonInfo) are documented inline, so the schema carries parameter semantics fully. The description's mention of rows/items/nested code-name objects is output-structure guidance, not parameter meaning, so it adds nothing parameter-specific. Baseline 3.

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

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

States a concrete verb+resource: 实时获取当日跌停股池 (real-time retrieval of today's limit-down pool), plus the fields it carries (跌停原因、封单金额). This unambiguously distinguishes it from the many limit-up siblings since the resource is the down-side pool. It stops short of naming any sibling it should be chosen over, so not a 5.

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

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

The '何时使用' clause gives an analysis context (跌停池和负反馈分析 / negative-feedback analysis), which is better than nothing. But it is largely circular — telling the agent to use the limit-down tool for limit-down analysis — and gives no exclusions or named alternatives (e.g. broken_limit_up for 炸板). Implied usage only.

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

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

Annotations already declare readOnlyHint/ idempotentHint/ openWorldHint and non-destructive, covering the safety profile. The description adds genuine context: real-time event-stream semantics, second-level timestamps, and the required markdown-link format for stocks — behavior beyond the annotations, though it doesn't mention rate limits or staleness of the stream.

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

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

Front-loads purpose, then usage, then output-format rules in clearly delimited segments. Efficient and structured, though the bracket markers make it slightly dense.

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

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

With an output schema present, return values needn't be described, and the description still adds the essential cross-tool routing and link-formatting requirement. Complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so type/limit/order/format/sinceTime/eventTypes/detailLevel are all documented in the schema itself. The description adds little parameter-level meaning, so the baseline 3 is appropriate.

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

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

States a specific verb+resource: real-time push of limit-up sealing (封板) and breaking (炸板) events with second-level timestamps for intraday monitoring. It explicitly names the sibling it is not (limit_up_ladder), so an agent can distinguish them without opening schemas.

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

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

Provides explicit '何时使用' guidance: use only when the user explicitly requests real-time events or latest sealing, otherwise use limit_up_ladder. The condition and the alternative are both spelled out, and the schema further routes limit-down queries to limit_down.

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

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

Annotations already declare the safe, read-only, idempotent profile, so the bar is low. The description adds useful non-structured context: the returned data is nested stock objects carrying code/name, and any listed stock must be rendered as a markdown link — a mandatory output requirement an agent would not otherwise know.

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 text is dense but front-loaded: purpose first, then usage, then the linking/format rule. There is no wasted filler. The only minor cost is that the output-format rule is bundled into the same block as usage guidance, slightly blurring structure.

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 10-parameter tool with an output schema and safety annotations already in place, the description covers purpose, routing, and the non-obvious output-format obligation. The absence of explicit sibling differentiation and any return-shape summary beyond the link rule are the only remaining gaps.

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

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

Schema description coverage is 100% across all 10 parameters, so each parameter's meaning (topN, bucketMinutes, detailLevel, coreOnly, etc.) is already documented in the schema. The description adds little parameter-level semantics beyond noting the nested output shape, so the baseline of 3 applies.

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

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

The description states a specific verb+resource — aggregating the limit-up/break event stream and extracting named signals (最早首封、最多炸板、最多回封、尾盘事件、分时情绪拐点). This is far more precise than a tautology. However, it never explicitly contrasts itself with close siblings such as limit_events or board_break_analysis, leaving that discrimination to the agent.

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

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

It gives an explicit when-to-use list (盘中分歧/炸板潮/尾盘事件/反复回封等过程分析) and an explicit when-not (普通复盘不需要), which is strong routing guidance. It stops short of naming a concrete alternative tool for the excluded case, so it is clear context rather than full when/when-not/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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuine non-obvious behavior: data source routing (local close statistics for historical dates) and defined behavior on non-trading days. Return format is not described but an output schema exists, so this is a meaningful addition.

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 dense block that front-loads purpose, then the when-to-use condition, with no redundant sentences. It is packed with delimiters rather than wasted prose, though the transition between purpose and usage could be slightly cleaner.

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?

Covers purpose, usage conditions, and non-trading-day edge behavior; an output schema exists so return-value explanation is rightly omitted. For a 3-param, one-required read tool this is essentially complete, with only explicit sibling exclusions missing.

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

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

Schema description coverage is 100%, so date format, format, and detailLevel are already documented in the schema. The description adds no syntax, default, or interaction detail beyond what the schema provides. Baseline 3 applies when the schema carries the full parameter burden.

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

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

States a specific resource (实时涨跌停统计) and enumerates concrete outputs: 封板数, 炸板数, 封板率, 今日vs昨日对比. This distinguishes it from event-level siblings like limit_events and broken_limit_up, which report individual events rather than aggregate strength metrics. It stops short of an explicit negative boundary ('do not use for X').

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?

Has a dedicated 何时使用 clause that names the authoritative caliber (涨跌停/炸板/封板率) and states edge-case routing: historical days read local close stats, pre-market/non-trading days return an explicit status. It also names companion tools (market_overview, limit_up_ladder), giving clear context. No explicit when-not-to-use or alternatives is given, so not 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered and the description is not required to restate it. What it does add is unit conventions (元 / %), the primaryTheme output field, and the downstream-handoff behavior; however, most of those units are also in the schema descriptions, and there is no disclosure of rate limits, latency, or pagination behavior in natural language.

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 and downstream usage are front-loaded, and the bracketed 【链接】 formatting rule is a genuinely useful addition. However, the '何时使用' section duplicates the opening paragraph almost verbatim, so a substantial share of the text does not earn its place and inflates the description without adding information.

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

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

For a 39-parameter tool with 100% schema coverage, no required parameters, and an output schema, the description covers what is left to say: the rows shape (date/code/name + event fields), unit conventions, and the downstream workflow. Mode interactions (e.g. pattern disabling other filters) live in the schema, which is acceptable, but the missing sibling differentiation leaves one gap.

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

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

Schema description coverage is 100%, so the schema already carries all 39 parameter meanings, including enum explanations for breakMode, changeTag, pattern and conceptTagsMode. The prose only re-lists categories of filters generically and adds no syntax, defaults, or edge-case semantics beyond the per-parameter descriptions. Baseline 3 is the correct ceiling here.

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

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

States a specific verb+resource (按日期/区间筛选涨停记录) and enumerates the filterable event fields, so the agent knows exactly what this tool does. It also names downstream consumers (kline, valuation_snapshot, stock_screener), which helps position it, but it never distinguishes itself from the closest siblings in the family (limit_events, limit_up_ladder, broken_limit_up, approaching_limit_up), so the agent must infer the boundary.

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 a '何时使用' heading, but its body restates the capability list rather than stating when to pick this tool over the other limit-up siblings. The only real routing guidance is downstream-oriented (use the rows as a candidate pool for kline/valuation_snapshot/stock_screener) and the note that firstLimitUpTimeText is preferred when describing seal times. No when-not conditions or sibling exclusions are given.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's job is to add context — and it does: it names a return field (primaryThemeStats, aggregated by 开盘啦 main category), warns that firstLimitUpTime/lastLimitUpTime are raw timestamps with Text variants preferred for user-facing封板 times, and mandates markdown-link formatting. It does not discuss pagination or data latency, but this is solid added behavioral detail.

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

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

Front-loads purpose, then usage keywords, then return-field and link-format constraints — every clause is actionable for an agent. Dense but no filler sentences.

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

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

With annotations carrying the safety profile, an output schema covering return values, and 100% param description coverage, the description's added output-field and formatting guidance makes the definition sufficient. Only minor gaps remain (no sibling-vs-sibling exclusion, no data freshness note).

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema, and the description adds no parameter-level syntax or defaults beyond that. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource+scope: real-time display of limit-up stocks layered by consecutive-board height, exposing the ladder structure and promotion path. It names the concept unambiguously enough to distinguish it from siblings like limit_stats or dragon_tiger, which it explicitly references as companions.

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?

Includes an explicit '何时使用' clause (limit-up ladder, consecutive-board height, leader structure) and says to pair it with limit_stats and dragon_tiger. It gives clear context for selection but never states when NOT to use it or how it differs from e.g. limit_up_filter or broken_limit_up.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds valuable non-obvious context: the 'not a real-time signal' caveat and the required markdown-link format for constituent stocks, which constrains how results must be rendered.

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

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

Front-loads the core purpose in the first clause, then usage, then output-format constraint. Three compact segments with no filler, though the markdown-link instruction is dense and slightly detachable from the purpose statement.

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

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

With annotations covering safety and an output schema covering returns, the description only needs to add the non-obvious pieces, and it does: the non-real-time caveat and the mandatory link formatting for listed stocks. Minor gap in not clarifying result ordering semantics or date-range constraints.

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

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

Schema description coverage is 100%, so every parameter (page, limit, format, sortBy, endDate, sortOrder, startDate, detailLevel, minLimitUpCount) is already documented in the schema. The description only hints at return structure (rows/items with code/name) rather than adding meaning to any parameter, so the baseline 3 applies.

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

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

States a specific verb and resource: statistics of next-day premium returns ranking for limit-up stocks, plus quantifying win rate/profit-loss ratio of the '打板' strategy. An agent can distinguish it from limit_up_ladder or limit_stats by the next-day premium focus, though no sibling is named explicitly.

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

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

Explicitly gives 何时使用 (next-day premium and historical win-rate statistics) and a when-not condition (不能单独作实时信号 — cannot be used alone as a real-time signal). Clear context, but does not route to a named alternative for real-time needs.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and idempotency profile is fully covered. The description adds useful context that this is a multi-step composite workflow and that the default return mode is digest, but that default is also already stated in the schema, so added behavioral value is modest.

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

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

Two sentences, front-loaded with the package contents before the usage guidance, so an agent gets the 'what' first. There is mild redundancy between the opening content list and the 何时使用 list of the same items, but it is compact and wastes little space.

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 a workflow tool with 9 optional parameters, no required params, and a rich schema plus an existing output schema, the description covers what the package contains, when to use it, and the key conditional flags, so return values need not be explained here. It is complete enough to invoke correctly, with only the sibling-alternative routing left implicit.

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

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

Schema description coverage is 100% with all 9 parameters documented, so the schema carries the semantic load; the baseline is 3. The description restates includePremium and includeEventSummary conditions, which map to those params but do not add meaning beyond the schema text.

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 (一键生成) with a clearly scoped resource (涨停板复盘数据包) and enumerates exactly what the package aggregates: 涨跌停统计、涨停梯队、涨停主类排行、炸板池、跌停池. This lets an agent distinguish it as a composite one-shot review tool from single-purpose siblings such as limit_stats, limit_up_ladder, limit_up_premium, broken_limit_up, and limit_down.

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?

A dedicated '何时使用' clause states the scenario (一键涨停复盘 across 统计/梯队/题材/炸板/跌停), and it adds a conditional rule for opening includeEventSummary during 盘中事件分析 while noting 普通涨停复盘不需要. It does not, however, explicitly name single-purpose siblings as the alternative when only one slice is needed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only a scope boundary and nothing about defaults (e.g. the 14-day window, format/output behavior) beyond what the schema states; it 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?

Purpose is front-loaded, but the description repeats itself: the opening sentence and the '何时使用' sentence restate the same coverage and use case with near-identical phrasing, and the same example ('未来几天有哪些重要经济数据') appears twice. Some redundancy costs 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?

An output schema exists, so return values need not be described, and all ten params are fully documented at 100% coverage. Combined with annotations covering safety, the description supplies purpose, usage and scope boundaries, leaving little an agent needs missing.

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

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

Schema description coverage is 100%, so every one of the ten parameters is already fully documented with types, defaults and formats. The description reinforces country/currency/keyword filtering but adds no syntax or meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource ('查询全球宏观财经日历') and enumerates the covered domains (经济数据、央行/机构事件、国家/货币维度). It bounds scope by noting it does not cover industry conferences and product launches, which helps distinguish it from calendar siblings, though it never names an alternative tool.

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?

Contains an explicit '何时使用' section and a concrete example use case ('未来几天有哪些重要经济数据/央行事件'), plus a negative exclusion ('不覆盖全部产业大会和产品发布'). This is strong when-to-use guidance, but it stops short of naming sibling tools like market_catalyst_calendar or stock_event_calendar as the alternative to prefer.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the response shape is polymorphic (summary vs. per-stock detail) depending on whether code is supplied. It does not discuss pagination or date-range limits, so it is not a full 5.

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

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

The core branching logic is front-loaded, but it is stated twice in near-identical form ('传 code 返回 margin_detail，不传 code 返回交易所汇总' then again in the 何时使用 clause), which is avoidable repetition for a tool whose schema already documents the same rule.

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

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

An output schema exists, so return values need not be explained; annotations cover the safety profile; and the description supplies the usage context and mode-selection rule. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema, including the code branch and the tradeDate vs. startDate/endDate exclusivity. The description restates the code branch without adding syntax or format detail beyond the schema, 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?

States a specific verb and resource (query margin trading market summary / individual-stock details) and encodes the polymorphic contract: code present returns margin_detail, absent returns exchange-level margin. This distinguishes it clearly from siblings like capital_flow or dragon_tiger, which cover different capital dimensions.

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?

An explicit '何时使用' section states the usage context (leverage-capital crowding, margin balance shifts, securities-lending pressure) and the code-vs-no-code branch that selects the mode. It stops short of naming an alternative tool or a when-not-to-use case, so it is clear context without 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety and idempotency profile is covered without description help. The description adds the scope exclusion (not announcement full text) but says nothing about pagination, date-default behavior, or rate limits beyond what the schema states. With annotations carrying most of the load, 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 text is redundant: the opening sentence listing catalyst categories is repeated almost verbatim inside the '何时使用' section, and the sample user query appears twice. Nothing is wrong in content, but roughly half the length is duplicated rather than front-loaded with new information.

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

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

For a 10-parameter read-only tool with an output schema, full schema coverage, and rich annotations, the definition covers purpose and trigger conditions adequately. The remaining gap is sibling disambiguation against macro_calendar/stock_event_calendar, which matters given how many calendar tools exist. Otherwise an agent can call this correctly.

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

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

Schema description coverage is 100%, so every parameter (date/startDate/endDate ranges, type enum, limit, format, country, keyword, minStar, detailLevel) is already documented in the schema. The description adds no syntax, format, or defaulting detail beyond it. Baseline 3 when the schema does the heavy lifting.

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

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

The description names a specific verb+resource: querying future catalyst events across policy meetings, industry conferences, product launches, index adjustments, economic data, and holidays. It also draws one explicit boundary (not company announcement original text), which separates it from official_announcements. However, it never distinguishes itself from the close siblings macro_calendar or stock_event_calendar, which cover overlapping calendar semantics.

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

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

It gives a clear usage condition: use when the user asks what short-term catalysts/conferences/launches/policy effective dates fall in the coming days, and it explicitly excludes announcements. That is real routing guidance, but no alternative tool is named for the boundary cases (e.g., macro_calendar for pure macro data, stock_event_calendar for per-stock events), so the agent must still guess on adjacency.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: non-trading-day fallback to the previous trading day with a 'fallback' marker, and a specific MARKET_SUMMARY_NOT_READY error instead of silently returning stale prior-close figures.

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 data scope is front-loaded, but the limit_stats routing instruction is duplicated verbatim (it appears in the opening clause and again at the end), and the fallback behavior is restated in both description and schema. Tightening would remove a full sentence with no loss of 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 annotations covering the safety profile, the description only needs to cover selection and edge behavior, which it does (when-to-use, sibling routing, date fallback, not-ready error). Minor gap: it never clarifies how this differs from other market-level siblings such as index_market or short_term_emotion.

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

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

Schema description coverage is 100%, so the schema already documents date, format, and detailLevel, including the same fallback wording the description repeats. The description adds no new parameter semantics (format and detailLevel are untouched), so this is the baseline 3.

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

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

The description names a specific resource set — real-time whole-market advancing/declining counts and market thermometer (breadth data) — and explicitly routes limit-up/limit-down/board-break definitions to the sibling limit_stats, so an agent can separate it from limit_stats or index_market. It lacks an explicit verb, but the resource scope is concrete enough to be 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?

There is an explicit '何时使用' (when to use) clause and an explicit alternative for a confusingly adjacent sibling ('涨跌停/炸板口径请用 limit_stats'). However the alternative is stated twice and there is no statement of when NOT to use or of other overlapping siblings (index_market, short_term_emotion), so it falls short of a full when/when-not/alternatives treatment.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds default behavior notes ('股票/资讯热榜默认不跑', '默认 digest'), but these largely restate defaults already documented in the input schema, so the added value beyond structured data is minimal.

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, followed by a compact usage section. The enumeration of components is necessary to convey scope, and the sentences are efficient, though the usage portion slightly repeats schema defaults with '默认 digest'.

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 is a complex workflow with six optional parameters and a dedicated output schema, the description adequately covers purpose and usage context. It does not need to explain return values (output schema exists) nor safety (annotations cover it), but it could have mentioned the internal dependency on trading_calendar for date resolution (currently only in the schema) to better set expectations.

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

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

Schema description coverage is 100%, so all six parameters are fully documented in the schema itself. The description only reinforces the includeHotlist condition and default digest mode, which are already present in the schema parameter descriptions; it adds no new semantic detail 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?

States a specific verb and resource: '一键生成 A 股市场复盘数据包' and enumerates the included components (trading day, market overview, limit up/down stats, ladder, theme rankings, briefing). This clearly distinguishes it as a composite workflow, though it does not explicitly name sibling workflows like limitup_review_workflow to further differentiate.

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

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

Provides an explicit '何时使用' section with the primary use case ('一键 A 股复盘：温度/宽度/涨跌停/梯队/题材/简报') and a conditional instruction for enabling includeHotlist ('问题问到题材为什么热时再开 includeHotlist'). It lacks guidance on when not to use this tool or how it relates to alternative siblings, but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds that historical dates preferentially read single-stock archives, but this behavior is already documented in the tradeDate parameter schema; no auth, rate-limit, or freshness details are added.

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 short, front-loads what the tool does, and follows with a when-to-use note. It has a minor redundancy, repeating the historical archive preference twice, but overall it is efficiently structured.

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 output schema exists and parameter descriptions are complete, the description need not explain return values. It covers purpose and when to use adequately, though it leaves a gap in sibling selection by not differentiating from kline or intraday_main_flow.

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

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

Schema description coverage is 100%, so all six parameters are fully documented in the schema. The description only restates the tradeDate usage pattern, which is already in the parameter description, and adds no syntax or format guidance beyond the schema.

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

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

The description states a specific verb and resource: 获取个股实时或指定交易日分时走势, and lists returned data (价格、均价、成交量). It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as kline or intraday_main_flow.

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 an explicit 何时使用 section: use for real-time intraday trend during trading hours, and pass tradeDate for historical queries that read from the single-stock archive. It gives clear context but does not state when not to use the tool or name alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that data is aggregated across全网 and financial media sources - useful scope context but no freshness, source coverage, or rate-limit detail, so it clears the (lower) annotated bar without being 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?

Two short clauses, front-loaded with the resource and scope, then the usage note. Slightly redundant - '观察资讯关注度和潜在题材线索' is restated as '观察消息面温度和潜在题材线索' - but there is no padding or boilerplate.

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 five fully documented optional parameters, a rich enum set, an output schema, and annotations covering the safety profile, the description supplies enough to call the tool correctly without restating return values. The one real gap - no differentiation from the many sibling news/hotlist tools - is a routing issue rather than a completeness one.

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

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

Schema description coverage is 100%, with limit, format, category, platform and detailLevel all documented in the schema, including enum meanings and defaults. The description adds nothing about parameter behavior, so the baseline 3 applies - the schema carries the entire parameter burden.

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 concrete verb+resource: aggregating all-network hot topics and financial-media rankings, with the goal of watching news sentiment and potential theme leads. That is clear enough to identify the tool. However, it never distinguishes itself from close siblings such as smart_hotlist, cls_news, or briefings, leaving the agent to guess which hotlist/news tool applies.

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 an explicit '何时使用' section naming the scenario (all-network / financial media hot-topic rankings, gauging news temperature). That is more than implied usage, but it offers no when-not-to-use conditions and names no alternative tool, so routing between news_hotlist, cls_news and smart_hotlist is left entirely to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds one genuine behavioral fact beyond annotations: the next-trading-day data update lag, which matters for interpreting results. It offers nothing further (no rate limits, coverage windows, or freshness for historical ranges).

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?

Purpose is front-loaded and the two sentences are compact. There is mild redundancy across the two paragraphs (沪深股通持股明细 is restated, and the code behavior appears in both the first sentence and the schema), which slightly dilutes efficiency but does not obscure anything.

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

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

With an output schema present, return values need no explanation, and all 8 params are documented. The description covers the dual query modes, market filter, and data-update timing, leaving only minor gaps (e.g., which sibling to prefer for related foreign-flow questions).

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

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

Schema description coverage is 100%, so the schema already documents every parameter including code, marketType (SH/SZ), tradeDate vs startDate/endDate exclusivity, and detailLevel. The description largely restates code and marketType semantics rather than adding new meaning, so the baseline 3 applies.

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

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

States a specific verb (查询) and resource (沪深股通持股明细) and explains the dual-mode behavior: passing code returns per-stock northbound history, omitting it returns whole-market detail by date. An agent can immediately tell this is the northbound/Stock-Connect holdings tool, distinct from generic capital_flow or shareholder_structure siblings.

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 '何时使用' block gives clear context (northbound holdings; judge foreign capital position changes) and a useful freshness caveat ('数据通常下个交易日更新'). It does not, however, name explicit alternatives or when-not-to-use conditions among the many siblings.

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

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

Annotations already declare read-only, idempotent, open-world behavior, so the safety profile is covered. The description adds real operational context beyond that: live mode is slower, auto mode falls back, rows carry matchedKeywords, and — importantly — an output formatting requirement (markdown link for stock codes) that the agent must follow.

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

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

Front-loaded and readable, but the default/site-record vs live/auto behavior is stated twice — once in the opening paragraph and again under 何时使用 — which is genuine redundancy for an otherwise tight description.

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

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

With 20 parameters, no required fields, an output schema, and full annotation coverage, the description supplies the decision-relevant extras an agent needs: mode selection rules, multi-keyword behavior, and a mandated output link format. Only the duplicate mode explanation and lack of return-shape hints (mitigated by the output schema) keep it short of perfect.

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

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

Schema description coverage is 100%, so the schema already documents all 20 parameters, including verificationMode, keywords, and the stock aliases. The description largely restates the same mode semantics rather than adding syntax or format detail beyond the schema, so baseline 3 applies; the link-format note is output guidance, not a parameter clarification.

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

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

States a specific verb+resource (查询上市公司正式公告) and a clear scope: official announcements for listed companies, with date/keyword/stock filtering. An agent can distinguish it from news-oriented or filing-oriented siblings even though no sibling is named explicitly.

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

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

Gives explicit when-to-use guidance and names the alternative modes with their selection conditions: default site records, live only when the user explicitly requests official-site verification, auto only for fallback when site records are missing. Nothing about mode choice is left 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?

With readOnlyHint/idempotentHint already covering the safety profile, the description adds real behavioral context: default reads station-internal records, auto backfills from the official site on misses, and live is slow and reserved for explicit requests. This is useful operational detail beyond the annotations.

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?

Purpose is front-loaded, but the description is noticeably redundant: the verificationMode auto/live behavior and the keywords support are stated both in the opening and again in the 何时使用 block, which largely repeats the purpose. The 【链接】 formatting note is valuable but the overall text wastes space on duplication.

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

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

With an output schema present and 100% schema coverage, the description needn't explain return values, and it does add the markdown-link formatting requirement plus mode behavior. It is essentially complete for calling the tool, with only minor redundancy.

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 every one of the 15 parameters is already documented in the schema, so the description adds little parameter meaning. It restates the keywords and verificationMode semantics already present in the schema, warranting the baseline 3.

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

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

States a specific verb (聚合/aggregate) and resource (官方公告和官方互动问答) scoped to a single stock, and the aggregation aspect distinguishes it from the separate official_announcements and official_interactions siblings. An agent can tell what it returns without opening the schema.

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

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

An explicit 何时使用 section plus mode guidance ('verificationMode=live 较慢，仅用于明确要求') tells the agent when to pick live vs default. It does not name the sibling tools (official_announcements/official_interactions) or say when to prefer them individually, so it falls 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds real behavioral value: the latency tradeoff of live verification and the fallback semantics of auto mode, which are not visible in the annotations.

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

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

Front-loaded with purpose, but the verificationMode tradeoffs and the keywords/matchedKeywords behavior are each stated twice (body plus 何时使用), and the trailing 【链接】 formatting block sits oddly at the end of a query-tool description.

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

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

With an output schema present, return-value explanation is unnecessary, and 100% schema coverage means parameters are well documented. The description covers purpose, default behavior, and verification tradeoffs sufficiently for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, and the enum/param semantics are repeated here (keywords, verificationMode, matchedKeywords) rather than extended. Baseline 3 applies since the schema carries the load and the description mostly reinforces it.

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

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

States a specific verb and resource: querying official investor Q&A (深交所互动易/上证 e 互动问董秘数据). It is clearly distinct from the 公告-oriented siblings like official_announcements and official_disclosure_evidence, though it never names those siblings explicitly.

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

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

Gives an explicit 何时使用 section and spells out the switching condition for verificationMode (default station records; live only on explicit user request; auto when records are missing). It stops short of naming an alternative tool to use instead, so it is strong context but not full when/not-when/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?

Annotations already declare readOnly/idempotent/open-world/non-destructive, so the safety profile is covered. The description adds genuinely non-annotated context: the output-link convention that stock mentions must be rendered as markdown links using code/name—a real behavioral requirement for the agent. Pagination/rate-limit behavior is left unstated, preventing a 5.

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