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

With no annotations, the description carries the burden and does add real context: the data is CC0, community-maintained, and may be unreliable, and it names the returned fields. It omits any mention of pagination/result limits, matching behavior (fuzzy vs exact), or empty-result handling.

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

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

One compact sentence with the search keys and source front-loaded, followed by the return fields. The parenthetical caveat is worth its words, though the field list is somewhat 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-parameter lookup, the description covers source, reliability, accepted inputs, and outputs, and an output schema exists so return values need not be detailed. The remaining gap is behavioral detail on limits and match strictness.

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains the required 'query' parameter (English or Chinese name, or stock code), which is the key ambiguity, but says nothing about 'limit' beyond what the schema's default=10 implies.

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 (Find) and resource (HK-listed companies) plus the exact keys accepted (English/Chinese name or stock code) and the data source (Wikidata). It is clearly distinct from the IPO-rules/sell-cost siblings, though it never names or contrasts them 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 the accepted query forms; there is no statement of when to prefer this over hk_listings or the IPO tools, and no note on when results should be distrusted beyond a generic verify caveat. The 'verify before relying on it' note is more of a data-quality warning than 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?

With no annotations, the description carries the full burden, and it does well: the explicit fee formula makes clear this is a deterministic, side-effect-free calculation with defined rounding ('each rounded to the cent'). It stops short of stating outright that it performs no transaction or that the result is not a guarantee of allotment, but the calculation nature is unambiguous.

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, both dense with useful content: the first defines the computation and its exact fee components, the second delivers the one-lot shortcut. Nothing is redundant and the core definition 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?

For a two-parameter pure calculator with no output schema, the description provides enough to call it correctly and to understand the composition of the result. It does not explicitly say the return value is a single monetary amount, which is the only remaining ambiguity.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: offer_price is identified as HK$ currency and shares as a share count, plus the practical alias that board lot size yields the entry fee. The rounding convention is also conveyed. Minor gap: no stated type/range expectations for offer_price beyond currency units.

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

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

The description names the exact computed quantity (amount payable to apply for HK IPO shares) and enumerates the components that make it up, so there is no ambiguity about what the tool returns conceptually. It is clearly distinct from siblings like hk_sell_costs or hk_ipo_plan, which cover different stages of the workflow.

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 offers one concrete usage hint — pass shares = board lot to get the one-lot 'entry fee' — which is genuinely useful. However, it never states when to use this tool versus alternatives (e.g., hk_sell_costs for exit costs) or any preconditions, so routing still requires inference from 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 burden and does well by disclosing the calculation model: margin interest as loan × rate × days / 365, break-even pricing with stamp duty rounding, and P&L under day-one scenarios. It does not discuss error behavior or assumptions, but the core computational behavior is unusually transparent.

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

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

The description is front-loaded with the tool's purpose and then packs useful formulas and unit clarifications into a compact paragraph. It is dense but not wasteful, and every clause contributes to understanding the calculation.

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

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

For a complex 16-parameter financial calculator with no annotations and no output schema, the description covers the main outputs and key calculation rules. However, it leaves many optional parameters and output structure details unspecified, so it is adequate but not fully complete.

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

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

Schema description coverage is 0% across 16 parameters, so the description must compensate. It clarifies important semantics for annual_rate, sell_commission_rate, allot_probability, valid_applications, and successful_applicants, but many inputs such as handling_fee, financing_fee, scenarios_pct, sell_platform_fee, and sell_min_commission remain undocumented beyond their titles.

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 resource and scope: a full HK IPO subscription plan covering entry fee, payable amount, margin loan, break-even sell price, and scenario P&L. It is clear what the tool computes, but it does not explicitly distinguish itself from siblings such as hk_ipo_amount_payable or hk_sell_costs.

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 does not say when to use this tool versus hk_ipo_amount_payable, hk_sell_costs, or other siblings. It gives an alternative input method for allotment probability, but that is parameter guidance rather than tool-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 behavioral burden. It adds that results are 'cited,' which is useful, but it does not disclose source authority, return format, limitations, or whether this is a read-only lookup. For a rule-reference tool with no annotations, this is a meaningful 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?

