ReportGem Global Research

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

The annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, which is surprising for a 'get' tool; the description does not explain this. It does add real behavioral context beyond the annotations: results are bounded excerpts, sequential reads are resumable via cursor, and a no-match must not be treated as verified evidence.

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 clauses with no filler, and the core behavior (bounded excerpts / continuable window) is front-loaded before the caveat. Efficient, though extremely terse for a 7-parameter tool.

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 parameter coverage is high, so the description need not restate return values or parameter formats. What remains, mainly when to prefer each reading mode and the relationship to the search siblings, is only partially addressed, leaving a small 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?

Schema description coverage is 86%, so the schema already documents query, cursor, source_id, source_type, and reading_mode semantics. The description adds essentially no parameter-level detail beyond the schema baseline, so 3 is the correct ceiling 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?

The description states a specific operation on a resource: returning bounded source excerpts or a continuable sequential reading window. This distinguishes it implicitly from the search_* siblings (retrieval of evidence vs. discovery), though it never names those siblings explicitly, keeping it just 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?

Modes are implied (bounded excerpt search vs. continuable sequential reading), but there is no explicit statement of when to call this instead of search_filings/search_meetings/etc., nor prerequisites such as 'requires a source_id returned by a search tool'. Usage is inferable only from the schema.

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 are present, so the bar is lower, and the description does add one behavioral fact beyond them: results come with verifiable internal source links. However it says nothing about ordering, pagination, partial-query behavior, or coverage limits, and it does not clarify the oddly permissive annotation profile (readOnlyHint=false, openWorldHint=false) for what is clearly a search/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?

A single front-loaded sentence with no filler, naming the sources and the return benefit immediately. It is arguably too terse for a six-parameter, dual-market search, but nothing in it 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 six-parameter tool with date filters, a market enum, a form-type filter, and only 33% schema coverage, one sentence is inadequate. An output schema exists so return values needn't be described, but the missing usage guidance and parameter semantics leave real gaps for correct invocation.

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

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

Schema description coverage is only 33% – only query and form_type carry schema descriptions, while limit, market, and both date bounds are undocumented. The description mentions US and Chinese sources, hinting at the market enum, but gives no semantics for date_from/date_to, limit caps, or form_type filtering, 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 (检索/search) plus two concrete resources (US SEC filings and Chinese company announcements) and the return type (verifiable internal source links). This separates it from search_meetings and search_visuals, but it never distinguishes itself from the closest sibling, search_research.

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 search_research, get_evidence, or the other siblings, and no stated conditions or exclusions. Usage must be inferred entirely from the domain nouns.

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?

The description adds no behavioral context beyond the operation itself: no note on read-only vs mutating nature, no rate limits, no result-set behavior or pagination, no auth requirements. The annotations are also weak/misleading here (readOnlyHint=false and openWorldHint=false for what is plainly a search tool), so the description had the burden and did not carry it.

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 that states scope, resource and result distinction with no filler. It is efficiently sized, though the closing clause about 正文证据与清单命中 is opaque enough that it reads as jargon rather than useful 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 not be explained, but the description leaves too much unsaid for a 6-parameter search tool: no usage routing, no date-range semantics, no limit semantics, and no explanation of the two enums. Given the low schema coverage, the description should have carried more of this load.

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 17% – only 'query' is documented in the schema. The description partially compensates by implying the region dimension ('全球和中国'), which maps to the region enum, but limit, date_from, date_to and output_language receive no explanation anywhere. That is a clear gap for a 6-parameter tool.

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 verb (检索) with a specific resource (会议纪要、业绩会记录), which is enough to separate it from search_filings, search_research and search_visuals by resource type. It also states a scope (全球和中国) and an output property (区分正文证据与清单命中). It stops short of naming a sibling or explaining how it differs from get_evidence.

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 named. The only routing signal is implicit: the tool covers global and China meeting minutes, so an agent must infer it is the right choice for meeting/earnings-call content rather than filings or research.

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?

The description frames the tool as a pure read operation (search and return metadata/excerpts), yet the annotations declare readOnlyHint=false, which asserts the call is not read-only. This is an outright contradiction between the prose and the structured hints, which per the rubric caps this dimension at 1 despite the useful note about bounded metadata and body-text excerpts.

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 compact two-clause sentence that front-loads the verb and resource before the return-behavior detail. No filler, though the return-behavior clause 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?

With an output schema present, return values need not be explained, and the schema documents most parameters, so the core calling contract is covered. However, the missing usage guidance and the unresolved readOnly contradiction leave meaningful gaps for a 5-parameter, multi-source search 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 80% (query, date_from, date_to, sources all documented; only 'limit' bare), so the schema already carries the parameter burden and baseline 3 applies. The description adds no parameter-level meaning, syntax or defaults 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 specific verb+resource ('检索研报和论文' – search research reports and papers), which is enough to distinguish it from content-type siblings like search_filings, search_meetings and search_visuals without opening their schemas. It does not explicitly name those siblings, 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 implies the tool is for research reports and papers but gives no explicit when-to-use vs when-not guidance and never names an alternative tool or the condition that would select get_evidence or search_filings instead. Usage is left entirely to inference 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?

The description presents a plain search operation, which is inherently read-only, while annotations declare readOnlyHint=false and idempotentHint=false. This is an outright inconsistency between the stated behavior and the structured metadata, and the description adds no compensating behavioral context such as provenance format or filtering 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 dense sentence with no filler, and the core purpose is front-loaded. It is efficient, though the trailing 'with report/page provenance' phrase is somewhat compressed and could be clearer.

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 one-sentence purpose is adequate for identification. However, for a five-parameter tool with 20% schema coverage and no usage guidance, the description leaves the filter and date-range behavior 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?

Schema description coverage is only 20% – just the query parameter is documented. The description does not explain visual_type, date_from/date_to, or limit, so it fails to compensate for the four undocumented parameters, leaving the agent to guess at filter 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 verb ('Search') and a concrete resource set (charts, tables, industry diagrams, images), so the agent knows what is being retrieved. It does not explicitly differentiate itself from siblings like search_research, and the phrase 'research-relevant images' slightly blurs that 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?

The description says what is searched but gives no guidance on when to choose this tool over search_research, search_filings, or search_meetings, and names no exclusions or prerequisites. The agent must infer usage from the resource nouns alone.

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