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

With no annotations, the description carries the full burden and does well: it discloses that the browser is non-headless (human interaction required), that the call blocks until login succeeds or the timeout elapses, that state is saved even on timeout, and that state is keyed by domain and isolated per session. It omits where the credentials land on disk and whether an existing valid login is overwritten.

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?

Front-loaded with the one-line action summary, then the operational context, then per-argument notes. Slightly repetitive between the opening line and the second paragraph, but every clause carries information an agent needs.

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 no explanation, and the description covers the rest of what matters for a side-effecting, human-in-the-loop tool: interaction model, timeout behavior, and state keying. Nothing essential to invoking it correctly is missing.

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%, so the description must compensate, and it does: url is 'any page of the target site, keyed by domain', timeout is seconds waited with state still saved on expiry, and session is a namespace for parallel identities that web_fetch must match. That is real semantics — particularly the domain keying and the session must-match rule — not present 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?

States a specific action chain — open a headed browser, let the user log in manually, persist the resulting cookies to disk — and anchors it to a concrete sibling trigger (web_fetch returning login_required=true). An agent can distinguish this from session_list/session_export without reading any schema.

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 an explicit activation condition: use it for sites where web_fetch reports login_required=true. It also explains the multi-account case via distinct session names. It stops short of saying when NOT to use it (e.g. checking existing state with session_list first, or that it is unnecessary when a session is already valid).

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 burden — and it does disclose the key side effect: if path is given the JSON is written to a local file and the directory must already exist, otherwise cookies come back inline. It omits anything about overwriting an existing file, permission/auth requirements, or the sensitivity of the exported cookies.

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?