The description is one compact sentence with zero waste. The core purpose is front-loaded, followed immediately by the accepted topic values.

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 simplicity (one optional parameter, no output schema, no annotations), the description is minimally sufficient. It tells the agent the resource and allowed topic values, but leaves unclear what each topic returns and what 'cited summary' implies for output structure.

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?

There is one parameter with 0% schema description coverage and no enum in the schema. The description compensates by defining the accepted topic values: fees, allocation_mechanisms, pools, settlement, and all. It does not explain what each topic covers, preventing a 5.

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 resource and operation: a cited summary of HK IPO rules. It also enumerates the topical scope, making the tool's domain clear. It does not explicitly differentiate itself from siblings like hk_ipo_plan or hk_sell_costs, 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 topic list implies when to use the tool for fees, allocation mechanisms, pools, settlement, or all rules, but there is no explicit when/when-not guidance or comparison to sibling tools. Usage is inferable from the parameter options 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 and does disclose useful traits: the upstream source and licence (Wikidata CC0), the default sort order, and a data-quality caveat about incomplete recent-IPO coverage. What is missing is whether results are paginated or truncated by limit and whether the call has any side effects (implied read-only by 'listings' but not 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?

Two tight sentences: the identity, source and ordering come first, then the date-format rule and the coverage caveat. Every clause carries information an agent would otherwise have to guess.

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 three-parameter read tool with an output schema (so return values need not be described), this covers identity, ordering, date formats and data caveats. The remaining gap is limit behavior, which matters because callers will want to know if 30 is a ceiling.

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

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

Schema description coverage is 0%, so the description must compensate and it partly does by specifying that since/until take YYYY-MM-DD. The limit parameter is untouched — no indication of whether it is a page size, a cap, or what happens above the default of 30 — leaving one of three parameters undocumented anywhere.

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

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

The description names the resource precisely (HK listings that have a listing date in Wikidata), states the ordering (newest first) and the data source/licence (CC0). It is not just a restatement of the name, and the explicit note that IPO terms are excluded separates it from the hk_ipo_* siblings, though it never says which sibling to use instead.

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?

"Coverage of recent IPOs is incomplete; IPO terms are NOT included" implies that IPO-term questions belong to hk_ipo_rules / hk_ipo_plan etc., but the routing is left to inference rather than stated. No explicit when-to-use or when-not-to-use condition 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?

With no annotations, the description carries the full burden, and it does disclose real behavior: the fee schedule, rounding conventions ('rounded up to HK$1', 'each to the cent'), and that totals and net proceeds are returned. It omits what happens when the optional commission/platform parameters are left at their zero defaults, and does not state currency or whether gross consideration is price × shares.

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 cost breakdown and closed with the return values; the dense rate list is the substance of the tool rather than filler. Only minor gain available from tighter phrasing of the rounding clauses.

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?

There is no output schema, no annotations, and only 2 of 5 parameters are required, yet the description says nothing about defaults or how the optional broker inputs interact. For a small deterministic calculator the fee/rounding/return coverage is decent, but the parameter behavior an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0% across five parameters whose only documentation is a bare title. The narrative hints at commission_rate and platform_fee via '+ broker commission/platform fee', but leaves min_commission (a commission floor) unexplained and never states whether commission_rate is a decimal fraction or a percentage.

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

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

The description names a specific resource (HK share sell-side costs) and enumerates the exact fee components plus 'Returns total and net proceeds', so an agent knows this is a cost calculator rather than a lookup. It is clearly distinguishable from the IPO-oriented siblings, though it never uses an explicit verb like 'calculate'.

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 phrase 'Costs of selling HK shares' and by the fee-rate listing, which tells the agent this is the sell-side fee computation. There is no explicit when-to-use/when-not statement, no mention of a buy-side counterpart, and no note about prerequisites such as needing broker commission inputs.

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