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

No annotations are supplied, so the description carries the full burden. It does add one genuinely useful behavioral trait — that uncovered coverage windows cause results to be labeled 'unverified' — but it omits that this is a multi-stage, likely long-running operation against external sources, and never mentions that save_files defaults to true and writes files to disk as a side effect.

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

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

The purpose is front-loaded in a single dense sentence, followed by only the parameter notes that are actually needed. It is compact with no filler, though the abrupt line breaks and the lack of any structural marker between purpose and parameters slightly hurt scanability.

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. But for a complex multi-stage tool with five parameters at 0% schema coverage and no annotations, leaving save_files and name undocumented and saying nothing about duration or side effects leaves real gaps an agent must guess at.

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 does well on three of five parameters, explaining that announcement_pages × page_size defines scan breadth and that window_days is the coverage window behind the 'unverified' marking. However, `name` and especially `save_files` (a side-effect-bearing boolean) get no explanation at all.

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 first line states a specific verb and resource: produce a complete background-check report on one company, and it enumerates the internal pipeline (probe → disambiguate → collect → red-line judgment → conclusion). This lets an agent see it is the end-to-end orchestrator while siblings like probe_sources, resolve_company and risk_sweep are individual stages, though it never says so 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: the pipeline sequence suggests this is the 'do everything' tool versus the single-step siblings, but there is no explicit when-to-use / when-to-prefer-a-sibling statement, and no mention of cost, runtime, or prerequisites that would make an agent choose otherwise.

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

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

No annotations are supplied, so the description carries the full burden. The verb 读取 makes clear that it is a read operation and the field list reveals the shape of the returned ledger. It says nothing about permissions, rate limits, pagination, or behavior when a report has no evidence, which is thin for a zero-annotation tool, though the low-risk read nature limits the damage.

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

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

Two short lines, both front-loaded and purposeful: line one enumerates contents, line two directs the verification workflow. No filler whatsoever.

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 describing the fields is somewhat redundant though useful as a preview. For a single-parameter, read-only tool, the definition is minimally adequate, but the unclear report_id semantics and the absence of any empty-result or error behavior leave gaps.

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

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

