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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool checks local state, including current tasks, and does not touch the network, which is the most important behavioral trait: no calls, no authentication, and no side effects. It leaves implicit that the operation is read-only and does not reveal whether any local state is modified.

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 definition consists of a single compact clause with semicolon-separated scopes, and the offline constraint is stated last where it is prominent. No sentence 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?

An output schema exists, so return-value shape does not need explanation here. For a no-argument local diagnostic tool, the scope list and the offline guarantee are enough to call the tool correctly. The only real omission is routing guidance against similarly named siblings.

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 are no parameter semantics to document. A baseline of 4 is appropriate because nothing is left ambiguous on the input side.

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 concrete resource set: configuration, data volume, browser dependencies, rate limits, and current tasks. This is more specific than a tautology. It does not explicitly contrast itself with related siblings such as session_status or operation_status, so differentiation 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?

The description implies usage in troubleshooting and pre-flight situations through the list of things it checks and the note that it does not go online. It never states when an agent should choose this over operation_status or session_status, and it gives 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?

With no annotations supplied, the description carries the full burden and does substantial work: it discloses the resolution chain (institutional subscription browser session → Unpaywall OA copy → publisher page), the PDF→CAJ fallback rule, the policy that paywalled content is not bypassed, and that unknown outcomes are not automatically replayed without retry=true. It stops short of saying what authentication is needed for the institutional-session path or what a failed download returns, but the behavioral profile is far above baseline.

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?

Four short lines, front-loaded with the purpose and the primary usage gate, then falling back to behavioral detail. Almost every clause earns its place; the '(知网常见)' parenthetical is the only mildly expendable fragment.

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 complex resolution logic is well covered. However, for a tool with 8 optional parameters and zero annotation coverage, the description never says which identifier combinations are valid, where the file is written (subdirectory is undocumented), or what wait_seconds controls, leaving an agent to guess at invocation details.

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 0% across 8 parameters, so the description must compensate, and it meaningfully explains only format ('auto 优先 PDF，站点只提供 CAJ 时回落 CAJ') and retry semantics, plus an oblique hint that site relates to 知网. The remaining parameters — doi, title, record_ref, subdirectory, wait_seconds — get no explanation of meaning, mutual exclusivity, or which one identifies the paper, leaving real gaps for an 8-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 opens with a specific verb+resource: '下载全文（PDF/CAJ）' (download full text as PDF/CAJ), which is immediately distinguishable from metadata-oriented siblings such as get_metadata, search, and export_citations. It lacks an explicit naming of those siblings, but the resource and output form are unambiguous.

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?

'仅在用户确实需要文件时调用' is a genuine when-to-use constraint that steers the agent away from this expensive tool when a metadata lookup would do. It also states the condition for retrying (explicit retry=true), though it never names a concrete alternative tool for the case where only metadata is needed.

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 reveals the format capability set but says nothing about whether a file is written to disk, what happens with the default 'selected' scope, permission or login requirements, or any limits on export size — significant gaps for an 8-parameter tool with side effects implied by 'filename' and 'template'.

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?

It is a single front-loaded sentence with the verb and resource first, and the format list, though long, is the only substantive information conveyed. No filler or redundancy is present, though the list would be more useful if attached to the format parameter explicitly.

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 eight optional parameters, zero schema coverage, and no annotations, the description leaves most of the call contract unexplained; an output schema exists so return values need not be described, but scope selection, file output behavior, and reference-selection parameters remain opaque. This is far short of what an agent needs to invoke the tool 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 description coverage is 0%, and the description only indirectly touches one of eight parameters (format) by listing format names without tying them to the parameter or giving valid string values. scope, limit, titles, filename, template, search_id, and record_refs are entirely undocumented in both schema and description.

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 (导出参考文献 / export citations) and enumerates the supported output formats, so an agent knows exactly what capability this is. It does not differentiate itself from siblings such as search_results or get_metadata, which also deal with reference data.

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 choose this tool over siblings, no mention of prerequisites (e.g. that references must be selected or a search_id supplied first), and no explanation of the 'selected' vs other scope values. The agent must guess the workflow context entirely.

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 it does disclose real behavioral traits: local_only bypasses the network, refresh ignores a 30-day cache, and quality may fail to return JCR metrics because the WoS Starter API lacks them. It omits mutation/auth profile (implied read-only), pagination via limit/offset, and missing-record 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?

