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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: automatic pagination, HTML tag stripping, return of plain text plus PDF attachment links, an output contract that the body is not rewritten, and the data source with a verified-as-of date. It stops short of covering rate limits, auth requirements, or failure modes, so it is strong but not exhaustive.

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

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

Front-loaded with the core action and input, followed by behavior, output contract, and data source in a scannable structure. The skill cross-reference and the data-source verification date are marginally useful but slightly add noise.

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, yet the description usefully pre-declares the plain-text + PDF-link return and the no-rewrite contract. Combined with the input-source guidance, an agent has what it needs to invoke the tool correctly; only edge-case behavior is unaddressed.

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

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

Schema description coverage is 0% for the single art_code parameter, so the description must compensate, and it does by explaining where the value originates (ann_list/ann tools) and that it is required. It adds no format/example detail beyond that, so it is good but not complete.

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?

Specific verb+resource: '公告正文抓取' (fetch announcement body text), distinguishing it from the sibling ann_list which supplies the input. The description also names the associated skill, so an agent can tell what operation this performs without opening the schema.

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

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

It states the input dependency clearly ('输入 art_code（从 ann_list/ann 相关 tool 获取）'), which tells the agent to call ann_list first. However, it gives no explicit when-to-use vs when-not guidance against siblings like earnings_ann or ir_records, leaving the choice implied.

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

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

No annotations are provided, so the description carries the full burden, and it does add real behavioral context: a data source, an output contract (descending by publish time), an integrity constraint (only real interface entries, no imagined announcements), and a no-recommendation policy. It stops short of pagination behavior, rate limits, or error handling.

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 input, output, contract, and constraints in short labeled lines; each line earns its place. Slightly verbose in restating the output fields despite an output schema existing, but 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?

Output schema exists, and the description nonetheless specifies ordering, source, and non-fabrication constraints, which is more than required. The remaining gap is page_size behavior and how to retrieve further pages, which the agent cannot infer from either schema or description.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain code (6-digit stock code) with format detail beyond the bare 'string' schema, but page_size is never mentioned even though it controls result count and defaults to 20.

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: list an individual stock's recent announcements, with the required input (6-digit code) and the returned fields named. It is distinguishable from content-oriented siblings only implicitly through the art_code hint ("取正文用"), so it does not fully route the agent away from ann_content or earnings_ann by name.

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

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

