lianban-a-share-review

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

No annotations provided, so description bears full burden. It lists returned data categories and mentions optional date parameter but omits behavioral details like authentication, rate limits, or side effects. The tool is read-only, but this is inferred rather than stated.

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

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

The description is one moderately long sentence but packs significant detail concisely. It front-loads the purpose and then lists KPIs. Could benefit from bullet points for clarity, but overall efficient.

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

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

Despite lacking output schema, the description enumerates return components (KPIs, ladder, topics, AI text) adequately for an agent to anticipate results. Complexity is low (single optional param, no nesting) and coverage is sufficient.

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% with thorough description. The tool description reiterates the date default behavior but adds no new parameter semantics beyond citation note, which is not parameter-specific. Baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves complete A-share daily review data, listing specific KPIs and components (limit-up/down, consecutive boards, etc.). It distinguishes itself from siblings by focusing on aggregated market review rather than individual stock history, LHB, or trade date listings.

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 implicit guidance: omitting date returns latest trading day, and earlier history should be obtained via website/opendata. However, it does not explicitly compare with sibling tools or state when not to use it.

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

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

No annotations provided, so description carries full burden. Adds behavioral context like units (yuan) and citation requirement, but does not explicitly state read-only nature or idempotency. Adequate but not thorough.

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

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

Description is reasonably concise, covering core functionality, fields, units, and citation in a few lines. Not overly verbose, but front-loads the main purpose.

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

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

No output schema, but description lists all returned fields explicitly (code, name, gain, etc.) and notes units. Provides sufficient context for a simple list tool, though lacks details on ordering or pagination beyond the top parameter.

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% with detailed descriptions for both parameters (top, date). Description adds the unit '元' which is not in schema, but otherwise does not significantly augment parameter meaning beyond 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?

Description clearly states the tool retrieves the 'Dragon and Tiger List' for A-shares on a given trading day, listing fields returned. It differentiates from siblings implicitly (specific data type), but does not explicitly contrast with them.

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

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

No guidance on when to use this tool versus siblings (get_daily_review, get_stock_history, list_trade_dates). Does not mention prerequisites or typical use cases.

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

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

With no annotations, the description carries full responsibility and does so thoroughly. It discloses that historical counts are returned for the full period (since 2020/2016), but detailed line items are only provided for the last ~30 trading days, and that earlier data requires visiting the webpage. It also states an attribution requirement, adding behavioral context beyond the tool name.

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

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

The description is concise yet information-dense, with every sentence contributing a distinct piece of guidance: purpose, data scope, fallback, input format, alternative tool, and attribution. It front-loads the core function and uses clear punctuation to structure related details.

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 absence of an output schema and annotations, the description fully explains the return structure (counts vs. details), temporal limits, and the alternative for earlier data. It is sufficiently complete for an agent to select and invoke the tool correctly, including citation requirements.

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

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

The schema already describes the 'code' parameter as '6位股票代码(如002384)或名称(如 东山精密)' with 100% coverage. The description repeats '支持6位代码或中文名称' without adding new semantic meaning, so it does not improve upon the schema baseline of 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 clearly states the tool's function: '查询个股涨停史与龙虎榜史' (query individual stock limit-up history and dragon-tiger list history), with a specific verb and resource. It also distinguishes from siblings by explicitly mentioning the alternative get_daily_review for market reviews.

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

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

The description provides explicit usage guidance: '查某日大盘复盘请改用 get_daily_review' indicates when not to use this tool and what to use instead. It also specifies supported input formats (6-digit code or Chinese name) and the 30-trading-day limit for details, with a fallback to the web page for earlier data.

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

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

No annotations provided, so description must cover behavior. Mentions descending order, approximate count (30), and limit default. Does not detail error behavior, exact output format, or limit validation, but adequate for a simple list tool.

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

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

Extremely concise single sentence with a useful note about earlier history. No unnecessary words, well 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?

Given one optional param and no output schema, description is fairly complete: explains purpose, usage context, limitation. Could add output format (e.g., YYYY-MM-DD), but overall sufficient.

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 has 100% coverage (limit described with default and upper bound). Description adds value by specifying the approximate window size (~30) and reinforcing default, enhancing understanding beyond 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?

Description clearly states it lists A-share trading dates in descending order, about 30 recent ones, and specifies it is intended for use with get_daily_review/get_lhb date parameter, distinguishing it from sibling tools.

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

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

Explicitly tells to use output for date parameters of get_daily_review/get_lhb, and provides alternative for earlier history via webpage and open data. Lacks explicit 'when not to use' but is clear for the tool's simplicity.

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