Three short, front-loaded lines: first the core action and selectors, then the flag semantics. Each sentence earns its place, and the unusual quality/cache caveats are stated compactly rather than buried.

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 spelled out, and the caching/quality caveats are covered. But for an 11-parameter, zero-required tool with no annotations, leaving scope/fields/limit/offset/site unexplained and offering no routing against siblings leaves the definition only minimally sufficient.

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 0% and there are 11 parameters, so the description must compensate: it explains record_refs/titles/search_id, local_only, refresh, and quality well beyond the field names. However, site, limit, offset, fields, and especially scope (default "selected") are left completely undefined in both schema and description, which is a substantial residual 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?

"批量收集题录" gives a concrete verb (batch-collect records) plus the resource, and it enumerates the three lookup keys: record_ref, full title, or search_id, along with what is returned (abstract/keywords/DOI). That clearly separates it from discovery tools like search/structured_search, 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?

Listing record_ref/title/search_id as input modes implies you should use this once you already know what you want, rather than to discover papers. But there is no explicit when-to-use vs. search_results or export_citations, no statement about what happens when no selector is supplied (all 11 params are optional), and no prerequisites such as login.

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 reveal the payload shape (sites plus a capability matrix), but says nothing about whether the call requires authentication, whether results are cached or live, or how large the response can be.

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 sentence with the resource stated first and the purpose trailing it. Every clause earns its place and nothing is padded.

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 (no parameters) and an output schema already documents the return values, so the description only needs to convey what is listed and why. That is covered; only auth/prerequisite behavior is left 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the empty schema. Baseline 4 applies; no parameter gaps exist.

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 — listing registered sites together with their capability matrix — and adds the intent behind it (finding which sites are searchable/downloadable). That is clearly distinct from siblings like search or structured_search, though it does not explicitly name them.

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 clause '用于发现哪些站点已可检索/下载' implies the usage context: check availability before searching or downloading. It stops short of explicit when-not guidance or naming the alternative tools (search, structured_search, download_paper) an agent should call next.

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; it discloses the key traits: the action is interactive and requires the user to act in a separate browser window, and force=true destroys a saved session before re-authenticating. It does not cover blocking or timeout behavior, or what happens if the user abandons the window.

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 compact sentences, each carrying a distinct fact: what happens, the site requirement and default, and the force side effect. Nothing is repeated and the core behavior is front-loaded.

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

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

Two parameters are both accounted for, and an output schema exists to cover return values, so the remaining need is low. Minor gaps are the lack of a pointer to list_sites for accepted site strings and no note on whether the call blocks until the user finishes.

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 both parameters must be explained in prose, and they are: site controls which provider's login page opens, with an explicit example value and a stated default, and force controls whether the saved session is cleared. This adds real meaning beyond an untyped string and boolean in 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: it opens a separate browser window so the user can complete institutional or personal login. That is far more informative than the name alone. It stops short of a 5 because it never names a sibling tool, such as session_status or list_sites, to contrast itself with.

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 clearly states when an explicit site value is mandatory (Wanfang/CQVIP) and what the default is otherwise (WoS login page), plus when to use force to clear a saved session. It does not say when to call login rather than check session_status first, and it gives no pointer to list_sites for valid site values.

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, and it omits nearly all of it: whether cancel is irreversible, what state the operation lands in afterwards, whether recover destroys the existing browser session, or what permissions are needed. Only one behavioral detail surfaces — that continue can extend budget — which is far short of what a state-mutating control tool 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?

