熔岩 Lava

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

Annotations already cover readOnlyHint and idempotentHint, so the safety profile is known. The description adds a genuinely useful fact not in the annotations: calling it is free / not billed, which affects how liberally an agent should use it. It also discloses the return shape, though not rate limits or failure behavior.

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

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

The 'no charge' fact is stated three separate times ('不扣钱', '查这个不扣钱', '不计费') across a four-clause description, wasting roughly a third of the text. The substantive content (purpose + return values) is front-loaded, but the restatement is clear 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?

For a zero-parameter read tool with no output schema, the description supplies what the schema cannot: an enumeration of returned fields and the billing implication. Only minor gaps remain, such as whether values are real-time and what happens on auth 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline applies. Nothing in the description misleads about inputs.

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 (check balance and usage) and immediately enumerates the returned values: balance, unit price, estimated remaining calls, today's call count. This is clearly distinguishable from the news/stock/market siblings, none of which return account state.

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 rather than stated: 'check this' is contextual, and the cost signal ('doesn't deduct money') nudges the agent to call it freely, which is a mild usage cue. There is no explicit when-to-use vs. when-not framing, though the sibling set is unrelated enough that routing is not ambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: each call is billed once and results are ordered chronologically from earliest to latest, by publishing day.

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 two short sentences plus a billing note, with the core purpose front-loaded. Every sentence earns its place by conveying scope, ordering, and cost.

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 a simple read operation with full schema coverage and annotations, and the description discloses ordering and billing. It is nearly complete, though it could better distinguish this tool from sibling agency-related tools for an agent choosing among them.

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 agency_id, start_date, end_date, and limit are already documented in the schema. The description reinforces the per-publishing-day and chronological aspects but adds no parameter-level syntax or filtering 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?

The description states a specific resource and scope: historical score trend for a single anonymous agency/influencer, with chronological ordering and per-publishing-day scores. It is clear what the tool returns, but it does not explicitly differentiate itself from sibling tools such as get_agency_pit or list_agency_pit_dates.

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 explicit guidance on when to use this tool versus alternatives. The closest it comes is implying single-entity use through '单个匿名机构/大V', but there is no statement about when-not-to-use or which sibling handles related queries.

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

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

Annotations already state that this is a read-only, idempotent, closed-world tool. The description still adds real context: it says there is no lookahead, that the result is the most recent published date not later than as_of_date, and that each call is billed. This last point about fallback behavior is not obvious and is not in the schema; it is behavior an agent would otherwise have to guess.

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 compact and front-loaded: the purpose and PIT definition come first, then the result semantics, then billing. It repeats the title string at the start, which is mild redundancy, but nothing else 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 five-parameter read tool with no output schema, the description covers purpose, as-of-date fallback behavior, and cost. It could say more about the shape of the returned records, such as the fields of a score entry, but an agent has enough to invoke it correctly.

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

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

Schema coverage is 100%, so the parameters are already documented. The description adds the non-obvious fallback semantics of as_of_date ('returns data for the most recent published date not later than as_of_date'), which goes beyond the schema's 'snapshot date' label. The other parameters (limit, offset, min_score, agency_id) get no extra meaning beyond their schema descriptions.

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

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

The description uses a concrete verb and resource: it looks up a point-in-time score for an anonymous agency/KOL on a given day. The parenthetical definition of PIT ('only uses data known that day, does not peek at the future') clearly distinguishes it from plain history or ranking siblings. It does not explicitly name get_agency_history or get_agency_ranking, so it falls short of a top score.

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

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

'适合回测' gives a clear use case for when to prefer this tool. It also warns about cost ('每次调用计费 1 次'), which helps an agent decide whether to call it. It names no alternative sibling or exclusion condition, which keeps it at 4 rather than 5.

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

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

Annotations already establish readOnly, idempotent, and closed-world behavior, so the description's added value is in the domain layer: it discloses per-call billing (每次调用计费 1 次), the score scale (~450-1500 with ~1000 as middling), and which fields come back (score, effective sample count, win rate). These are genuinely useful for interpreting results and for cost-aware invocation; only pagination/limits behavior is left unaddressed.

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 plus a bracketed billing note; the purpose is front-loaded, the identifier semantics come next, and the cost caveat is parenthetically isolated. Nothing is redundant with the schema or 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?

With no output schema, the description carries the return-value burden and does name the key returned fields plus their interpretation scale, which is sufficient for an agent to consume results. Minor gaps remain on result ordering guarantees and pagination semantics across the full 500-row cap.

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

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

Schema description coverage is 100%, so baseline is 3, but the description goes further by explaining what the 'score' value actually means and its numeric range, which makes the order='score' enum and min_score filter interpretable rather than abstract. It does not add anything for offset/limit beyond the schema, hence a 4 rather than 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?

States a specific resource (an anonymous agency/KOL scoring ranking) and marks it as the current snapshot, which implicitly contrasts with the history/pit siblings. It also explains that agencies are identified by a stable anonymous agency_id, so an agent knows what the records represent. Sibling differentiation is present but only via the '当前' qualifier rather than an explicit named alternative.

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 '(当前)' marker implies this is the tool for present rankings and that get_agency_history / get_agency_pit cover past data, but this is never stated explicitly. There is no guidance on when to prefer it, no prerequisites, and no exclusion cases; the agent must infer the choice from sibling names.

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

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

Annotations already cover read-only/idempotent/closed-world, and the description adds two genuinely useful facts not in structured fields: data freshness (~10 min refresh) and a per-call billing cost of 1. It still doesn't say what happens with an unmatched concept name or whether 'days' windows beyond available history degrade.

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

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

Compact and front-loaded: what it returns, then aggregation semantics, then freshness and cost. The opening clause duplicates the title almost verbatim, a small redundancy, but nothing else 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?

Without an output schema, the description still conveys the shape of the result (per-stock mention counts plus institution/KOL mention counts), which is the key missing piece. What remains absent is sibling disambiguation and edge-case behavior for unmatched or sparse concepts.

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%, including defaults, bounds and the ≤30-char exact-match constraint on 'concept', so the schema does the heavy lifting. The description only hints at the time window ('最近一段时间') without tying it to the 'days' parameter, adding no new 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?

States a specific resource (concept-sector heat) and the exact aggregation returned: per-stock mention counts for a given concept. It is distinguishable from get_market_hot_concepts by being concept-scoped, but it never explicitly contrasts with the near-namesake sibling get_stock_concept_heat (the inverse lookup), leaving some ambiguity.

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

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

No guidance on when to use this versus get_stock_concept_heat, get_market_hot_concepts or get_weighted_hot_stocks. The only usage-adjacent statement is the billing note, which tells the agent this call costs money but not when it is the right call.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's job is to add context, and it does: it discloses the per-call billing cost and enumerates exactly what each row contains (first-mention time, first-mentioning ID and score, source category, re-mention count). It does not discuss ordering, empty results, or rate limits beyond the billing note.

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 concept and its defining window are front-loaded, followed by returned fields, the use case, and the billing note. Slight redundancy: the "此前 7 天没人提" rule appears in both the opening clause and the second sentence.

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 no output schema, the description carries the return-value burden and does list the row fields. Missing only minor operational details such as result ordering and behavior when nothing qualifies; sufficient for a read-only discovery tool with fully documented 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 description coverage is 100%: hours, limit, source, and min_score are all documented in the schema, including the enum values and the score scale. The description only restates "最近 N 小时" and adds no extra meaning, so the baseline of 3 applies.

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

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

The description states a specific operation on a specific resource with a clearly bounded definition: stocks first mentioned in the last N hours that had zero mentions in the preceding 7 days. That criterion alone separates it from get_market_hot_stocks and get_weighted_hot_stocks, 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?

It gives an explicit use case — "适合发现新冒头的标的" (good for spotting newly emerging names) — which is clear context for when to pick this tool. It stops short of saying when not to use it or which sibling to use instead for热度 ranking versus first-mention discovery.

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

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

Annotations already cover read-only/idempotent/closed-world, and the description adds genuinely non-structural facts: ~2 minute refresh cadence, a per-call billing cost of 1, descending sort order, and that generic market terms are pre-filtered out. It does not describe item shape or whether results can be empty, but the added operational context is above the annotation-covered bar.

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 dense front-loaded sentence names the tool's job, then statistics, ordering, filtering, refresh rate and billing each appear once with no padding. Parentheticals are compact; nothing is redundant with the title.

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 no output schema, the description carries the return-value burden and does explain the key fields (mention counts, institution/KOL counts, rank order). Minor gaps remain: per-item fields and the absence of a note on empty results or how limit interacts with ranking are not covered, but an agent can call this correctly.

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

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

Schema coverage is 100% and all four parameters (limit, source, window, min_score) carry their own descriptions including enum meanings and score ranges. The description restates the 1h~3d window but adds no semantics 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 and resource: rank market-wide concept sectors by heat, with the scoring basis (mention count, number of institutions/KOLs mentioning) and explicit noise filtering of generic terms like '美股'/'A股'. This differentiates it from get_market_hot_stocks (stocks) and get_concept_stock_heat (per-concept stocks), though it never names those siblings directly.

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 '最近哪些概念板块最热' and the time-window framing, but there is no explicit when-to-use vs when-not, and no routing to the many adjacent siblings (get_market_hot_stocks, get_concept_stock_heat, get_stock_concept_heat). An agent has to infer the choice from name semantics 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?

Annotations already declare readOnly and idempotent, so the bar is lower; the description still adds non-trivial operational facts: data refreshes roughly every minute and each call is billed once. It also discloses the merge semantics differ by market mode, though the schema covers that. It does not describe response shape or pagination limits, keeping it below a 5.

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

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

A single dense front-loaded sentence stating the resource and metrics, followed by a short filtering/meta note. Every clause carries information, though the metric list is slightly compressed and the billing note could be split for readability.

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, and the description compensates by enumerating the returned metrics and sort order. Combined with the fully documented input schema and safety annotations, an agent has enough to call it correctly; only the exact response field names and any truncation behavior remain unspecified.

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

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

Schema description coverage is 100%, including enum explanations for source, market, and window, plus min_score calibration guidance, so the baseline is 3. The description adds only a coarse restatement of window range and the source/min_score filtering idea, no syntax or format 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?

The description gives a specific verb and resource: rank all-market stocks by mention volume, with the exact metrics computed (mention count, distinct institution/KOL count, first and most recent mention times, sorted descending). It does not name any sibling such as get_weighted_hot_stocks or get_stock_heat_windows, so the agent must infer differentiation from metric wording alone.

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

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

It states the relevant context (time window from 1h to 7d, optional source filtering, optional high-score institution filtering) and the refresh cadence, which helps an agent decide if it is applicable. However, it never says when to prefer this over get_weighted_hot_stocks or get_first_mention_stocks, nor any exclusion or prerequisite, so usage remains implied.

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

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

Beyond the readOnly/idempotent annotations, it discloses non-obvious traits: output omits titles and body text, data refreshes roughly every 2 minutes, and each call costs 1 billed call. It also states the applicable time-window bounds per mode. These are operational facts the agent cannot get from structured fields alone.

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 paragraph, front-loaded with the resource and source list, then the output shape, then mode behavior, then freshness and pricing. No sentence is padding; the billing note earns its place as decision-relevant 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?

There is no output schema, so the description carries the return-shape burden and does so: publish time, media, matched stocks, plus a top-mentioned-stock ranking with 24h heat. Combined with the refresh cadence, cost, and window bounds, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the mode semantics that the schema does not state: omitting a stock means market-wide view, while supplying ts_code/stock_name restricts to news mentioning that stock. This complements the schema's per-parameter notes on source and hours defaults.

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 and resource: it matches financial-media news to A-share tickers and returns the hits plus a ranking. It also scopes the tool by listing the media sources and by explicitly excluding titles and body text, which helps separate it from siblings like search_news_flow. It never names a sibling directly, so the differentiation is implied 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?

It gives conditional usage guidance ('不给股票时看全市场；给股票时只看点名它的新闻'), which tells the agent how parameters change behavior. However, it gives no guidance on when to prefer this over related tools such as get_first_mention_stocks or get_stock_news_heat, and no exclusions.

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

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

Annotations already declare readOnly, idempotent, closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses per-call billing cost ('每次调用计费 1 次') and the aggregation window, both of which affect invocation decisions. It could go further on default lookback semantics, but the billing disclosure is a genuinely useful addition.

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

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

Two sentences, no filler, with the core resource statement front-loaded and the billing note trailing. The metric enumeration earns its place by previewing the return shape in the absence of an output schema. Slightly dense repetition of '某只股票关联' across both sentences keeps it from a 5.

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

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

With no output schema, the description compensates by naming the returned fields (mention counts, first/last mention timestamps, institution/KOL counts), which is what an agent needs to decide whether to call it. The main remaining gap is the absence of any sibling differentiation, which matters given a large cluster of heat-related 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 all four parameters including defaults, min/max, and the ts_code/stock_name either-or constraint are already documented. The description only loosely restates the time window ('最近一段时间') and adds no syntax or format guidance beyond the schema. Baseline 3 applies when the schema carries the load.

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

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

The title and opening sentence give a specific verb+resource: it computes concept heat for one stock, listing which associated concepts are hottest. The second sentence enumerates the metrics returned (mention count, first/last mention time, number of institutions/KOLs), so the agent knows exactly what the tool produces. It does not name the reverse-direction sibling (get_concept_stock_heat) or get_stock_news_heat, so 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?

Usage is implied by the '某只股票关联哪些概念最热' framing – the agent infers it should call this when it has a stock and wants concept-level heat. There is no explicit when-to-use/when-not-to-use statement and no routing to alternatives like get_concept_stock_heat, which is the mirror-image tool an agent could easily confuse it with.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: that each call is billed once ('每次调用计费 1 次') and that all windows plus hourly series come back in a single call. It does not discuss limits on freshness or data lag, which is the only remaining 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 output content is front-loaded in the first two clauses, the use case follows, and the billing note is placed last. It is dense with enumerations but every clause carries information; the only mild redundancy is restating the time windows already implied by the title.

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 no output schema, the description does the heavy lifting by enumerating the return fields and their time windows, and it discloses per-call billing. One gap remains: the schema marks zero required parameters while both ts_code and stock_name are described as '二选一', and the description never states that at least one identifier must be supplied, which an agent could get wrong.

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 ts_code, stock_name, and min_score (with default 1050) are fully documented in the schema, which sets the baseline at 3. The description adds nothing param-specific — it does not restate the ts_code/stock_name either-or constraint or explain what min_score changes in the returned 'high-score' counts, so it neither compensates nor detracts.

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 (single-stock heat trend) and enumerates exactly what is returned: mention counts, institution/KOL counts, high-score institution/KOL counts, weighted heat for 1h/4h/18h/24h/3d/7d, plus hourly detail over 24h. That is far more precise than a name restatement. It does not explicitly distinguish itself from close siblings such as get_stock_news_heat or get_stock_concept_heat, which keeps it off 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 phrase '适合盯单股热度怎么起来、怎么回落' gives a use scenario (tracking how a single stock's heat rises and fades), which is meaningful context. However, it offers no exclusions and never names an alternative when a different tool (e.g. news-level or concept-level heat) would be the better pick, so selection guidance against siblings is implicit only.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety is covered. The description adds genuinely new operational context: each call is billed once (每次调用计费 1 次) and the returned scope excludes sentiment and raw text. It does not mention pagination behavior beyond the limit parameter, which is already in the 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 content is front-loaded with the purpose, followed by returned fields and then the exclusions and billing note. It is moderately sized and every clause carries information, though the opening restates the title's '个股消息面热度' phrasing, which is minor redundancy.

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 7 optional parameters, no output schema, and rich annotations, the description fills the main gap by enumerating the returned fields and heat metrics. Only minor items like default time-window behavior when neither days nor start_date is supplied are left entirely to the schema, which does cover them.

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 every parameter including defaults, ranges, and the ts_code/stock_name either-or relationship documented in the schema. The description adds no parameter-level detail 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?

The description states a specific verb and resource: retrieve recent news-mention records for a single stock, including summary, key points, involved stocks/concepts, and heat counts. It also scopes content by excluding bullish/bearish views and original text, which helps distinguish it from text-oriented siblings like search_news_flow or get_news_stock_hits. The distinction is implicit rather than naming a sibling outright.

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 'query recent news records for a stock' and the explicit exclusions ('不含多空观点、不含原文') tell the agent when this tool is the wrong choice for sentiment or full-text needs. However, no alternative tool is named and no explicit when-to-use vs. when-not-to-use routing is given, leaving the agent to infer sibling 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?

Beyond the annotations, the description discloses the weighting formula, the minimum-score filter and its approximate percentile meaning, PIT/no-lookahead behavior, the 15:00 cutoff when as_of_date is supplied, the maximum number of returned agency IDs, and that each call costs 1 billing unit. These are exactly the behavioral details an agent needs.

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

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

The description is front-loaded with the purpose, then gives the scoring formula, PIT/backtest behavior, return scope, and billing in a compact paragraph. It is dense but every sentence carries operational value.

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 six-parameter tool with no output schema, it covers the core behavior, filtering, PIT semantics, return-ID cap, and billing well. The main remaining gap is that the returned stock-list fields and ranking structure are not described in detail, though the tool’s core output is understandable.

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 already 100%, so the baseline is 3, but the description adds useful meaning: min_score default 1050 corresponds roughly to the top 10%, and as_of_date applies a same-day 15:00 cutoff for backtests. It does not explain every parameter beyond the schema, but it materially enriches the important ones.

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 ranking resource and its unique scoring mechanism: only high-score agency/big-V mentions are counted and weighted by score. It is clear what the tool produces, though it does not explicitly name sibling tools such as get_market_hot_stocks or get_first_mention_stocks for 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?

It explains the backtesting use case for as_of_date and that the default threshold is about the top 10%, which implies usage. However, it does not explicitly say when to choose this tool over the many sibling hot-stock/mention tools, so alternatives remain 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?

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered; the description adds genuinely useful context beyond them: the sort direction (newest to oldest) and an explicit cost warning of 1 billed call per invocation, which is not expressible in the annotations.

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

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

Two short sentences, front-loaded with what the tool lists and what each row contains, followed by the cost note. Slight overlap with the title's wording, but no wasted content.

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 no output schema, the description carries the burden of describing returns and does so adequately (dates plus per-day agency/influencer counts, ordered newest-first) and flags billing. Only the linkage to the follow-up per-date tool is left implicit.

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

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

Schema description coverage is 100% and the single limit parameter is fully documented in the schema (default 60, max 500). The description adds no parameter meaning beyond that, 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 resource (dates that have PIT historical scores) and states exactly what is returned: published scoring dates in descending order with a per-day count of agencies/influencers. It is clearly distinct from sibling get_agency_pit, though it does not name that sibling 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?

The listing-plus-count framing implies this is a discovery/enumeration step preceding a per-date lookup such as get_agency_pit, but the description never states when to use this versus those alternatives or any prerequisite/exclusion.

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?

注解已经说明这是只读、幂等的操作；描述又补充了重要的额外行为：结果按最新在前排序，并且每次调用计费 1 次。它还说明了关键词匹配语义；对于这个简单搜索工具，这些信息已经足够明确。

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?

描述很简洁，并且先说明核心操作，再说明关键词匹配规则、排序规则和计费提示。几乎没有多余内容。

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?

对于使用 3 个参数、没有输出模式的简单搜索工具来说，描述已经覆盖了用途、关键词行为、排序和计费成本。次要的缺口是它没有说明返回哪些记录字段，但根据规则，这并不一定必需。

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?

输入模式对参数的说明覆盖率为 100%，因此参数含义的基线分数是 3 分。描述对核心的 `keyword` 参数补充了多于输入模式的信息，即最多 5 个空格分隔的词、所有词都必须包含；虽然它没有说明 `limit` 和 `since`，但这两个参数已经在输入模式中说明。

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?

明确写出了具体操作“搜”和资源“消息面记录”，因此作用很明确。它没有说明自己与相关兄弟工具（例如 get_news_stock_hits）的区别，所以没有拿到满分。

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?

用途由“按关键词搜消息面记录”隐含表达，搜索约束也很清楚：最多 5 个词，所有词都必须包含。但描述没有说明何时应使用这个工具、而不是其他新闻相关工具，也没有提及排除条件。

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