The only parameter, report_id, has no schema description (0% coverage), so the description must compensate. The phrase '报告的证据台账' only weakly implies that report_id selects the report, with no format, sourcing hint (e.g., from list_reports), or behavior for an unknown id.

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 (读取/read) and resource (报告的证据台账 / a report's evidence ledger), then enumerates the returned fields: source, URL, fetch time, sha256, raw payload path. This makes it clearly distinct in scope from get_report or list_reports, though it never names a 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?

Gives clear usage context and sequencing: 'during review, look here first' establishes this as the entry point of an evidence-verification workflow, and it tells the agent what to do with the data (re-check the URL at the source, compare the raw payload hash). It does not, however, state when to prefer get_report or probe_sources instead, nor any 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?

No annotations are supplied, so the description carries the full disclosure burden. It does disclose that the return is the complete report JSON including the evidence ledger index, which is useful behavioral context, but it says nothing about behavior when the ID is unknown, permissions/auth requirements, or payload size. A read-only, non-destructive nature is only implied by '读取'.

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

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

A single compact sentence with the lookup key front-loaded and no filler. It is efficient, though the brevity borders on under-specification for a tool with no annotations.

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

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

Having an output schema means return shape need not be described, and the single parameter is at least named in prose. However, with zero annotations and zero schema coverage, an agent is left without error behavior, ID provenance, or guidance relative to list_reports/get_evidence.

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 schema contributes nothing about report_id. The description compensates partially by explaining that the parameter is a report number/ID used to look up a full report, but it gives no format, origin, or example, so the agent still cannot validate the value it passes.

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 in one clause: read the complete report JSON by report ID, and it also notes the payload includes the evidence ledger index. It is clearly distinct in kind from sibling build_report or risk_sweep, but it never distinguishes itself from list_reports (how to obtain an ID) or get_evidence (partial retrieval), so the sibling routing is left implicit.

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

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

There is no statement of when to use this tool versus list_reports or get_evidence, and no note that a valid report_id must first come from list_reports or build_report. Usage is only implied by the phrase 'by report ID'. No exclusions or preconditions are given.

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

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

No annotations are provided, so the description carries the full burden. It does not state that this is a read-only operation, how results are ordered, whether the list is paginated, or what the limit does — all relevant for a listing tool with a limit parameter.

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 short sentence with no wasted words, and the scoping qualifier is front-loaded. It is efficient, though its brevity is part of why other dimensions are thin.

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 undocumented limit parameter and the absence of any usage or behavioral context leave the definition under-specified for a tool with a sibling that fetches a single report.

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 single parameter 'limit' has 0% schema description coverage and is not mentioned in the description at all. The agent gets no meaning for it beyond its name and default of 20, so the description fails to compensate for the schema gap.

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

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

The description states a specific verb (列出/list) and resource (背调报告/background-check reports) and scopes it to locally generated reports (本机已生成), which distinguishes it from get_report. It does not explicitly name a sibling, 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?

There is no guidance on when to use this versus get_report or build_report, and no mention of prerequisites or what happens when no reports exist. The agent must infer usage purely 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 must carry the full behavioral burden. It usefully discloses the tool's limitation (it does not perform verification, only generates a human checklist), but it does not state whether the operation is read-only, what side effects or state changes result, or what the caller should expect from the 'name' input.

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, front-loaded with the purpose followed by the constraint. There is no padding, though the second sentence could more tightly connect to the parameter or output.

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?

Because an output schema exists, return values need not be described, and the purpose plus human-verification caveat give a workable picture. However, for a tool whose only input is entirely undocumented, the definition leaves the caller guessing about the meaning of 'name', so it is only minimally 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?

The single parameter 'name' has 0% schema description coverage, and the description does not explain what it represents (company name, report name, or dimension). The description therefore fails to compensate for the schema gap on the only input.

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 action (生成人工必查清单) and enumerates the contents of the checklist (official channel entry points, search terms, record-keeping requirements), so an agent can tell this produces a checklist rather than records findings or evidence like its siblings. It does not explicitly name or differentiate itself from tools such as manual_record or manual_findings, which keeps it shy 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?

It gives a clear usage context: dimensions that are blocked by WAF/captcha must be reviewed by a human because the tool does not substitute for human verification in the official system. This establishes when the tool is appropriate, though it offers no explicit routing to or from the alternatives like probe_sources or manual_record.

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

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

No annotations are supplied, so the description carries the full disclosure burden. '读取' implies a safe read, and '已回填' hints that only completed entries are returned, but nothing states permissions, behavior for reports with no manual findings, or error conditions. The existence of an output schema covers return shape, which keeps this from being a 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?

A single short sentence with the verb front-loaded and no filler. It is efficient, though its brevity borders on under-specification rather than being a model of tight structure.

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

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

The tool is simple (one required param, output schema present), so little is needed, but the description omits the one thing an agent cannot get from structured fields: how this read differs from get_evidence and manual_record. That omission makes the definition incomplete for selection purposes.

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

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

Schema description coverage is 0% for the single report_id parameter, so the description must compensate. '某份报告' does establish that report_id selects the target report whose findings are returned, which is meaningful but minimal — no format, no example, no statement of what happens with an invalid id.

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 verb (读取) and a resource (人工核查证据) scoped to a report, so the basic operation is inferable. But it never distinguishes itself from siblings like get_evidence, manual_checklist, or manual_record, which sound closely related, leaving the agent to guess which one surfaces filled-in manual findings.

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

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

There is no when-to-use guidance, no prerequisite (e.g. the report must already have manual checks recorded), and no named alternative. With three manual_*/get_evidence siblings present, the absence of routing guidance is a real gap.

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

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

With no annotations at all, the description carries the full burden and does well: it discloses that this is a mutating write-back that changes rule state, that it is the sole permitted path for that mutation, and that evidence (official URL or screenshot/PDF path) plus a reviewer and method are mandatory. It does not address reversibility, overwrite behavior on repeated records, or permissions, which keeps it short of a 5.

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

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

Three short sentences, front-loaded with the action and followed by the value constraint and the exclusivity rule. No filler and no restatement of the tool name.

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 an eight-parameter mutation tool with zero annotation coverage, the description supplies the essential guardrails: allowed outcome values, mandatory evidence, and the exclusivity of this write path. An output schema exists so return values need not be explained, but idempotency and what happens to a previously recorded result are unstated.

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

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

Schema description coverage is 0% and no parameter has an enum in the schema, so the description's statement that outcome must be exactly 'clear' or 'hit' supplies constraint information available nowhere else. It also clarifies that operator, method, and a url-or-attachment pair are jointly required, covering five of eight parameters; note, rule_id, and report_id are left to inference.

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 concrete verb and resource: persist a manual review result as an audit trail and write it back into the report. It also distinguishes this path from the forbidden one ('cannot directly edit the report JSON'), which helps separate it from siblings like manual_findings or build_report, 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 declares a strong usage constraint — this is the only entry point through which a manual result may change rule status — which implies when the tool is required. However, it never names an alternative tool or states a when-not condition relative to the sibling list, so the routing 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?

With no annotations supplied, the description carries the full burden and does disclose the key trait: it actually fires real requests rather than returning cached capability data. It also enumerates the possible outcomes (ok / blocked / needs_key / error) with real HTTP codes, which tells the agent to expect partial failure and to branch on 'needs_key'. It omits cost/latency, rate limits, and whether repeated calls are safe.

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

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

Three short sentences, front-loaded with what it does, then the return shape, then the usage directive. The status enumeration partially duplicates the output schema, but it is short enough that the overlap costs little.

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

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

An output schema exists and the description correctly avoids re-explaining return values in depth while still naming the status taxonomy. For a zero-parameter preflight tool with no annotations, the remaining gaps (latency, whether probing is expensive, idempotence) are minor but would help an agent decide how often to call it.

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

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

The tool takes zero parameters, so there is no parameter semantics to add; baseline 4 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 and resource — probe all data sources for real-time availability — and scopes it to the entire source set rather than one source. The added line '先跑这个' positions it in the workflow relative to the manual_* siblings, so an agent can tell it is a preflight check rather than a query.

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?

Explicit ordering guidance ('run this first') plus the decision it enables — what can be queried now versus what must be escalated to manual — gives clear when-to-use context and implicitly points at the manual_* siblings. It does not state when this tool should be skipped (e.g. a fresh probe already done), so it stops short of full when/when-not coverage.

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

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

With no annotations supplied, the description carries the full burden and does reasonably well: it discloses the return shape (candidate list plus per-candidate anchors) and warns about the downstream failure mode of ambiguous names. It stops short of stating that this is a non-mutating lookup, or noting any rate/caching behavior, which keeps it from a 5.

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

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

Two short sentences, front-loaded with what the tool does and what it returns, followed by the operational caveat. Every sentence earns its place; there is no filler or restatement of the tool name.

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?

This is a low-complexity single-parameter resolver with an output schema, so return-value detail is already covered structurally. The description adds the disambiguation intent and the verification caveat that an agent would otherwise miss; only input-format expectations remain underspecified.

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

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

Schema description coverage is 0% for the single 'name' parameter, so the description must compensate; it clarifies that the input is a possibly ambiguous company name rather than a canonical identifier. It adds that framing but gives no guidance on accepted formats (full legal name vs. short name vs. ticker) or how to read the returned anchors, leaving a meaningful gap.

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

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

The description gives a specific verb and resource — disambiguating a company name into a definite investigation subject — and names the identifier kinds produced (listed code / CIK / QID). It does not explicitly contrast with any sibling, but the sibling set (manual_findings, probe_sources, build_report, risk_sweep, etc.) has no resolver-like overlap, so the distinction is clear in practice.

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 supplies a concrete precondition and sequencing rule: same-name subjects must be verified via the unified social credit code before collection begins, otherwise red-line determinations will be misattributed. What is missing is any statement of when this tool should be skipped or what to do if disambiguation fails, but the usage context is otherwise unambiguous.

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

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

With no annotations supplied, the description carries the full burden and does disclose the mechanism (pulls recent titles, matches keyword rules) and what is returned per item. However it omits auth/permission expectations, scope limits, and how 'recent' is bounded, which a no-annotation read operation should ideally cover.

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: the scope constraint leads, then the use case, then the return fields. No wasted wording, though the line-broken fragments read slightly choppy.

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 the return-field sentence is somewhat redundant, and the description is reasonably complete on purpose. But with zero param documentation and no annotations, the gaps around 'name'/'pages' semantics and permission behavior leave an agent under-informed relative to a 2-param scanning 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 0%, so the description must compensate, yet it never explains what 'name' means (presumably the company/target) or what 'pages' controls. The phrase about fetching recent titles vaguely implies paging but adds no concrete meaning for either parameter.

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: it scans recent announcement titles for red-line keyword hits and says '只做风险信号扫描' (only does risk signal scanning), which distinguishes it from heavier report-building siblings like build_report. It stops short of naming a specific alternative sibling, so it misses the top bar.

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 implied when-to-use guidance: fast initial screening. There is no statement of when NOT to use it, no explicit alternatives, and no prerequisites, leaving usage largely inferred.

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