A single semicolon-delimited line with action name first and meaning second, which scans well for an agent matching an action to an effect. No filler; the only cost is that the compact list format leaves no room for the conditions and constraints noted above.

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 four-parameter, multi-mode control tool with no annotations, the description should map parameters to actions and state the effect of each mode. It does neither for the three optional parameters, and an output schema existing only relieves it of explaining return values, not of explaining control semantics.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate and largely does not. It documents the effective values of `action` (a genuine gain, since the schema declares no enum), but operation_id, additional_seconds and additional_requests are only obliquely gestured at by '可追加预算' — there is no statement of which actions require an operation_id or how the two budget parameters interact.

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 enumerates five concrete action verbs (cancel, continue, resume, show, recover) and what each does to an in-flight operation/browser session, so the resource and effects are identifiable. It does not explicitly differentiate itself from the sibling operation_status, leaving the control-vs-inspect boundary 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?

Per-action conditions are given for two actions ('continue' is for interrupted or budget-exhausted searches; 'resume' is for when a manual step is done), which is real routing guidance. However cancel/show/recover have no stated preconditions, and the description never says when to call this instead of operation_status or what to do if the operation is unknown.

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

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

With no annotations, the description carries the full burden and does disclose the key non-obvious behavior: this is a long-poll of up to 55 seconds that returns early on completion or when the task enters awaiting_user. The default-when-omitted behavior for operation_id is also stated. What is missing is error behavior for an invalid/expired operation_id and whether calls are concurrency-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 lines, front-loaded with the purpose, then the timing constraint, then the parameter fallback. Every sentence conveys information an agent needs and nothing is repeated from the schema.

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

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

An output schema exists, so return-value documentation is not needed, and for a two-parameter read tool the description covers purpose, timing, and default targeting well. It falls short only on task-state vocabulary beyond awaiting_user and on failure modes, which matter for a polling tool with no annotations.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it explains the 55-second ceiling on wait_seconds and the omit-to-get-active-task semantics of operation_id. It does not mention that wait_seconds defaults to 0 (i.e., non-blocking) or that operation_id is a string identifier, leaving some ambiguity about default polling behavior.

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?

"查询任务进度与结果" gives a specific verb (query) plus the resource and the two things it returns (progress, results). It is clearly distinguishable from operation_control (control) and session_status (session-scoped) by name, but the description never explicitly disambiguates itself from those 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?

Usage context is implied rather than stated: the agent learns it should call this to poll progress, and that omitting operation_id targets the current active task, which is a useful selection rule. However, it never says when to use operation_control or session_status instead, nor what happens if the operation has already finished or never existed.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only discloses the default source (Web of Science). It says nothing about authentication requirements, rate limits, whether results are paginated or truncated at 'limit', or what makes 'mode' (default 'balanced') change behavior. For a 10-parameter search tool with zero annotation coverage, this is a significant 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?

