抓取页面 DOM

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

With no annotations, the description carries the full behavioral burden. It does disclose two useful traits beyond the schema: the default is 'both' and overly long HTML is automatically truncated. However, it omits whether this is a pure read, any permission/context requirements, and what truncation actually does to the returned payload.

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

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

A single dense sentence front-loads the resource, then lists the output modes and the two behavioral facts (default 'both', auto-truncation). Nothing is wasted and the key information comes first.

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 6-parameter, no-required-args read tool with no output schema and no annotations, the description is adequate on purpose but thin on behavior: it does not characterize the returned payload shape, how truncation is signaled, or any relationship to sibling capture tools. Parameters themselves are fully covered by the schema.

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 100%, so every parameter (mode, depth, maxNodes, skipHidden, maxHtmlChars, maxTextLength) is already documented with its default in the schema. The description only restates the mode default and truncation behavior, adding no syntax or interaction detail beyond the structured fields — the expected baseline.

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 ('获取当前页面的 DOM') and enumerates the three output modes (raw HTML, LLM-friendly indented outline, or both), so the agent knows exactly what this returns. It does not, however, differentiate itself from nearby siblings like page_evaluate or page_screenshot.

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 when-to-use or when-not-to-use guidance. The phrase '适合 LLM 阅读的缩进结构大纲' implies the outline mode exists for LLM consumption, but the description never says when to prefer this over page_evaluate, page_screenshot, or network_body, nor does it state any prerequisites.

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