Usage is implied (monitor a stock's announcements) but there is no explicit when-to-use/when-not guidance and no named alternative such as ann_content or earnings_ann. The parenthetical art_code note lightly implies ann_content is the follow-up call, but the agent must infer that.

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

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

With no annotations, the description carries the full behavioral burden and does substantial work: it defines an output contract (numbers tagged with dates), discloses that advancers/decliners and sector data have no stable public source and are flagged '未核验' rather than fabricated, states the data source (新浪行情), and declares it gives facts only with no recommendations. This meaningfully exceeds what structured fields provide.

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 in the first sentence, followed by the return contract and caveats. Each sentence earns its place (what it returns, how gaps are handled, source, and non-recommendation stance); only the parenthetical skill reference is minor overhead.

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, and the description still adds the contract, data source and 'no fabrication' caveat. It is nearly complete for a zero-param read tool, with sibling differentiation as the only notable 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?

The tool takes no parameters (0 params, empty schema), so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side.

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 ('收盘指数快照' - closing snapshot) and enumerates exactly what is returned (涨跌幅/现价/成交量/成交额 for the four major A-share indices). It is clear on its own, but does not explicitly differentiate itself from closely related siblings like 'quote' or 'market_snapshot', leaving some ambiguity about which snapshot tool to pick.

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 mention of '盘后复盘' (after-hours review) implicitly signals the usage context, and the reference to skill 'laogu-close' ties it to a workflow. However, it never states when to use this instead of the overlapping 'quote' or 'market_snapshot' siblings, so the usage rule must be inferred.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that name input fails gracefully (ok=false + a web-search template), refuses to guess codes, and states the rationale ('猜错代码=张冠李戴，比没有更糟'). It omits auth/rate-limit/latency details, but the failure-mode behavior is unusually explicit.

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 mapping and organized into input-behavior and output-contract segments. There is mild duplication between the '返回官方简称' line and the later '输出契约' line, but overall it is dense and earns its length.

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 inputs, success/failure outcomes, and the fallback path, which is sufficient for a one-parameter verification tool with an output schema. Missing only minor details (e.g., input normalization/whitespace handling), so it is near-complete.

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

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

Schema coverage is 0% (the single 'keyword' param is just typed as string), so the description must compensate, and it does: it explains the two accepted forms (6-digit code vs. Chinese short name) and the divergent behavior each triggers. Only edge cases like partial/malformed input are left undefined.

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: '新闻提及公司 → 股票代码核对' (verify a stock code against its official short name). It clearly distinguishes itself from siblings like quote/market_snapshot by being a verification/lookup tool, not a market data tool, and even names the corresponding skill (laogu-news).

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 context for use (news mentions a company, need to confirm the ticker) and a clear when-not: for a Chinese short name there is no stable programmatic 'name→code' interface, so it honestly returns ok=false rather than guessing. It doesn't name alternative sibling tools, but the usage boundary is well drawn.

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

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

No annotations are provided, so the description carries the full behavioral burden and does so well: it defines an output contract (only real interface entries, empty list rather than fabrication when no forecasts exist, no premature interpretation of profit ranges), and states the factual-only/no-recommendation boundary. It omits auth, rate-limit, and pagination behavior, keeping it below a 5.

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

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

Front-loaded with the tool's purpose, then the filter logic, then the output contract. It is slightly dense with skill-mapping and contract boilerplate, but each sentence carries a distinct constraint rather than 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?

An output schema exists, so return values need not be re-explained, and the description nonetheless pins down the output contract and scope limits well. The only real gap is the unexplained 'code' and 'page_size' parameters for a tool that accepts user input.

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

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

Schema description coverage is 0%, so the description must explain the parameters, but it never addresses either 'code' or 'page_size'. The title-keyword filtering it describes is baked into the tool logic, not a parameter, so the two actual inputs remain undocumented in both schema and description.

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: scanning the announcement list for titles containing the earnings-forecast keywords (业绩预告/业绩快报/业绩预告修正), and names the exact fields returned (art_code/title/date). It also explicitly differentiates from the sibling ann_content ('正文用 ann_content 另取'), so an agent can tell the two apart 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?

Clearly signals the use case (scanning for earnings previews/flash reports) and routes body-text extraction to ann_content, which is the complementary tool. It lacks an explicit 'when not to use' clause or a reference to ann_list as the general-purpose alternative, so it is strong context but not 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?

With no annotations, the description carries the full burden and does so well: it discloses T+1 lag, that dates follow actual API return, the output contract (cite numbers as-is with units and dates), the explicit exclusion of northbound net-inflow figures since 2024-08-19, a fact-only/no-recommendation policy, and the data source. It omits auth/rate-limit behavior, keeping it short of a 5.

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

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

The content is front-loaded with the overall purpose, then structured into per-kind blocks and an output contract. Length is justified by the two-mode design, though the parenthetical skill reference and source-date note add mild noise.

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 formatting need not be restated, yet the description adds the essential output contract and a hard boundary (no northbound net-inflow numbers). For a 2-parameter, no-annotation tool this is nearly complete; only the sibling overlap and auth context are unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: kind='margin' is documented as requiring code and returning margin-balance fields, while kind='lhb' documents an optional code and its Top5 output. The default values themselves are left to the schema, but the semantic meaning of both parameters is fully conveyed.

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 the resource (资金流向) and specifies two distinct modes via kind='margin' (per-stock margin trading) and kind='lhb' (market-wide dragon-tiger list), each with concrete returned fields. It is clear what the tool does, but it never distinguishes itself from the overlapping sibling lhb_board, which appears to cover the same 龙虎榜 domain.

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

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

Usage is only implied through the kind branches: margin requires code, lhb allows an empty code. There is no explicit when-to-use-this-vs-alternatives guidance, and the presence of the sibling lhb_board makes the lack of routing language a real gap.

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

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

With no annotations, the description carries the full burden and meets it: it openly states the tool cannot retrieve real subscription/listing data, that it returns ok=false plus a template, and that it will not fabricate codes, dates, or prices. This is exactly the non-obvious behavior an agent must know before relying on the output, and it prevents hallucinated downstream reasoning.

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 in the first line, followed by the honest limitation and the downstream procedure. The dated 'experimental result' parenthetical is slightly verbose but is defensible evidence for the claim, so little 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?

For a zero-param tool with an output schema and no annotations, the description covers the essential behavior (always-degraded output, no fabrication) and the follow-up contract. The remaining detail about the shape of the template is delegated to the output schema, which is acceptable.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. No parameter information is missing because no parameters exist.

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

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

The first line names a specific verb+resource ('打新日历') and ties it to the laogu-ipo skill, so the agent knows the domain immediately. It then precisely redefines what the tool actually does (returns ok=false plus a search template). It does not explicitly differentiate itself from siblings like unlock_notices or ann_list, which are the nearest topical neighbours.

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 tells the host exactly what to do downstream: use the returned search results per laogu-ipo's Output Contract to build the calendar, and state clearly when there are no new listings. What is missing is a 'when not to call this / call X instead' clause relative to the sibling tools.

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

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

With no annotations provided, the description carries the burden and does add real behavioral context: an output contract (only real entries, empty list with annotation when none exist, no fabrication), a neutrality guarantee (facts only, no buy/sell recommendations), and a disclosed data source (East Money announcement interface). Missing permission/auth and rate-limit details keeps it from a 5.

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

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

The purpose is front-loaded and the sentences are dense but purposeful (method, output contract, data source). Some content, such as the neutrality reminder and skill cross-reference, is boilerplate that does not directly help invocation, keeping it short of 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?

An output schema exists, so return-value enumeration is not needed, and the description still adds the output contract and data source. The main gap is the undocumented parameters, but against a present output schema the definition is largely complete for correct invocation.

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

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

Schema description coverage is 0% and the description never mentions the two parameters. The required 'code' and 'page_size' are left entirely undocumented; an agent can only guess that 'code' is a stock/announcement code and that 'page_size' paginates. The description does not compensate for the coverage gap.

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

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

States a specific verb+resource: it searches/filters the announcement list for entries whose titles contain '投资者关系活动记录表' and returns art_code/title/date. An agent can immediately tell this apart from the sibling ann_content, which is explicitly named as the body-fetching 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?

It explains the workflow context and routes the agent to a sibling: the minutes body must be fetched separately via ann_content and then structured. It gives clear context but frames ann_content as a complement rather than spelling out when this tool should be preferred over or combined with other announcement tools.

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

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

With no annotations, the description carries the full burden and does so well beyond a restatement: it discloses the auto-rollback rule (max 10 days, skip weekends), the classification contract (seat type only, ignore buy/sell wording), the data limitation (no specific brokerage branches, never fabricate), and the no-recommendation policy. It also cites the concrete data source and its last-verified date. The only missing piece is any error-handling or rate-limit 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 description is dense but front-loaded: identity and skill mapping come first, then the date rule, then output and contracts. Every clause (rollback, contract, data source) adds usable information rather than filler, though the multi-clause contract paragraph is heavy and could be tightened.

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?

Because an output schema exists the description needn't enumerate return values, yet it still summarizes the output shape and, more importantly, supplies the governance contracts (no fabrication, no recommendations) that structured fields do not carry. With annotations absent, the behavioral and output-contract coverage makes it nearly complete, lacking only failure-mode detail.

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

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

Schema coverage is 0%, so the description must supply parameter meaning, and it does: trade_date's empty-value behavior is fully explained (rollback to nearest trading day), and top_n's role is conveyed via the '净买入/净卖出 TopN' output framing. top_n is still only implied rather than explicitly tied to the parameter, keeping it out of the top band.

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+resource: it retrieves 龙虎榜明细 (the daily LHB detail list) and identifies its scope via the corresponding skill (laogu-lhb 龙虎榜夜报). The resource is unmistakable and clearly distinct from the sibling set (quote, fund_flow, ann_list, etc.), but it never names a sibling or states what it is *not*, so it stops short of explicit differentiation.

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

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

Usage context is implied through the skill correspondence and the trade_date rollback rule, but there is no explicit 'use this when…' or routing against alternatives like fund_flow or market_snapshot. The trade_date default behavior is well specified, which helps invocation, but selection guidance 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 no annotations, the description carries the full burden and does well: it discloses the heuristic nature of weekday validation (cross-checked via 龙虎榜 data existence), the default-date behavior, that it is read-only/factual with no recommendations, and explicitly that it will not fabricate event calendars. It stops short of stating permission requirements or output shape, but adds substantial behavioral context.

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

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

Purpose and default are front-loaded, but the text is dense with parenthetical asides and repeats return items that the output schema already covers. Each clause is meaningful, yet it could be tightened without losing 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 1-parameter read tool with an output schema present, the description is nearly complete: it covers the default argument, the heuristic limitation, and the explicit non-goal (no fabricated event calendar). Only permission/prerequisite information is absent, which is minor 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 0% for the single `date` parameter, but the description compensates by clarifying that the argument is a date and defaults to today. That partially fills the gap, though it adds no format/expected-value detail beyond the default.

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 deliverable: whether a given date (default today) is an A-share trading day, plus Beijing time and US session notes. It is specific about the resource and scope, though it never explicitly contrasts itself with siblings like ipo_calendar or market_snapshot, which also touch calendar/time concerns.

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

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

Usage is implied (call it to check trading-day status, default date is today) and the skill mapping (laogu-macro) is noted, but there is no explicit when-to-use/when-not guidance or named alternative among the 15 siblings. The reader must infer routing.

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

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

With no annotations, the description carries the full burden and delivers real behavioral context: an output contract (name/price/change/time per item), session-state labeling for US indices, a null-instead-of-guessing rule for unreliable A-share turnover, and a no-recommendation disclaimer. It omits auth/rate-limit behavior, keeping it short of a 5.

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

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

Front-loaded with the payload contents, then the output contract, then caveats. The data-source line and tested-date stamp are defensible for a live-quote tool. Slightly dense but every sentence carries weight.

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 restated, yet the description usefully supplements it with the null-handling and session-label conventions an agent needs. Given a parameterless, single-call tool, this is close to 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?

Zero parameters, so the baseline of 4 applies. The description sensibly uses that space for the output contract rather than fabricating parameter guidance.

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 (market snapshot) and enumerates exactly what it returns: four A-share indices, three US indices, WTI crude, COMEX gold, offshore RMB. This scope enumeration clearly differentiates it from narrower siblings like quote and close_recap without opening either schema.

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

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

It ties itself to two named workflows (laogu-morning daily brief / laogu-close review), which implies the usage context. However, it never explicitly contrasts against sibling tools such as quote or fund_flow, nor states when this broad snapshot is the wrong choice. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the output contract (values quoted verbatim with units, missing fields set to null and reported in warnings, no estimation or fabrication), an explicit no-buy/sell-advice constraint, and a three-tier data-source fallback (腾讯 → 新浪 → 东财 push2) surfaced via warnings. It stops short of stating rate limits, latency, or authentication needs.

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 one-line purpose, then clearly labeled sections for output fields, output contract, and data source. Every line earns its place; there is no filler or repetition.

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, and the description still adds the value-level contract (units, null policy, warnings) that the schema cannot. Input format, output contract, and failure/degradation behavior are all covered, leaving only minor gaps around concurrency or freshness guarantees.

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

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

Schema coverage is 0% – the schema only declares code as a bare string – so the description must supply the meaning, and it does: the value is a 6-digit stock code with a concrete example (600519). That is the single most important detail for invoking the tool correctly, though no further format/validation constraints are given.

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 action (个股行情快照 = individual stock quote snapshot) and enumerates the return fields, so an agent knows exactly what it produces. It names the associated skill but never contrasts itself with the close sibling market_snapshot, so differentiation from alternatives relies on inference.

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 tells the agent the required input form (6-digit code, e.g. 600519), which implies when the tool applies. However, it gives no explicit when-to-use/when-not guidance and never points to an alternative such as market_snapshot, so selection between the two is left to the agent.

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

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

With no annotations, the description carries the full burden and does meaningful work: it honestly declares that report bodies have no stable programmatic interface, that it does not supply report content, and that it only states facts without buy/sell recommendations. That scope-disclosure is genuine behavioral context, though read-only/safety traits and any limits are left implicit.

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, and the honest-declaration sentences each add a distinct constraint. It is somewhat repetitive and longer than strictly necessary, but no sentence is pure 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 not be explained, and for a one-parameter tool the description covers what it returns, its scope limit, and its intended use. The main residual gap is parameter format guidance, which is minor given the output schema's presence.

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

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

Schema description coverage is 0% for the single required 'code' parameter, so the description should compensate. It implies code is used for 代码核对/官方简称 lookup, giving the parameter a purpose, but it never specifies format or accepted values, leaving the agent to infer how to populate 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?

The description names a specific output (代码核对/官方简称 + 行情快照) and ties it to a concrete use case (研报精读时的交叉验证), and explicitly disclaims that it does not return research-report content. This lets an agent distinguish it from pure siblings like code_verify or market_snapshot, though the combined 'grounding' framing is a little abstract.

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 states context of use ('供研报解读时交叉验证') and a prerequisite (research report text must be pasted by the user), which is useful. However it never explicitly contrasts itself with the sibling tools it overlaps with (code_verify, market_snapshot) or states when NOT to use it, so routing is implied rather than directed.

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

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

With no annotations, the description carries the full burden and does disclose key behaviors: it is input-prep only, does not score, derives the report period strictly from the announcement title without speculation, and states facts only with no buy/sell recommendations. This is meaningful behavioral context beyond structured fields, though it says nothing about failure modes or rate limits.

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

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

The description is front-loaded with purpose and returns, then the output contract, using a compact multi-part structure. It is dense but every clause (returns, contract, period rule, no-recommendation) contributes, so there is little waste.

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

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

An output schema exists, so return-value format is covered, and the description adds the behavioral contract (no scoring, no speculation, facts only). The one missing piece is any meaning for the 'code' parameter, which leaves a small completeness gap for a 1-param tool with no annotations.

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

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

Schema description coverage is 0% and the single required parameter 'code' is never explained in the description. Context (market snapshot, financial reports) makes it inferable as a stock code, but the description does not compensate for the documentation gap as required at low coverage.

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 function (input preparation for a financial risk check, 'laogu-risk') and specifies its two concrete outputs: a market snapshot and the located latest periodic report. It also distinguishes its role from the sibling ann_content by noting the report body must be fetched separately. Clear verb+resource, though the tie to the 'risk_inputs' name relies on the 'laogu-risk' skill reference.

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 states this tool only prepares inputs and does not score, and explicitly names ann_content as the follow-up call needed for report text, which routes the agent across siblings. It does not enumerate when-not-to-use beyond the scoring disclaimer, so it stops just short of a full 5.

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

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

With no annotations the description carries the full burden, and it discloses useful behavior: exact title-filter keywords, returned fields only (art_code/title/date, no scale/ratio/shareholder data), empty-list behavior when nothing matches, and the data source (东财公告接口). Pagination/rate-limit behavior is not described, keeping it below a 5.

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

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

Front-loaded with purpose and the filter criteria, with the output contract and sibling handoff following logically. Slightly padded by the skill reference and compliance boilerplate (只陈述事实，不做买卖推荐), but nothing is truly 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 values need not be re-explained, and the description covers filtering, chaining to ann_content, and empty-result handling. The only real gap is parameter meaning, which is left entirely undocumented.

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

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

Schema description coverage is 0% and neither parameter is explained: the description never clarifies that code is the target security identifier or what page_size controls. For a 2-param tool with no schema-level documentation, the description fails to compensate.

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

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

States a specific verb and resource (search/filter unlock announcements by title keywords) and enumerates the exact match strings. It also scopes the output (art_code/title/date) and explicitly routes body-content needs to the sibling ann_content, so an agent can distinguish it from ann_list and ann_content without opening schemas.

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

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

Explicitly ties the tool to a workflow (解禁冲击评估 / laogu-unlock skill) and states when-not to rely on it: 抛压定级需正文数据，本 tool 只做公告定位，用 ann_content 另取. The alternative and the condition that selects it are named.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data-source fallback chain (Tencent → Sina → Eastmoney push2), that only fetchable metrics are returned, that historical percentile/peer-comparison gaps are flagged as '未核验' in warnings for the host to fill via search, and that it only describes percentile position without buy/sell recommendations. It omits auth/rate-limit or freshness/latency details, keeping it short of a 5.

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

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

Front-loads the purpose and keeps to a few dense lines: return payload, output contract, constraint, then data sources. Parenthetical skill reference and the source chain are informative rather than filler, though the structure is slightly telegraphic.

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 prose. The description still covers data-source fallback, gap/warning handling, and the no-recommendation constraint, which is sufficient for a one-parameter read tool. The missing element is parameter format guidance, which matters for Chinese ticker codes.

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

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

Schema coverage is 0% and the single 'code' parameter is undocumented in both the schema and the description — no ticker format (e.g. 600519.SH vs 600519) is specified. The miss is bounded because there is only one, self-evidently named parameter, but the description adds nothing about 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+resource: returns current PE(TTM)/PB/market cap/price for a given code, framed as the valuation anchor input for the laogu-value skill. An agent can tell it produces valuation metrics rather than raw quotes. It does not, however, explicitly differentiate itself from close siblings like quote or market_snapshot, which overlap on price/valuation data.

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

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

The description implies a purpose (valuation anchor for the laogu-value skill) but never says when to choose this over siblings such as quote, market_snapshot, or risk_inputs. No exclusions or alternative-selection conditions are given.

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