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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the non-real-time nature of the data, which is valuable. However, it does not explain what 'annotate' means in practice, nor describe the return format, leaving some transparency gaps.

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 that efficiently communicates both the action ('read') and the critical caveat ('non-real-time'). No filler or redundant phrasing.

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 tool with no parameters, no output schema, and no annotations, the description covers the basic behavior and the non-real-time caveat. However, it does not explain what a 'radar summary' contains or what the output structure looks like, which leaves some context incomplete.

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 there is nothing for the description to clarify. Per the rubric, a baseline of 4 is appropriate for 0-parameter tools, and the description does not need to compensate for missing parameter documentation.

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

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

The description clearly states the verb 'read' and the resource 'historical topic research radar summaries', and adds the specific action of flagging non-real-time data. It is distinct enough from sibling tools, but it does not explicitly differentiate itself by naming alternatives, so it falls 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 words 'historical' and 'non-real-time' imply this tool is for historical data rather than real-time, but there is no explicit statement about when to use it or when not to. No alternative tools are mentioned, so guidance is only implied.

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

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

No annotations are provided, so the description carries the full burden of disclosure. It only says 'read', implying non-destructive behavior, but does not disclose return format, pagination, or restrictions beyond the allowed framework values. The behavioral transparency is minimal.

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 extremely concise: two short sentences, no filler. It is front-loaded with the core action and domain, and every word adds 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?

With no output schema, no annotations, and a 3-parameter input, the description is incomplete. It does not explain return values, behavior nuances, or the roles of 'query' and 'max_chars', making it insufficient for confident correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for the 'framework' parameter by listing valid values, but provides no explanation for 'query' or 'max_chars', leaving two of three parameters semantically unclear.

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

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

The description clearly states the tool reads approved research framework excerpts, and lists the specific valid framework values (enterprise/business/finance/people/brand). This provides a specific verb+resource, though it does not explicitly differentiate from sibling tools.

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

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

The description implies the tool should be used when needing to read approved research framework excerpts, but does not provide explicit when-to-use or when-not-to-use guidance, nor mention alternatives among sibling tools.

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: only hypotheses that passed the delivery evidence threshold are returned, and unverified ones are filtered out. This adds meaningful context beyond the schema, though it does not cover side effects, errors, or permissions.

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, front-loaded sentences with zero waste. The main action and the key exclusion are presented clearly and efficiently.

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 no output schema and no annotations, the description covers the core behavior and the main selection criteria. Minor gaps like return format or error handling exist, but for a simple read tool with one parameter, this is reasonably 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%, so the description must compensate for parameter meaning. It does not explain 'hypothesis_id' beyond what the schema already shows. The parameter name is self-explanatory, but the description adds no additional semantics, format, or usage details.

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

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

The description clearly states the tool reads frozen hypotheses that have passed a delivery evidence threshold, and explicitly excludes unverified ones. This specific verb+resource+scope distinguishes it from sibling tools that handle other data types.

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

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

The description implies when to use this tool by defining its selection criteria (frozen, passed threshold). It also provides an exclusion ('does not return unverified hypotheses'), which gives some guidance on when not to use it, though it does not explicitly name 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?

With no annotations, the description carries the full burden. It discloses that the data is '冻结的' (frozen/static) and that raw market data/panels are excluded, which sets expectations. It does not mention output format or other traits, but for a simple zero-parameter read-only tool, this is adequate and not misleading.

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 sentence with two parts: the purpose and the exclusion. It is front-loaded with the action and resource, and every word earns its place. No unnecessary elaboration.

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 (0 params, no output schema), the description adequately defines the data domain and its limitations. It tells the agent what to expect (a frozen IC summary) and what not to expect (raw quotes/panels). It does not describe the output structure, but that is less critical for such a straightforward read-only 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?

The tool has zero parameters and an empty schema, so there are no parameter semantics to convey. The description confirms it is a simple read operation with no input needed, which aligns with the 0-param baseline of 4.

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 and resource: '读取冻结的因子历史 IC 摘要' (reads frozen factor historical IC summary). It also explicitly excludes raw market data and panels, distinguishing it from data-retrieval tools. This fully satisfies the purpose clarity criteria.

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

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

The description provides a clear when-not: '不提供原始行情或面板' (does not provide raw quotes or panels), indicating it shouldn't be used for raw data. However, it does not name alternative tools or give explicit positive use-case guidance beyond the read action. Thus it has clear context with an exclusion but lacks explicit 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 must carry the full burden of behavioral disclosure. It does reveal that trading fields are removed and a research assistance boundary is added, which is a useful behavioral trait, but it omits effects on inputs/outputs, whether the operation is read-only or mutating, permission requirements, error handling, or any rate limits.

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

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

The description is a single short sentence, which is concise in length, but it sacrifices clarity and informativeness. It is under-specification rather than efficient communication; key operational details are missing, and the sentence does not front-load the most important user-facing 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?

Given no output schema, no annotations, 3 parameters with zero documentation, and a vague description, the tool is severely under-described. The agent cannot reliably determine the purpose, input semantics, return format, or safety profile from this description, making it inadequate for selection and invocation.

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

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

Schema description coverage is 0% (no parameter descriptions), so the description must compensate by explaining what symbol, question, and market mean or how they are used. The description does not mention any parameters at all, leaving the agent without semantic guidance beyond raw names and types.

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 says to 'call controlled research interface, delete trading fields and append research assistance boundary,' which implies a research analysis operation with sanitization, but it does not clearly state what the tool actually does for the user (e.g., analyze a symbol/question). It is closer to a tautology of the tool name 'research_analyze_safe' and provides no concrete outcome, making it hard to distinguish from sibling analysis tools like hypothesis_get or cognition_radar_read.

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, no mention of prerequisites, and no exclusions. The description only states 'call controlled research interface' without explaining the appropriate context or comparing to sibling tools such as stock_snapshot_latest or framework_excerpt.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses a key trait: the data is frozen, not real-time, and specifically the latest snapshot. This helps set expectations about data freshness, which is critical for a research tool. It does not mention return format or side effects, but for a read operation this is acceptable.

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 sentence that immediately states the primary function and a critical caveat. Every word earns its place, and the structure is optimally front-loaded. There is no wasted text or repetition.

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

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

For a simple, parameterless read tool, the description is sufficiently complete. It tells the agent what it does (reads latest frozen snapshot) and its key limitation (not real-time). With no output schema required, this is adequate for an agent to select and invoke 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?

The tool has zero parameters, and the schema confirms this with full coverage. Per the baseline for zero-parameter tools, the description need not add parameter details. The description adds no param-specific meaning, but this is not a deficiency given the absence of parameters.

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

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

The description clearly states the tool '读取最新冻结的股票研究快照' (reads the latest frozen stock research snapshot), specifying a concrete action (read) and resource (snapshot). It also distinguishes itself from real-time market tools by explicitly noting it does not represent real-time market status, which separates it from potential siblings.

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

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

The description provides clear context that this tool returns a frozen snapshot, not real-time data, implying it should be used when historical or non-real-time data is acceptable. However, it does not explicitly name alternative tools or state when not to use it, though the 'not real-time' caveat serves as an implied exclusion.

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