It is a single, tightly written sentence with no padding, and the core action is front-loaded. Its brevity is a virtue in form but the space saved is not reallocated to the missing parameter and usage detail, which is penalized in other dimensions.

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 for a 10-parameter search tool with no annotations and no schema descriptions, the definition leaves the agent without guidance on mode, filtering, sorting, or how this differs from 'structured_search'. It is far too thin for the tool's complexity.

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%: the schema gives bare titles and defaults (mode, site, sort, limit, year_from, year_to, concept_groups, document_types, options) with no meaning. The description only hints that 'query' is a research question and that 'site' defaults to Web of Science; the other eight parameters receive no semantic explanation in either the schema or the description.

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 identifies a specific verb and resource ('按研究问题检索学术文献') and names a default source (Web of Science), so the agent knows this is a literature search. However, it does not distinguish the tool from the sibling 'structured_search' or 'search_results', so an agent cannot tell which search entry point is appropriate without opening both schemas.

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 '按研究问题' implies that this tool is meant for research-question-level queries rather than fielded or structured queries, providing only the faintest usage context. The description names no alternatives, gives no when-to-use or when-not-to-use guidance, and says nothing about prerequisites such as login or site selection, even though a 'login' and 'list_sites' sibling exist.

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 behavioral burden, and it does disclose two important traits: the operation is local-only (no network) and results are paginated. It omits what happens on an invalid or expired `search_id`, whether ordering across pages is stable, and any size/cost implications of the `records` view, which are meaningful for a paginated fetch.

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 text is short and front-loaded, with the core capability stated first and the two enumerated parameters set out as scannable lines. Every line does work; the only cost is that the extreme terseness leaves gaps that a slightly longer phrasing could close.

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 shapes need not be described, and the description covers the local/no-network model plus the two enumerated parameters. For a 5-parameter paginated read with zero annotation coverage it should still say something about `search_id` lifecycle and pagination interaction (limit/offset), which are the main ways an agent could misuse this 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% across 5 parameters, so the description must compensate and it only partially does. It glosses `scope` values (selected/eligible/candidates) and lists `view` values (titles/compact/records) but never says what each view actually returns in terms of payload weight, and gives no meaning at all for `search_id`, `limit`, or `offset` beyond their self-evident names.

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 combination ('本地分页读取检索快照' - locally paginated read of a search snapshot) plus an operational constraint ('不联网' - no network). This clearly differentiates it from the sibling `search`/`structured_search` tools that presumably hit the network. It does not name those siblings explicitly, keeping it below 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 '不联网' (no network) clause and the required `search_id` imply this is the follow-up step to a prior search that materialized a snapshot, and the scope glosses hint at narrowing. However, there is no explicit statement of when to use this rather than re-running `search`, nor any exclusions or preconditions (e.g. snapshot expiry).

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 whole burden, and it does disclose the one behavior that matters most: refresh=true performs a live browser-session probe rather than a passive check. It says nothing about the cost/latency of that probe, permission requirements, or what the non-refresh path actually consults (cache vs. cookie jar), leaving the mutation-adjacent side effects underspecified.

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 semicolon-joined sentence with zero filler, and the primary purpose is front-loaded ahead of the refresh modifier. Nothing redundant is present.

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

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

For a two-parameter status tool whose output schema already defines the return shape, this is nearly sufficient: purpose plus the refresh behavior covers the core decision. The only real hole is the unexplained 'site' parameter, which matters because the tool is site-scoped.

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 two undocumented properties. It explains 'refresh' well but leaves 'site' completely unaddressed — an agent cannot tell whether it takes a domain, a site key, or whether null means 'the default/active site'.

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 ('查看') plus a specific resource ('站点登录/会话状态'), so an agent knows immediately this reports authentication state rather than mutating anything. It does not name the nearest siblings (login, list_sites, diagnostics), so the differentiation from them must be inferred from the name.

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 one useful conditional: set refresh=true to re-probe via the browser session. That implies the default path is a cheaper/cached read, but there is no explicit when-not guidance and no pointer to the login tool for the case where the status comes back unauthenticated.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior for the expression itself: allowed operators, the default of `match: phrase` versus `exact`, and the exact field vocabulary. It says nothing about what happens on malformed expressions, how `site` scopes results, auth/rate limits, or pagination behavior, which leaves substantial behavioral ground uncovered.

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 compact sentences with the grammar front-loaded and the valid field list following it; every element is load-bearing. The structure is terse but readable, with no filler.

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 a nested, free-form object as the required argument, the description gives the minimum an agent needs to build a valid expression. It stops short of covering the six sibling parameters and the year_from/year_to versus `year` overlap, which is a real ambiguity for a 7-parameter tool, though the existing output schema reduces the need to describe results.

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

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

Schema description coverage is 0% across 7 parameters, so six of them (site, sort, limit, options, year_from, year_to) are documented nowhere. The description compensates strongly for the required `expression` parameter by spelling out its nested shape and field names, but it never clarifies how year_from/year_to relate to the `year` field inside the expression or what `options` accepts, so the gap is only partly filled.

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 mechanism: boolean-expression retrieval where a leaf is {field,value,match} and a node is {op:and|or|not,items}, and it enumerates the queryable fields. An agent can tell this is the precise/structured query tool, but nothing in the text distinguishes it from the sibling `search` tool, 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 explicit statement about when to use this tool instead of `search` or `search_results`, and no exclusions or preconditions. Precise boolean semantics are implied by the grammar, but the choice between this and a plain keyword search is left entirely to inference.

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