Purpose is front-loaded in one sentence and the Args block is terse and useful; every line earns its place. Minor redundancy in restating the default value and the two-line wrap on path.

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 needn't be spelled out, and the description's conditional (file vs inline) behavior covers the meaningful return branch. For a tool that writes a credential-bearing file with no annotations, an explicit note on overwrite behavior and the sensitivity of the exported cookies would close the remaining 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 coverage is 0%, but the description documents all three params with real meaning beyond the schema: url is any page URL of the target site and domain-matching is how the session is resolved, session names the session with a stated default, and path is optional with a directory-must-exist precondition and a defined alternative behavior when omitted.

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 (导出/export) and resource (cookies from a site's login session), with the scope rule '按域名匹配登录态'. It implicitly distinguishes itself from session_import by framing the output as something to back up or import elsewhere, but it never names the sibling or states the boundary explicitly.

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

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

The opening sentence gives clear use contexts: backup, or moving a session to another machine. It does not state any exclusions or explicitly point to session_import / session_list as the alternative path, so the when-not guidance is absent.

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 largely meets it: it discloses that no network request is made, and critically explains the destructive semantics of replace=True (wholesale replacement of the session's cookies) versus the default merge by (name, domain, path) where imported values win on conflict. Missing only edge behaviors such as error handling for malformed files or limits on file size.

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?

Front-loaded with the core action and its key constraint, followed by supported file formats and then per-argument notes. Every section is useful, though the Args block restates types already present in the schema and could be tightened slightly.

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 4-parameter tool with zero schema documentation and no annotations, the description covers file formats, container path handling, session naming, and merge-versus-replace semantics. An output schema exists, so unexplained return values are not a 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 0%, so the description must supply all parameter meaning, and it does: url is domain-matched to a page, path includes a practical docker cp note for container deployments, session is named and tied to web_fetch consistency, and replace documents both its default and its exact merge semantics. This is substantially more than the schema conveys.

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 opening sentence names a specific verb (导入/import) and resource (cookie → 站点登录态) and immediately bounds the scope with '仅本地文件，不发起网络请求'. This clearly separates it from sibling tools like login (interactive auth) and session_export (the inverse direction).

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 definition establishes context well: it is the counterpart to session_export, it must share the session name used by web_fetch, and it explicitly takes a local file rather than performing network auth. It stops short of an explicit 'use login instead when...' routing statement, so a 4 rather than a 5.

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

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

With no annotations, the description carries the full burden. It usefully discloses that only locally saved sessions are returned and that cookie contents are excluded, which signals a safe metadata-only read. However, it does not cover permissions, what happens with no saved sessions, or any behavior beyond the data scope.

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 the resource and returned fields in a parenthetical, plus one scoping exclusion. No wasted text for a simple 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, so return values need not be explained further, and the tool has no parameters to document. The description is complete enough for correct invocation; only the absence of explicit sibling routing keeps it from a 5.

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 the baseline is 4. The description adds the useful note that the output is limited to metadata, but there are no parameters whose semantics need explaining.

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 (列出/list) and resource (本地已保存的登录态), and enumerates the returned fields (session name, host, update time). The explicit '不含 cookie 内容' implicitly separates it from session_export, though neither sibling is named directly.

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

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

Usage is implied by the zero-parameter read-only nature of listing sessions, but there is no explicit 'use this when...' or exclusion guidance pointing agents to session_export/import for cookie data. The agent must infer when to prefer this over the export/import siblings.

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 substantial work: it discloses concurrency, that deadline exhaustion returns per-subtask timeout with diagnostics 'deadline:exceeded' without consuming network/browser resources, that custom headers/cookies/proxy disable shared cache, and that progress is only reported when the client requests it. These are real behavioral traits beyond the schema. It omits rate-limit/concurrency-cap behavior and partial-failure semantics for the batch as a whole.

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?

Front-loaded summary sentence followed by a per-argument list, so the reader gets purpose before detail. The argument block is long but each entry is one line and earns its place by documenting otherwise-undocumented params. Minor verbosity in the ctx entry, which is framework-injected and of little use to an agent.

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 detail is rightly omitted, and the description still states 'returns per-URL results'. For a 12-param concurrent tool with no annotations, the description covers scoping, deadline behavior, cache effects, and session/proxy propagation adequately. It could say more about failure isolation across the batch and concurrency limits.

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 12 params, so the description must compensate and largely does: every parameter is explained, including non-obvious semantics like deadline_ms being a batch-wide budget, session applying to all URLs, and the cache side-effects of headers/cookies/proxy. The 'same as web_fetch' references for link_policy and format defer meaning to another tool's docs rather than stating it here, which is the main 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 opening line gives a specific verb+resource: concurrent fetch of a batch of URLs, each through the full tiered pipeline, returning per-URL results. It's clearly distinct from web_fetch (batch vs single) though it never explicitly names the boundary. Sibling differentiation is implied via 'link_policy/format 同 web_fetch' rather than stated.

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

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

Usage is implied by 'batch' vs the singular web_fetch sibling, but there is no explicit 'use this when you have multiple URLs, use web_fetch for one'. No when-not guidance, no prerequisites. The cache-implication notes (headers/cookies/proxy disable shared cache) provide operational context but not selection guidance.

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 so well: every page goes through the full compliance chain (robots/allow-block list/rate limiting/same-host concurrency), a single page failure does not abort the crawl, static asset links are skipped automatically. It also discloses non-obvious side effects: explicit headers/cookies/proxy bypass the shared cache, and when deadline_ms is exhausted already-fetched pages are still returned while queued subtasks return timeout.

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 and mode split are front-loaded, then a structured Args list follows — the bulk is necessary given zero schema descriptions. The trailing ctx entry is framework plumbing that adds little for an agent, a small amount of dead weight.

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 15-parameter crawler with no annotations, the description covers mode selection, failure isolation, caching, deadlines, and compliance — enough to call it correctly. Return values are covered by the existing output schema, but auth/session prerequisites and concurrency limits are only gestured 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 Args block is doing all the work — and it documents 14 of 15 parameters with real semantics: depth range 0–3, limit bounded by crawl_max_pages, next_selector suppressing depth, max_pages default 5, session applying to all pages. It loses a point because a few details (e.g. timeout/proxy fallback nuances vs. global config) remain terse, but the compensation for a 15-param, 0%-covered schema is substantial.

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 opening states a specific verb and resource: discover in-site links from a start page and batch crawl them, or page through via "next page". It further splits the tool into two named modes (link mode / pagination mode) so the agent understands the tool's two distinct behaviors. It only references a sibling indirectly ("link_policy: 同 web_fetch") rather than explicitly contrasting scope with web_fetch/web_batch, 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?

"适合把一个栏目的前 N 篇读进来" gives a concrete selection scenario, and the two-mode block states which parameter selects which mode (next_selector overriding depth). There is no explicit "when not to use this / use web_fetch for a single page instead" exclusion, which keeps it at 4 rather than 5.

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

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

With no annotations, the description carries the full burden and does so: it discloses cache-bypass semantics for headers/cookies/proxy, that wait_for/scroll/click only apply at L2, that debug returns diagnostics without page content, that session must match the login session name, that a missing required field yields ok=false with missing_required, and that an omitted schema falls back to the site recipe.

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 and the web_fetch contrast are front-loaded, followed by the DSL example and an arg list. It is long but the length is justified by a 13-param DSL tool; the only slack is some repetition of the fetch-chain equivalence and a very large example block.

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-shape explanation is not required, yet the description still adds the failure contract (ok=false, missing_required). Combined with the full param semantics and DSL specification, nothing an agent needs to call this correctly is missing.

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%, so the description must compensate for all 13 parameters – and it does, documenting each arg's meaning, defaults (session=default), and interactions (proxy allocation from pool, deadline_ms degradation rules same as web_fetch). The field-rule DSL is fully specified with types, post-processing options, and worked examples.

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 ('抓取网页并按字段 schema 抽取结构化 JSON') and immediately draws the distinction from sibling web_fetch ('数据而非整页正文', '而不是一段 compact 文本'). An agent can pick this over web_fetch without opening either schema.

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 provides a clear use-case condition – when you need fields rather than full page text – and notes that the fetch chain (anti-bot tiers, login state, compliance) is identical to web_fetch. It does not explicitly say when to prefer web_fetch or web_crawl instead, so the routing guidance is implied rather than spelled out.

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: it discloses the deadline degradation ladder (skip retry, skip L2, immediate timeout), that degraded results are not written to cache, that headers/cookies/proxy requests bypass and do not populate the shared cache, and that debug returns counts and decisions but no page content. It also notes failures still return a trimmed decision trace.

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?

Purpose and the anti-bot caveat are front-loaded in one sentence, then a clean per-argument list. Dense but proportionate to 15 parameters; a few entries (proxy pool env vars) could be trimmed without losing callable 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, and the description still covers caching, degradation, sessions and proxies. The one real omission is sibling differentiation and the default rendering tier (what plain web_fetch does without wait_for/scroll/click).

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 it documents all 15 parameters: enumerated values for link_policy (internal/all/none) and format (markdown/text/json), what bypass_cache and debug do, proxy format examples, and the L2-only restriction on wait_for/scroll/click with recipe fallback. This is materially richer than the bare 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?

A specific verb and resource (fetch a web page, return token-compact body) plus notable extras: anti-bot page detection reported faithfully, support for HTML/PDF/plain text. It never names the sibling fetchers (web_crawl, web_extract, web_batch), so an agent cannot distinguish which of the four to pick from the description alone.

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

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

Usage is implied rather than stated: wait_for is flagged as suitable for SPAs, session must match the name used at login, and L2 gating is mentioned. There is no explicit when-to-use / when-not guidance and no routing to web_crawl or web_extract, which matters given three closely related siblings.

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 so well: it discloses that a snapshot is saved per successful fetch, that failures (blocking/timeout/login wall) do not overwrite the old snapshot, that reset rebuilds the baseline and returns first_seen=true, and how caching interacts with bypass_cache. Missing are concurrency/rate-limit expectations and what happens on the very first call for a URL, but the stateful semantics are unusually well surfaced.

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?

Purpose and statefulness are front-loaded, then failure/snapshot behavior, then an Args block that maps one-to-one onto the schema. The Args block is long but each line carries operational meaning; there is no filler or repeated 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?

For a 7-parameter stateful tool with no annotations, the definition covers persistence model, failure handling, first-call/baseline behavior, caching, session coupling, and proxy/deadline semantics, and an output schema exists so return shape need not be restated. An agent has enough to call this correctly on the first attempt.

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 it documents all seven parameters in ways the schema cannot: reset returns first_seen=true, bypass_cache defaults to true and lets CACHE_TTL content be reused, session must match the name used at login, deadline_ms is a total call budget, and proxy falls back to the pool or global config. This adds genuine meaning beyond types and defaults.

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

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

States a specific verb and resource: detect changes in a page (or a block within it) since the last call, with snapshot-based diffing. This is clearly a stateful watch tool rather than a plain fetch, so an agent can distinguish it from web_fetch/web_crawl in practice. It never names those alternatives explicitly, which keeps 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?

Gives a concrete usage scenario ("每天看一眼这个页面有没有新内容") and the conditions that change the behavior for reset and bypass_cache. It also ties session usage to the login tool ("需与 login 时使用的会话名一致"), which is a real routing constraint. No explicit when-not-to-use or alternative-tool guidance is given.

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