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, yet it only says an LLM is involved. It omits non-determinism/cost implications, latency, failure behavior when output does not match the supplied JSON Schema, and any truncation semantics beyond what the schema default states.

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 front-loaded sentence with no filler. It is efficient, though arguably too terse for an LLM-backed tool with non-trivial behavior.

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 needn't be explained, but this is a complex LLM extraction tool with nested schema input and no annotations. The description leaves out model behavior, cost/rate considerations, and what happens on schema-conformance failure, so it is not complete enough for confident 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 baseline is 3; each parameter already has a description. The tool description adds nothing about the meaning or interaction of text, prompt, schema, or max_chars, so no credit above 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 (structured extraction) and resource (report section text) with the added qualifier that it is LLM-driven, which distinguishes it from purely mechanical extraction. However, it does not name or differentiate itself from close siblings like extract_section or extract_indicators, 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 no when-to-use or when-not-to-use guidance, and no alternative is named. Given several overlapping siblings (extract_section, extract_indicators, extract_indicators_by_position), the absence of routing guidance is 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 it does disclose the key behavioral fact that this tool writes an output file ('write a stable JSON report'). It does not state whether output_path is overwritten, whether the run is idempotent, what permissions are needed, or what happens when no bundles exist, which are meaningful gaps for a mutating 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?

A single front-loaded sentence with no filler, stating action, input source, and deliverable. It is appropriately sized, though it could have spent one more clause on the behavior gap noted above without becoming bloated.

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 documented. What is missing is the behavioral context a mutation tool without annotations needs: overwrite semantics for output_path, required prior state of out_dir, and result when zero gaps are found.

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 three parameters (out_dir, max_files, output_path) documented including defaults, so the schema does the heavy lifting. The description only echoes the out/ directory and report-writing concepts already in the schema, adding no extra 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?

States a specific verb+resource pair ('audit rule gaps from existing out/ bundles') plus the side effect of writing a report, which is clear enough to distinguish from unrelated siblings like list_filings or get_indicator. However, 'rule gaps' is unexplained domain jargon, so the agent knows the action but not precisely what a gap is.

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 phrase 'from existing out/ bundles' implies a prerequisite (bundles must already be extracted), but the description never states when to run this versus other tools or what to do if bundles are absent. No explicit when/when-not guidance is 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?

No annotations are provided, so the description carries the full behavioral burden. 'Evict' hints at destruction, but it does not disclose whether eviction is reversible, what permissions are required, whether it runs immediately, or the impact of clearing a shared cache. This is a significant gap for a mutating tool with zero annotation coverage.

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

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

A single front-loaded sentence with zero waste. Every word earns its place, and the core action is immediately clear.

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

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

An output schema exists, so return values need not be explained. However, for a cache-eviction mutation with no annotations, the description omits reversible/permission/impact context and any relation to list_cache, leaving the agent insufficiently informed about a destructive operation.

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 thoroughly documents the scoping behavior of year and stock_code. The description adds nothing beyond the schema, so the baseline of 3 applies when structured data already 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 ('Evict') and resource ('cached annual reports'), which is far more informative than a tautology. It is clear what the tool does, though it does not explicitly contrast itself with the sibling list_cache, so sibling differentiation is left to 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?

There is no guidance on when to use this tool, when not to, or how it relates to list_cache. The description gives no prerequisites or caution about the eviction being a mutating/irreversible operation, leaving the agent to infer usage entirely.

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. It usefully discloses that both the index and its metadata row are destroyed, which is more than the name conveys, but it omits irreversibility, permission requirements, and confirmation behavior beyond what the schema already states.

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 front-loaded sentence with the destructive action first and the affected resources second. Every word earns its place 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?

The output schema covers return values, and the schema documents the confirm gate. However, for a destructive tool with zero annotation coverage, the description is thin on safety, permissions, and irreversibility, leaving meaningful 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 coverage is 100%, so both parameters are already documented. The description clarifies what "year" indexes into (the cnreport-{year} naming), adding a little context, but the confirm safety gate is left entirely to the schema. Baseline 3 is appropriate.

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

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

The description pairs a specific destructive verb ("Drop") with a precise resource and scope ("the cnreport-{year} Elasticsearch index and its metadata row"). This clearly separates it from siblings like index_records, which writes rather than deletes.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any stated prerequisites or runbook context. The destructive intent is implied by "Drop," but no conditions, warnings, or sibling routing are provided.

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 largely delivers: it discloses single PDF fetch, section grouping, one LLM call per section, per-rule Python extractor dispatch, local ratio computation, and disk caching (a persistence side effect). It omits error behavior, permissions, and rate limits, 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 purpose sentence followed by a dense but relevant mechanics sentence; no filler. The single long sentence packs many clauses, but each earns its place by disclosing real behavior.

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 described, and params are fully schema-covered. The description adequately conveys the batch-extraction model and caching behavior; the main omission is routing guidance relative to sibling extraction tools.

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 ticker_or_name, year, form, indicators, and extractor_mode. The description adds no parameter-level detail beyond what the schema provides, 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?

The description states a specific verb (extract), resource (indicators), and scope (one company/year in a single pass), which lets an agent distinguish it from per-position or per-section extraction. It does not explicitly name the closest sibling, extract_indicators_by_position, so the differentiation is implied rather than stated.

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

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

The description explains how the tool works but gives no explicit guidance on when to choose it over extract_section, ai_extract, or extract_indicators_by_position. There is only a weak implied 'batch/whole-company' framing, with no when-not conditions or prerequisites.

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 batch engine, single PDF fetch, batched LLM, python extractors, computed ratios, bundle cache, and the crucial behavior that realtime/external indicators are NOT extracted but returned in `skipped`.

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 operation in the first sentence and follows with the mechanism and the skip behavior. The engine internals parenthetical is dense but each clause conveys real behavior; nothing 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 values need not be described, and the description covers the extraction scope, the CSV default, and the skip semantics. An agent has enough to invoke it correctly, though the relationship to extract_indicators remains 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 coverage is 100%, so the schema already documents all five parameters, making 3 the baseline. The description adds the default CSV path and clarifies the `indicators`/`skipped` semantics, but does not add format or syntax 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?

States a specific verb ('Extract') and resource ('the indicators named in a position CSV') scoped to one company/year, which is clearly more specific than the generic siblings like extract_indicators or get_indicator. It never names those siblings, so the agent must infer the distinction.

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?

Implies usage through the CSV-driven workflow but gives no explicit when-to-use/when-not guidance versus extract_indicators or list_indicators. The note that realtime/external indicators land in `skipped` is helpful context but not routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It states only the extraction operation and does not explain selector-miss behavior, source requirements, authentication needs, or any other behavioral trait beyond the obvious read operation.

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

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

The description is a single front-loaded sentence with no wasted words. Its brevity is appropriate in form, though it is arguably too short for a tool with seven parameters and no annotations.

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

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

Given the tool's complexity (seven parameters, no annotations, overlapping sibling tools), the description is missing critical context about when and how to use it. The output schema covers return values, but usage guidance and parameter context remain largely 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 description coverage is 57%, and the description mentions only 'selector' without adding meaning beyond the schema's own selector description ('exact section title, regex, or 1-based ordinal'). The other six parameters, including required 'source', receive no explanation in the description, so it 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?

The description states a specific verb (Extract), resource (one section's body text), and method (by selector), so the core operation is clear. However, it gives no domain context (e.g., filings/reports) and does not distinguish this tool from siblings like get_section or ai_extract, which likely overlap.

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

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

There is no guidance on when to use this tool versus alternatives such as get_section, get_filing, or ai_extract. No required context, exclusions, or comparison to sibling tools is provided.

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 it discloses essentially nothing: no auth requirements, no rate limits, no statement of what is returned or whether a miss produces an error versus an empty result. The only technical detail (6-digit format) already lives in the schema, so there is effectively no added 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?

A single front-loaded sentence with no filler; the verb, resource and keying identifier come first. The trailing '(bse.cn)' parenthetical is terse to the point of being ambiguous, but nothing 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 one-parameter resolver with an output schema, the description is close to sufficient: an agent knows the exchange, the identifier type and that a lookup occurs. The gaps are the unmentioned name lookup path and any failure semantics, which are minor given the full schema coverage and existing output 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% and the schema already documents the accepted ticker prefixes (430xxx/83xxxx/87xxxx/88xxxx/920xxx), so the description need not repeat them. However, saying 'by 6-digit ticker' omits the name-matching half of the ticker_or_name parameter that the schema exposes, adding no meaning beyond or in fact slightly less than 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?

States a specific verb (resolve) and resource (BSE-listed company) keyed by a 6-digit ticker, and the BSE framing distinguishes it from get_sse_company, get_szse_company, get_hk_company and the generic get_company. It is slightly narrower than the input schema, which also accepts a company name via ticker_or_name, so the stated purpose under-describes the tool's actual lookup capability.

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 by the exchange qualifier rather than stated: an agent can infer 'use this for BSE companies' when it already knows the exchange, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative resolver. No prerequisites or routing guidance 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the multi-source fallback (BSE or CNINFO), that the response carries which one was used, and that failures return {error}. It stops short of saying anything about auth needs, rate limits, or PDF availability edge cases.

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 tight sentences with the core purpose front-loaded and the fallback/return details compactly appended. Nothing is wasted, though the flat return-value listing adds little.

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 3-required-parameter extraction tool, the description covers sourcing and error behavior but leaves the parameter vocabulary entirely undocumented — notably what valid section names are, which matters since the tool extracts by name. An output schema exists, so restating the return fields was optional.

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 gives no meaning for the three required parameters. It hints that 'section' is a name, but ticker_or_name format, accepted year format, and the section vocabulary (matching outline_entry / list_outline) are all left unstated, so the agent must guess.

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 (Extract), a specific resource (a named section of an annual-report PDF), and a specific exchange scope (BSE company), which cleanly separates it from the sibling get_sse_section, get_szse_section, and get_hk_section.

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 exchange scope ('a BSE company') implies when this tool applies, and the CNINFO fallback is noted, but there is no explicit when-to-use/when-not guidance versus alternatives like get_section, extract_section, or the other exchange-specific section 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?

No annotations are provided, so the description carries the full behavioral burden. It does not state whether the call is read-only, what happens on a miss or an ambiguous name fragment, or how fuzzy matching resolves multiple candidates — meaningful gaps for a resolution 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?

A single front-loaded sentence with zero waste; the identifier forms are placed immediately after the verb and resource.

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 the single parameter is fully documented. For a simple lookup this is nearly complete, with only ambiguity/miss behavior left 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 coverage is 100% and the parameter already documents both a 6-digit ticker and a name fragment with examples. The description merely echoes those accepted forms, adding no syntax or matching-rule detail beyond the schema, so 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 ("Resolve") and resource ("company"), plus the accepted identifier forms. The "CN-A-share" qualifier begins to distinguish it from the HK/BSE/SSE/SZSE company siblings, but it never names which sibling to use instead, so differentiation is only implied.

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

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

No when-to-use guidance and no mention of alternatives, despite a crowded sibling family (get_hk_company, get_bse_company, get_sse_company, get_szse_company). The agent is left to infer the routing on its own.

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. It does disclose the two return shapes, including an error branch, which signals graceful failure handling. However, it says nothing about permissions, rate limits, or data freshness, and the return detail is somewhat redundant with the existing output schema.

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 and front-loads the purpose before the return-shape block. Every sentence is relevant, though the returns block spends most of the text on information the output schema already provides.

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, yet the description spends its text there while leaving usage and the ambiguous company_or_code parameter unaddressed. For a simple one-parameter query tool this is adequate but has visible 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 0% and the single parameter company_or_code is undocumented in the schema. The description never explains whether the argument should be a company name, a stock code, or both, nor its format, so it fails to 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: query CSRC IPO (首发) application review status for a company. This is clearly distinguishable from the near-named sibling get_csrc_merger_review. It stops short of explicitly naming which sibling to use for other CSRC review types, so it is clear but not fully differentiated.

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

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

No when-to-use or when-not-to-use guidance is given. There is no mention of the alternative get_csrc_merger_review or of prerequisites such as needing a valid company name vs a stock code. Usage is only implied by the verb 'query'.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return envelope ({company, source, fields} vs {company, source, error}), which conveys that failures are reported per-company rather than thrown, but it says nothing about auth, rate limits, data freshness, or whether a missing company yields an error object.

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 sentences, purpose first, return shape second, with no filler. Slightly compressed — the return clause could be dropped entirely given an output schema exists — but nothing 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 single-parameter lookup with an output schema present, the description need not re-explain return values, yet it still omits parameter format guidance and any scoping context (e.g., listed companies only, which markets). Adequate but with clear 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 0% for the single required parameter, and the description only implies a company identifier via 'for a company'. It never clarifies what company_or_code accepts — a ticker/stock code, an exchange-prefixed code, or a Chinese company name — which is the main ambiguity an agent faces 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 (Query) plus a specific resource (CSRC 并购重组 M&A review status for a company), which cleanly separates it from the sibling get_csrc_ipo_review. It does not explicitly name the sibling or contrast the two, so it stops short of 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_csrc_ipo_review or list_csrc_filings. The agent must infer the domain from the tool name alone.

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. It usefully discloses the output shape (metadata + PDF URL), implying a read-only fetch, but says nothing about auth requirements, failure modes when the id is invalid, or rate limits. Adequate but thin for an unannotated 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?

A single front-loaded sentence with no filler; the verb, resource, and lookup key all land immediately.

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 exposition, and the description states the resource and key. The only gap is not telling the agent where the required announcement_id comes from or noting the optional ticker_or_name narrowing hint.

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 both parameters are already documented in the schema (including the 'recommended' hint on ticker_or_name). The description only reinforces that lookup is 'by id' and adds nothing beyond the schema, matching 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 (Fetch), a specific resource (one CNINFO announcement's metadata + PDF URL), and a lookup key (by id). The word 'one' implicitly contrasts with list_filings, but no sibling tool is named, so differentiation is inferred rather than explicit.

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

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

No when-to-use guidance and no mention of alternatives, even though siblings like list_filings are the obvious way to obtain the id this tool requires. The agent gets no condition under which to pick this tool over the listing 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?

No annotations are provided, so the description carries the full behavioral burden. Beyond implying a read ('Return'), it says nothing about permissions, caching, pagination of statement rows, or latency, and does not clarify the CN-A-share-only constraint beyond a scope label.

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 tight sentence with the resource and market scope front-loaded. There is no filler, though it is arguably too terse to route an agent among many financial siblings.

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 and schema coverage is full, so return values and parameters are covered. What is missing is disambiguation from get_financial_statements/get_hk_financials and any behavioral context, which is notable for a tool in such a crowded sibling namespace.

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% – period, statement and ticker_or_name are all documented in the schema with defaults and allowed values. The description adds no extra parameter 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 (Return) and resource (structured income/balance/cashflow statements) and scopes it to CN-A-share companies. It does not, however, distinguish itself from the sibling get_financial_statements, which an agent could easily confuse it with.

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

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

No when-to-use guidance is given. With siblings like get_financial_statements, get_hk_financials and get_company, the description never says which market/vehicle this tool covers versus the alternatives, leaving the agent to guess.

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 behavioral burden well: it discloses the report-cache resolution (no re-download on repeat), the TOC parsing step, that output is section text only and never PDF bytes, and how unresolved statements are reported. It omits permission/auth prerequisites and rate-limit behavior, but covers the important traits for a read-style extraction.

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 line, and the following sentences are organized around resolution, output fields, and failure handling. It is somewhat long and uses pseudo-code formatting, but nearly every clause carries 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?

Given an output schema exists and no annotations are present, the description covers the essentials: what is returned, the text-only constraint, and how missing statements are signaled. It is slightly light on operational prerequisites but otherwise complete for the tool's complexity.

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 three params are already documented; baseline is 3. The description adds only the conceptual framing of the ``(ticker, year, form)`` triple used for PDF resolution, which is minor value over 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 precise verb and resource: extract the three major financial statements (三大报表) as text, and names the exact output fields (income_statement/利润表, balance_sheet/资产负债表, cashflow/现金流量表). However, it never distinguishes itself from the very close sibling get_financials (or get_hk_financials), leaving the agent to infer which one 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?

It provides a real fallback route: statements missing from the TOC are surfaced in ``missing`` with the ``available`` list so the caller can fall back to ``get_section`` with a custom selector. That is useful implied guidance, but there is no explicit when-to-use statement and no exclusion or comparison against get_financials, so usage is only 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 behavioral burden, yet it does not state that this is a read-only lookup, how ambiguous or partial name fragments are resolved, whether multiple matches are returned, or what happens on a miss. Only the input facet ('5-digit ticker or name fragment') is disclosed.

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 front-loaded sentence with no filler; the resolution key is stated immediately and nothing is padded.

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 with one simple parameter the definition is minimally adequate. It nonetheless omits any routing context for the surrounding HK toolset, leaving the agent to guess where this fits in a workflow.

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 single parameter is already documented in the schema, making 3 the baseline. The description's '5-digit' qualifier adds minor specificity beyond the schema's '00700' example but nothing about format tolerance or matching semantics.

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

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

The description gives a specific verb ('Resolve'), resource ('HK stock company'), and the two accepted key forms, which sets it apart from the geographically-named siblings get_sse_company, get_szse_company, and get_bse_company. It does not, however, clarify its relationship to the other HK tools like get_hk_financials or get_hk_section.

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

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

There is no when-to-use guidance, no statement that this is the entry point for resolving a company before calling get_hk_filings or get_hk_financials, and no exclusion of alternatives. The agent must infer usage purely from the tool name.

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 disclosure burden. "Return structured" implies a read-only, machine-readable fetch, but nothing covers reporting period, currency, statement types, or whether statements are consolidated — all relevant for financial data.

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?

One short sentence with no filler and the key scope qualifier (HK) positioned early. It is efficient, though arguably terse to the point of omitting useful routing context.

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

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

For a one-parameter tool with an output schema defining the return shape, the essentials are covered. However, with two similarly named siblings (get_financials, get_financial_statements) in the same namespace, the description should clarify the distinction and is silent on it.

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?

Single parameter with 100% schema description coverage, so the schema already explains ticker_or_name. The description adds no format details (e.g., ticker syntax, whether a Chinese name is accepted), which is the expected baseline when the schema does the work.

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 ("Return") plus resource ("structured financial statements") and explicit scope ("HK stock company"), which separates it from the mainland-focused get_financials/get_financial_statements. It never names those siblings, so the boundary is implied by the "HK" qualifier rather than stated.

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

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

No when-to-use guidance, no prerequisites, and no mention of when to prefer this over get_financials, get_financial_statements, or get_hk_company. The agent must infer the routing decision entirely from the word "HK".

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. 'Extract' implies a read-only operation, but it does not explicitly state non-destructiveness, permission requirements, rate limits, or error behavior when a PDF or section is unavailable. It adds only the source type (HK stock annual report PDF).

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, front-loaded sentence with no wasted words. The verb, resource, and domain are communicated immediately.

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. However, given the large set of similar section-extraction and HK-related sibling tools, the description lacks enough routing context to confidently choose this tool over alternatives. It is minimally adequate for a simple extraction tool but incomplete for selection among close siblings.

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 three parameters. The description adds little beyond the schema: 'named section' aligns with the section parameter, and 'HK stock annual report PDF' contextualizes ticker_or_name and year, but no format or syntax details are added.

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 (Extract), resource (named section), and domain (HK stock annual report PDF). It is clearly about extracting report sections, though it does not explicitly differentiate itself from generic siblings like get_section, get_szse_section, or get_hk_financials.

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

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

No when-to-use guidance or alternatives are provided. The description does not explain when to prefer this tool over get_hk_financials, list_hk_filings, get_section, or other exchange-specific section tools. Usage is only implied by the HK annual report context.

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 does disclose useful behavior: resolution routes by `source_type` across akshare line items, annual-report PDF sections (LLM or registered Python extractor), or locally-computed ratios. This tells the agent the call may trigger extraction or computation rather than a plain lookup. It omits auth/caching/error 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?

Two sentences, no filler, with the core purpose front-loaded before the routing detail. Every clause carries 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?

An output schema exists so return values need no explanation, and all four parameters are schema-documented. The description adequately covers what the call does. Minor gap: nothing about what happens when a quarterly request hits a non-akshare source, or what the caller receives on resolution failure.

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 indicator aliasing, period, year, and ticker formats. The description adds only the 'company + period' framing and the routing hint, which is baseline for a fully documented 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?

States a specific verb ('Resolve') and resource ('one named financial indicator') with the scoping dimensions (company + period). It is distinguishable from list_indicators and extract_indicators, though it never explicitly contrasts itself with those siblings. Clear but not self-differentiating.

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 routing sentence implies this is the single-indicator resolution path, distinguishing it implicitly from the batch-oriented list_indicators/extract_indicators tools. However, there is no explicit when-to-use statement, no mention of prerequisites (e.g., the indicator must exist in a rule set), and no guidance on failure 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 the full behavioral burden, and it discloses little beyond the mechanics: no mention of network dependency, the fragility of HTML-table parsing, error behavior for unreachable/blocked pages, or rate limits. It doesn't contradict anything, but for a scraping tool the omissions are meaningful.

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 efficient sentence with the action front-loaded and no filler. It is appropriately sized, though the brevity contributes to the completeness gaps elsewhere.

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 the parameters are fully documented. However, with zero annotations and no usage or behavioral context, the definition is only minimally viable for a network-scraping 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 both the url-override and limit semantics are already documented in the schema, giving a baseline of 3. The description adds no parameter-level detail beyond what the structured fields provide.

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 pair ('fetch' and 'parse') plus a clear resource ('a ministry's statistics page'), so the agent knows exactly what happens. It does not itself distinguish from siblings like get_nbs_stat or list_ministries – that routing note lives only in the schema parameter description.

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 offers no when-to-use or when-not-to-use guidance. The only routing hint ('use get_nbs_stat for nbs') appears in the ministry_id schema field, not in the description, so the agent gets no proactive direction about alternatives such as list_ministries.

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 supplied, the description carries the full behavioral burden, and it discloses almost nothing: no read-only confirmation, no note on data freshness, latency, rate limits, or whether codes can be wrong/empty. 'Query' weakly implies a read, but nothing beyond that is stated.

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

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

A single, front-loaded sentence with no filler; every word contributes to identifying the operation and its key input.

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 explanation is not required, and both parameters are documented in the schema. However, for a query tool with zero annotations, the description omits behavioral and usage context (read-only nature, where indicator codes come from) that an agent would need to invoke it confidently.

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 gives a concrete example ('A0201' for GDP) and the dbcode default meaning ('hgnd' = national annual). The description adds no additional parameter meaning beyond 'indicator code', 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?

The description names a specific verb (Query) and resource (NBS macro statistic) and identifies the keying mechanism (indicator code), which is enough to distinguish it from generic stat tools like get_indicator or get_ministry_stat at a glance. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully differentiated.

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

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

There is no statement of when to use this tool versus alternatives such as get_ministry_stat or get_indicator, nor any note that the indicator code must first be sourced (e.g. from list_indicators). Usage is only implied by the phrase 'by indicator code'.

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 must carry the behavioral burden. It does disclose the internal pipeline (CNINFO lookup → PDF URL → outline extraction), which usefully signals a network-dependent, multi-stage operation. It says nothing about auth requirements, caching, rate limits, failure modes, or what happens when the section title doesn't match.

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 lines with zero waste, purpose front-loaded in the first sentence and the wrapper relationship clarified in the second. Every clause 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?

With an output schema present, return values need not be explained, and the description adequately covers the input-to-output pipeline. The one real gap is scope: it does not indicate which filers/exchange universe it covers versus the many regional get_*_section siblings.

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 ticker_or_name, year, form, and the section selector grammar. The description only restates the parameter tuple '(ticker, year, section, form)' without adding format or semantic 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 verb+resource: 'Resolve a company's filing PDF and extract one named section,' which is a clear action. The 'Convenience wrapper' framing also distinguishes it from the lower-level extract_section sibling. However, it never names its exchange/source scope (CNINFO/mainland) against the many sibling get_*_section variants (SZSE, BSE, HK, SSE), leaving the agent to infer 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?

Calling itself a 'convenience wrapper' implies it should be used when you want a one-shot ticker→section flow instead of the multi-step lookup+extract path, which is implied guidance. But there is no explicit when-to-use vs when-not, and no routing away from exchange-specific siblings like get_sse_section or get_hk_section.

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, yet it discloses nothing about operation semantics. It never states that this is a read-only fetch, what happens when 'section' is omitted (metadata-only, no PDF download), or how limit/year interact — all of which sit in the schema rather than the description.

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

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

A single front-loaded sentence with zero filler; the core verb-resource-scope is presented immediately. Appropriately sized for the information it chooses to convey.

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 5-parameter tool with subtle behaviors (optional section triggering PDF download, limit-based selection), a one-sentence description is minimal. Rich schema coverage and an output schema reduce the burden, but the description still omits any behavioral framing an agent would want before calling it.

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 five parameters (year, limit, section, category, ticker_or_name) are already documented in the schema, establishing a baseline of 3. The description adds only 'by CNINFO category', which does not extend 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 concrete verb (Retrieve) and resource (special-type report) with scoping to CN-A-share companies and CNINFO categories, so the intent is identifiable. However, 'special-type report' is never defined, and the description does not distinguish this from siblings like get_filing or search_reports, leaving the agent to infer what makes a report 'special'.

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 gives no when-to-use or when-not-to-use guidance and never names an alternative (get_filing, get_section, search_reports). The only routing hint ('Use list_report_types to browse') lives in the schema, not the description.

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 not meet it. It says nothing about what happens with an unknown or malformed ticker, whether the lookup is cached, auth requirements, or rate limits, which matters for a resolution tool with zero annotation coverage.

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

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

One short, front-loaded sentence with no filler, and the identifying constraint (6-digit SSE ticker) appears before the parenthetical source. It is efficient, though the extreme brevity leaves structure with little room to add routing or caveats.

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

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

The tool is simple (one fully-documented parameter, output schema present so return values need no explanation), so most information needs are already covered by structured fields. What is missing is usage routing against the many sibling company/section/filing tools and any behavioral notes, but the gap is modest given the low complexity.

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 single parameter already documents the accepted ticker prefixes (600xxx/601xxx/etc.), so the schema does the heavy lifting. The description only repeats '6-digit ticker' and adds the sse.com.cn source, which is a marginal gain over the 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 ('Resolve') and resource ('SSE-listed company') and pins the identifier to a 6-digit ticker, which cleanly separates it from siblings like get_szse_company, get_bse_company, and get_hk_company. The only softness is that 'resolve' doesn't say exactly what is returned, though the exchange qualifier carries the disambiguation.

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

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

There is no when-to-use guidance, no mention of alternatives (e.g., get_company for a generic lookup, get_sse_section/get_sse_interaction for other SSE data), and no stated preconditions. Usage can only be inferred from the verb-resource pair.

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. It names the upstream source domain but says nothing about pagination, ordering, result completeness, authentication, or rate limits for what is clearly a read fetch operation.

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

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

A single compact sentence with the resource and source front-loaded and no filler. It is efficient, though slightly terse given the tool exposes no output explanation at the description level.

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 the tool is a simple two-parameter read. Still, with no annotations the description leaves behavioral traits like pagination and result limits entirely 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 100%, so both parameters (ticker_or_name, limit) are already documented in the schema. The description adds no syntax or format detail beyond the schema, which is the expected baseline 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 (Fetch), resource (investor Q&A), and the exact scope and data source (SSE-listed company, sns.sseinfo.com). An agent can distinguish it from get_szse_interaction by the exchange named, though the description does not explicitly call out that sibling.

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: use this when you need investor Q&A for an SSE-listed company. There is no explicit statement of when to prefer this over siblings like get_szse_interaction or get_sse_company, nor any prerequisite guidance.

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

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

No annotations are supplied, so the description carries the full behavioral burden, and it discloses almost nothing: it doesn't say whether extraction is read-only, whether the section title must match exactly, what happens when a named section is absent, or whether results are cached. The only behavioral hint is that the source is a PDF rather than structured data.

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 front-loaded sentence with no filler; the market scope and source type are stated immediately. It is efficient, though arguably too terse to earn a top 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?

With an output schema present and full parameter documentation, return values and inputs are covered elsewhere, so the description doesn't need to restate them. What is still missing is the operational context that matters for a section extractor: how section titles are matched and what the agent should do when a section isn't present.

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% — ticker_or_name, year and section are each documented in the schema — so the baseline is 3. The description adds only marginal meaning, confirming that "section" is a name and that year refers to the annual report, but it does not clarify valid section titles or ticker format beyond what the schema already states.

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 ("Extract"), a specific resource ("a named section"), and constrains both the market (SSE) and the source artifact (annual-report PDF). That scoping cleanly separates it from the exchange siblings get_szse_section, get_bse_section and get_hk_section, though it never names those alternatives.

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

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

There is no statement of when to choose this over the near-identical siblings (get_section, extract_section, get_szse_section, get_bse_section, get_hk_section). Usage must be inferred entirely from the word "SSE", and no prerequisites, exclusions, or failure conditions are described.

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 supplied, so the description carries the behavioral burden. The verb 'Resolve' implies a non-destructive lookup, but nothing is said about ambiguity handling (multiple matches), error behavior for unknown tickers, or whether the call is cached. With an output schema present, return-value description is not required, so the gap is moderate rather than severe.

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 front-loaded sentence with no filler; the verb, the scope, the input constraint and the data source all land in one pass.

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

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

For a one-parameter read with a full output schema, the description covers purpose, entity type and input format, which is nearly everything an agent needs. It would be complete if it clarified the ticker-vs-name parameter naming and what happens on an unmatched ticker.

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 ticker format is already fully documented in the schema; the description only restates it. One note of friction: the parameter is named 'ticker_or_name' while both the schema and the description restrict usage to a 6-digit ticker, leaving the name branch unexplained. Baseline 3 applies since 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 ('Resolve'), a specific resource ('SZSE-listed company') and the required identifier format ('6-digit ticker'), so the operation is unambiguous. The exchange qualifier plus the (szse.cn) marker implicitly separates it from get_sse_company/get_bse_company/get_hk_company, 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?

Usage is only implied by scope: an agent can infer 'use this for Shenzhen-listed companies, not SSE/BSE/HK'. There is no explicit when-to-use statement, no exclusion, and no pointer to the sibling get_company aggregator or the exchange-specific alternatives.

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

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

No annotations are provided, so the description carries the burden alone. It does disclose the response shape and the existence of an error case, which is useful behavioral context, but says nothing about authentication, rate limits, pagination of the Q&A list, or freshness of the data.

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 tight sentences: purpose first, return contract second. No filler, and the key domain is 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?

An output schema exists, making the return-value sentence largely redundant, while the two input parameters remain entirely unexplained. Adequate to identify the tool but incomplete for calling it correctly with non-default inputs.

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 both parameters, and the description adds nothing about them. 'ticker_or_name' is ambiguous (which formats, aliases?), and 'limit' (default 20) is undocumented as to what it limits and its bounds.

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 ('Fetch') and resource ('互动易 investor Q&A for a SZSE-listed company') with the data source domain (irm.cninfo.com.cn), which is unambiguous. It implies the split from the sibling get_sse_interaction via 'SZSE-listed' but never names it, so the differentiation is left to 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?

There is no when-to-use guidance, no mention of the SSE sibling, and no conditions or prerequisites for calling it. The agent must guess that this is the SZSE counterpart and when it is preferred over other company-data 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?

No annotations are provided, so the description carries the full burden. It does disclose the return shape and the existence of an {error} outcome, which is useful signal about failure behavior, but it says nothing about permissions, what happens when the section name isn't found in the outline, or rate/PDF-fetch 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?

Front-loaded single sentence stating the action, followed by a compact return-shape block. Efficient overall, though the return-shape list is somewhat redundant given a full output schema exists.

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 3-required-param tool with 0% schema coverage and no annotations, the description omits the parameter semantics and routing guidance an agent needs. An output schema exists so return values are partly covered, but the input-side gaps leave the definition under-specified.

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?

All three parameters have 0% schema description coverage, so the description must compensate and it does not. 'Named section' gives only a faint hint about the section parameter and nothing about year format or what ticker_or_name accepts (ticker vs. company name, exchange prefix, etc.).

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 (extract) and resource (a named section from a SZSE company's annual-report PDF), and the 'SZSE' + 'annual-report PDF' scoping distinguishes it from get_sse_section, get_bse_section, and get_hk_section. It stops short of differentiating it from the generic get_section/extract_section siblings, so it's clear but not fully disambiguating.

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

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

No when-to-use guidance, no prerequisites, and no named alternatives among the many sibling section/filing tools. The agent must infer that this is the SZSE-specific variant from the name alone.

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 it discloses little: it does not say whether the index is created if absent, whether documents are overwritten or upserted, whether the operation is idempotent, or what happens on partial failure in a bulk operation. Only the implicit 'this is a write' is conveyed.

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 single sentence is front-loaded and wastes no words, but for a 7-parameter bulk mutation it reads as under-specification rather than true conciseness. There is room for prerequisite or behavior detail without bloat.

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, but this is an un-annotated mutation tool with 29% parameter coverage and no stated prerequisites, permission needs, or failure semantics. An agent lacks enough to invoke it confidently in anything but the simplest case.

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 only 29%, so the description must compensate, and it largely does not. The only parameter context supplied ('year' determines the index name, records come from ai_extract) is already in the schema, while company, section, report_id, section_id, and stock_code carry no meaning in either place.

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 (index) and resource (records), plus the bulk scope and the derived target index name cnreport-{year}. An agent knows what the call does, but nothing distinguishes it from siblings like delete_index, search_reports, or ai_extract.

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

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

There is no explicit guidance on when to use this versus delete_index, search_reports, or the extraction tools. The phrase 'extracted records' faintly implies a post-ai_extract workflow, but the prerequisite sequence and any exclusions are 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. It usefully discloses a non-obvious behavior – the CNINFO fallback and the per-row 'source' tag distinguishing bse from cninfo – which an agent could not infer from the schema. However, it omits auth/permission requirements, pagination or rate-limit behavior, and whether the fallback triggers silently or affects result ordering.

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?

Three short sentences, front-loaded with the core action and followed by the source semantics and return shape. No filler, though the 'Returns:' line is partly redundant given an output schema exists.

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-shape disclosure is a bonus rather than a necessity, and the fallback note is a genuine value-add. Still, for a four-parameter tool with zero schema coverage and no annotations, the description leaves filtering semantics and operational constraints unresolved.

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% across four parameters, so the description must compensate and does not: it says nothing about what year, limit, or title filter, nor the expected format of ticker_or_name. Only the implicit notion of 'a company's disclosures' gestures at ticker_or_name, leaving three parameters entirely undocumented.

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 (list) and resource (BSE-listed company disclosures), and the 'BSE-native, CNINFO fallback' clause pins down the exchange and data source. It is clear the tool is BSE-specific, but it never explicitly distinguishes itself from the near-identical siblings list_filings, list_sse_filings, or list_szse_filings beyond the exchange 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?

The parenthetical '(BSE-native, CNINFO fallback)' implies when this source applies, but there is no explicit statement of when to choose this over list_filings or the other exchange-specific listing tools, and no prerequisites or exclusions are given. Usage must be inferred from the exchange scope alone.

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 but only partially addresses it. It describes the entry structure (provenance, cached_at, size) but does not mention authentication needs, rate limits, side effects, or whether listing affects cache state. The added detail is useful but incomplete for a no-annotation tool.

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

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

The description is front-loaded with its purpose and then efficiently details the entry format. The second sentence is dense but informative; it could be slightly streamlined, but overall it earns its place without excess.

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

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

Given the simple nature of the tool (0 parameters, no annotations) and the presence of an output schema, the description provides adequate context by explaining what is listed and what each entry contains. However, it lacks usage context to differentiate from siblings, leaving a minor 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 has zero parameters, so the schema provides no parameter details. The description appropriately does not discuss parameters, matching the baseline score of 4 for this dimension when there are no parameters to document.

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 a specific verb ('List') and resource ('cached annual reports'). It distinguishes itself from siblings like search_reports or list_filings by focusing on cached items, allowing an agent to identify the tool's function 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?

No explicit guidance on when to use this tool versus alternatives is provided. With many sibling tools that also list or search reports, the description offers no conditions, prerequisites, or exclusions to help an agent choose correctly.

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 supplied, so the description carries the full behavioral burden, and it discloses little beyond the response envelope ({filings, count} or {error}). Since an output schema already exists, the return-shape sentence is largely redundant, and nothing is said about data freshness, live-site dependency, rate limits, or pagination 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?

Two short sentences, purpose front-loaded, zero filler. Nothing in the text is wasted even though the second sentence is partially redundant with the output schema.

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

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

For a simple two-optional-parameter list tool with an existing output schema, the description covers the essential what but leaves the parameters and any usage conditions unexplained. Adequate as a minimum but clearly incomplete on the filtering behavior.

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% across the two parameters (limit, begin_date), and the description adds nothing about them. It never mentions that begin_date filters by filing date or how limit interacts with the returned count, so an agent gets no semantics beyond the bare names.

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 ('List') and resource ('CSRC administrative-penalty / enforcement actions') and pins the source domain (csrc.gov.cn), which cleanly separates it from the sibling list_csrc_filings. It stops short of explicitly contrasting with that sibling, so the differentiation is inferable rather than stated.

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

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

There is no when-to-use guidance, no prerequisite or auth note, and no mention of alternatives such as list_csrc_filings. The agent must infer that this is the enforcement-specific counterpart purely from the resource noun.

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, yet it only implies a read operation via the verb 'List'. It says nothing about pagination, ordering, coverage window, rate limits, or what the underlying source returns, leaving the agent to guess at operational 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?

A single well-formed sentence with the resource and domain front-loaded and no filler. It is appropriately sized, though so terse that it does no structural work beyond identification.

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, but with four optional parameters, no annotations, and undocumented begin/end date filters, the description leaves key calling decisions (especially date scoping) unaddressed. It is under-specified for a list tool with temporal parameters.

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 50%: limit and category are described in the schema, but begin_date and end_date are undocumented anywhere. The description mentions no parameters at all, so it fails to compensate for the gap, notably the date-range filtering that the two undocumented parameters clearly imply.

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 (List) and resource (CSRC regulatory announcements/notices) plus the source domain (csrc.gov.cn), which lets an agent distinguish it from sibling filing listers like list_szse_filings or list_bse_filings. It is clear but does not explicitly contrast itself with the adjacent CSRC siblings such as list_csrc_enforcement or get_csrc_ipo_review.

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

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

There is no guidance on when to choose this tool over the many sibling list_* tools (list_filings, list_sse_filings, list_csrc_enforcement), nor any mention of prerequisites or exclusions. The agent must infer usage purely from the regulator name in the description.

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 but only implies a read operation via 'List'. It omits pagination behavior, ordering, default result size, and any auth or rate-limit context. The schema mentions error conditions, but the description adds essentially no behavioral insight.

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 front-loaded sentence with no filler. It is efficient, though arguably too thin for a five-parameter listing tool, which slightly undercuts the benefit of its brevity.

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

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

An output schema exists, so return values need not be described, and the parameter schema is thorough. However, the description leaves the source-versus-sibling distinction and any usage caveats entirely to inference, making it only adequate rather than 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%, so all five parameters (form, year, limit, category, ticker_or_name) are already documented in detail, including mutual exclusivity and error behavior. The description adds nothing 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?

The description states a specific verb (List) and resource (CNINFO disclosures) scoped to a CN-A-share company. Naming CNINFO implicitly separates it from the SSE/SZSE/BSE/HK filing siblings, though it never explicitly contrasts 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?

There is no when-to-use or when-not-to-use guidance, and no mention of the sibling listing tools (list_sse_filings, list_szse_filings, etc.) that select a different exchange. The useful exclusivity rules (form vs category, use list_report_types) live only in the schema, not the description.

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, yet it discloses nothing beyond the basic listing action — no mention of default ordering, pagination behavior, rate limits, or whether results are cached. For a read-only list tool this is a modest gap, but with zero annotation coverage the disclosure is thin.

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 tight sentence with no filler, front-loading the verb and resource. It is arguably too terse given the missing usage guidance, but nothing in it is wasteful.

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 all four parameters are documented in the schema. However, the description lacks the disambiguation against the many sibling filing-listing tools that an agent would need to select confidently.

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 meanings of ticker_or_name, form, year, and limit are already documented in the schema with defaults. The description adds no syntax, format, or example guidance beyond what the schema provides, 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?

States a specific verb (List) and resource (filings/announcements) with exchange scope (HK stock company), which implicitly separates it from list_szse_filings, list_sse_filings, and list_bse_filings. It does not explicitly name or contrast with those siblings, but the HK qualifier is enough for an agent to route correctly.

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 gives no when-to-use guidance, no prerequisites, and no indication of how it relates to nearby tools like list_filings, get_hk_company, or get_hk_section. It simply states what the tool does with no context on selection.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond the data source ('data-driven by indicator_rules.json'). It does not confirm read-only semantics, describe result shape/ordering, or note the error behavior that the schema mentions for unknown modules.

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 efficient sentence with the key concept front-loaded. It is well-sized, though it is arguably under-specified rather than optimally concise.

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 all three optional parameters are fully documented in the schema. Still, for a listing tool with no annotations, the description is thin on scope and usage, leaving it merely adequate.

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 query, module, and company in detail (including the enum-like module values and filter semantics). The description adds no parameter meaning 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?

The description states a clear verb+resource: 'Browse the banking-indicator rule set.' An agent can infer this enumerates indicator rules, and the name reinforces it. However, it never distinguishes itself from close siblings like get_indicator, extract_indicators, or audit_rule_gaps, so it stops short of 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 description offers no when-to-use, when-not-to-use, or alternative routing guidance. Useful context (previewing indicators before calling extract_indicators) exists only inside the schema's company parameter, not the description, so the description itself provides no selection guidance.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the exact return envelope, including the {error} branch, and 'supported' implies a static enumeration, which is genuinely useful. However, it says nothing about the read-only nature, error conditions, or whether the list can change, leaving gaps for an unannotated 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?

Two short sentences, purpose front-loaded before the return shape, with no filler. Every clause carries 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?

With an output schema present and zero parameters, the description need not explain return fields in detail, and it already names the envelope. What is missing is the relationship to get_ministry_stat and any hint about how the listed sources should be used.

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 the baseline of 4 applies and there is no parameter meaning for the description to add.

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 ('List the supported ministry statistics sources'), which clearly distinguishes it from the get_ministry_stat sibling that retrieves a single stat. It does not explicitly name or contrast any sibling, but the list-vs-get distinction is inferable from the verb choice.

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

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

There is no explicit statement of when to call this versus alternatives or any prerequisite context. Usage is only implied: listing the supported sources suggests it is the discovery step that yields ids for get_ministry_stat, but the description never says so.

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, yet it discloses almost nothing beyond the basic action. It does not say the tool is read-only, does it mention network fetching behavior, rate limits, failure modes on unreachable URLs, or how the fetched report relates to caching/session state. For a no-annotation tool this is a notable gap.

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

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

A single sentence with no filler, front-loading the action and the returned artifact. Efficient, though perhaps under-specified rather than truly concise.

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 explained, and the single required parameter is fully documented in the schema. What remains missing is usage routing versus siblings and any behavioral profile, so completeness is only adequate for this simple fetch 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 both parameters (source formats, fetcher reserved note). The description adds only the 'Chinese annual report' scope, which is marginal beyond the schema. 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?

The description states a specific verb (Fetch), a specific resource (a Chinese annual report), and a specific return (its 目录 outline). An agent can tell this returns a table of contents rather than a section body. However, it does not differentiate itself from sibling section/extraction tools like get_section or extract_section, leaving the boundary unstated.

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

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

There is no statement of when to use this tool versus the many siblings (get_section, extract_section, search_reports, get_filing). No prerequisites, no exclusions, no alternative routing. The agent must infer usage entirely from the name and description.

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 burden. 'Browse' implies a non-destructive read, and an output schema exists so return structure need not be described, but the description omits any explicit read-only statement, pagination behavior, or result-size 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?

A single tight sentence with the resource front-loaded and no filler. It is efficient, though the extreme brevity buys conciseness at the cost of any actionable detail.

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 single optional-parameter catalog tool with an output schema, the description is minimally viable: return values need not be explained, but it never tells an agent when this catalog is useful versus the many other list/search siblings. The core enumeration intent is covered, nothing more.

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% and the single optional 'group' parameter is fully documented in the schema with example values, so the baseline is 3. The description adds nothing about the filter parameter beyond what the schema already states.

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 ('Browse') and resource ('CNINFO disclosure category catalog'), so an agent knows it enumerates disclosure categories. However, it does not distinguish itself from sibling listing tools such as list_ministries, list_filings, or search_reports, leaving the boundary implicit.

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 gives no when-to-use guidance, no prerequisites, and no alternatives. It never explains that this is the tool to call to discover valid category values before using other report tools, which is the obvious routing decision an agent faces.

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. It adds only that data comes 'directly from sse.com.cn'; it does not state that the operation is read-only, how results are ordered, whether pagination beyond 'limit' applies, or any rate/auth constraints for a live external source.

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 tight sentence with the resource front-loaded and zero filler. Appropriate size for the operation.

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 params are fully described. However, with no annotations and no usage guidance, the description is thin for a tool sitting among many near-identical sibling filing listers.

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 year, limit, title, and ticker_or_name with examples. The description contributes no additional parameter meaning, 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 (List) and resource (a SSE-listed company's disclosures), which implicitly separates it from the many sibling list_*_filings tools (SZSE/BSE/CSRC/HK). It identifies the market and data source, but does not explicitly differentiate itself from get_sse_company or get_sse_section.

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

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

No when-to-use, when-not, or alternative guidance. With siblings like list_szse_filings, get_sse_section, and get_company available, an agent gets no help choosing this tool over them beyond the 'SSE' in the name.

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. It discloses the live upstream source (szse.cn) which is genuine added context, but says nothing about rate limits, pagination, or how the default limit=20 behaves. The stated return shape largely duplicates the output schema.

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 sentences, front-loaded with the action and scope. The second sentence is brief but redundant with the existing output schema, which mildly dilutes the otherwise efficient 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?

An output schema exists, so return values need not be re-explained (the description's return line is unnecessary). The real gap is the four undocumented, description-free parameters for a read tool with no annotations; the definition is minimally adequate but incomplete on filtering behavior.

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% across four parameters (ticker_or_name, year, title, limit), and the description supplies no clarification. It never explains that year/title are filters or what limit controls, so an agent must guess parameter semantics from names alone.

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 (List) and resource (a SZSE-listed company's disclosures) with source scope (directly from szse.cn). This cleanly separates it from the many sibling list_*_filings tools (list_sse_filings, list_bse_filings, list_csrc_filings, generic list_filings) because the exchange and data source are named.

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 — an agent can infer you call this to retrieve SZSE disclosures — but there is no explicit when-to-use, when-not, or comparison against list_filings / get_szse_section / get_szse_company. No preconditions or alternatives 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 behavioral burden, and it does disclose the key non-obvious trait that this launches a local web server at http://localhost:<port>. However, it omits the behavior that matters most for an agent: whether the call blocks while the server runs, whether a busy port causes failure, and how the dashboard is stopped. Those lifecycle traits are left entirely to inference.

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 action and followed by concrete scope and features. No filler, no restatement of the tool name, and the most decision-relevant information (what it opens and what's in it) comes first.

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 the content scope is well covered. The gap is behavioral: for a server-launching tool the agent still lacks blocking/termination semantics, which no structured field supplies.

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?

One optional parameter with 100% schema description coverage, so the schema already documents port, its default of 8888, and its type; the description adds nothing beyond echoing it as <port> in the URL. Baseline 3 is appropriate when the schema does the work.

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 ('Start the industry rules web dashboard') and then quantifies the scope it exposes: 21,698 rules across 31 申万 L1 industries with filtering, search, sorting, and pagination. That is enough for an agent to distinguish it from the data-retrieval siblings like list_outline or search_reports, which return records rather than launching a UI.

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 by the feature list — an agent can infer this is for interactive browsing/filtering rather than programmatic record retrieval — but the description never states when to prefer it over the many list_*/get_* siblings, nor any prerequisites or exclusions. The filtering capabilities hint at the use case without naming an 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?

No annotations are provided, so the description carries the full burden, yet it discloses almost nothing: it does not state that the operation is read-only, how pagination works (size/from_ exist in the schema), result limits, or ordering. The mention of 'highlights' is the only 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?

A single front-loaded sentence with no filler, but it is arguably too terse for a 7-parameter tool, leaving room that could have been spent on filters 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 no explanation, but with 7 parameters at 29% coverage, no annotations, and no usage guidance, the definition is too thin for an agent to invoke it confidently.

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 only 29% (only query and year are documented). The description says 'filtered search' but never explains what company, section, stock_code, size, or from_ mean, so it fails to compensate for the large 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 ('search') and resource ('cnreport indices') plus the mode ('full-text + filtered') and a return trait ('highlights'). That distinguishes it from get_*/list_* siblings, but it doesn't name which sibling to prefer, so it stops short of full 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?

There is no statement of when to use this tool versus alternatives like list_report_types, get_filing, or get_section. Usage is only implied by the word 'search'; no prerequisites or exclusions are given.

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