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 discloses important behavioral traits: the start-before-request timing constraint, tab-bound monitoring that does not migrate, that 'get' returns an inline overview while full data lands in a JSON file for 'read', and that 'stop' clears the capture. These are meaningful operational details.

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 compact and front-loaded with a summary ('三合一') followed by per-action groupings, each earning its place. No redundant sentences beyond the heading. Dense but efficient.

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 three-mode capture tool with no output schema and no annotations, the description covers the critical timing, scoping, and result-handling details an agent needs. It could mention permissions or how the JSON file path is obtained, but the core operational picture is 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?

Schema description coverage is 100%, so the schema already documents all four parameters including the enum and method filter defaults. The description adds only a brief parenthetical about the overview/JSON-file split for 'get' at the top level, which is marginal beyond what the schema provides. Baseline 3 is appropriate.

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 clear verb+resource: network capture with three modes (start/get/stop) broken out explicitly. It is distinguishable from siblings like run_cdp or execute_js, though the exact relationship to browser-attached siblings is not explained. Purpose is clear without being fully differentiated.

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 gives clear sequencing guidance: 'start' must be called before triggering the request, and monitoring is bound to the current tab rather than following the pointer. It does not name alternatives or when-not-to-use, but the timing and scoping instructions are actionable.

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 provided, the description carries the full burden of behavioral disclosure. It states the action (close) but doesn't describe what happens—e.g., whether it gracefully shuts down the browser, kills processes, affects other tools, or has side effects like losing unsaved data. This is a significant gap for a potentially destructive operation.

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

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

The description is a single, efficient sentence ('关闭浏览器实例') that directly states the purpose without waste. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.

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 the tool's potential complexity (closing a browser could involve cleanup, state changes, or errors) and lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects, return values, or error conditions, leaving gaps for an AI agent to understand its full context.

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 has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's acceptable here. Baseline is 4 for zero parameters, as there's nothing to compensate for.

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 '关闭浏览器实例' (close browser instance) states a clear action (close) on a resource (browser instance), but it's vague about scope—it doesn't specify whether this closes all browser windows, a specific instance, or just the current tab. It distinguishes from siblings like 'navigate_to_page' or 'get_browser_status' by being a termination action, but lacks precision.

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?

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention if this should be used after completing tasks, to free resources, or as part of cleanup, nor does it reference sibling tools like 'launch_chrome_manually' for context. The description alone offers no usage context.

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 discloses the critical behavioral rule that the code must use return to produce a result, plus the default 150s timeout. It does not cover error behavior, sandbox/permission constraints, or what happens when the script throws, leaving meaningful gaps for a code-execution tool.

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 core action comes first, then the return-value warning, then the preset override. No filler sentences, though the preset paragraph is dense and could be slightly tightened.

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 no annotations and no output schema, the description must explain the return contract, which it partially does via the return-statement warning. However, it is silent on error handling, result serialization, and side effects, which matter for an arbitrary JS execution 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 coverage is 100% and each parameter is already documented, so baseline would be 3. The description adds value beyond the schema by showing the exact JSON argument shape for preset='dom_tree' with concrete keys (max_depth, include_text, max_text_length, selector), clarifying how the overloaded 'code' parameter behaves.

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: execute JavaScript code in the current tab, and clarifies a second mode (preset='dom_tree') that changes what 'code' means. It does not name or contrast with siblings like run_cdp or run_drission_code, so an agent must infer which execution tool to pick.

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 gives the condition for the dom_tree preset (pass JSON params instead of code), which is useful usage guidance, but it never says when to prefer this tool over run_cdp or run_drission_code, nor any exclusions or prerequisites.

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 disclose the essential behavior — a zero-parameter read that returns reference content, therefore inherently non-destructive — but says nothing about return format, length, or whether the content is static or context-dependent. That omission is notable for a tool whose entire value is the 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 front-loaded sentence that leads with what is returned before the topic enumeration. Every clause earns its place by telling the agent what content to expect. Slightly list-heavy, but no filler or redundancy.

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 zero-parameter, no-output-schema retrieval tool, the description supplies the one thing the agent needs: what knowledge it will obtain. The lack of any hint about return size or format is the main residual gap, but the topic list makes the tool's purpose sufficiently clear to call.

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; the 4 baseline applies. The description makes clear it is invoked without arguments, matching the empty object schema with 100% coverage.

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

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

States a specific verb+resource: it returns a built-in authoring manual, and enumerates the topics covered (locator syntax, element actions, waits, tab management, capture, CDP recipes, launch customization). This clearly distinguishes it from siblings like run_cdp or run_drission_code, which execute rather than document. It stops short of a 5 only because the manual's scope beyond the listed topics is undefined.

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?

No when-to-use guidance, no prerequisites, and no reference to the sibling tools whose DSL it presumably documents. The agent must infer on its own that this is a reference to consult before calling run_drission_code or run_cdp. Nothing states when-not to call it or whether it is cheap to call repeatedly.

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 burden and discloses notable side effects: opening a new tab, switching the operation pointer, and the return payload. It doesn't mention failure modes or timeouts beyond what the schema covers.

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?

Concise single paragraph, front-loaded with purpose and then tab semantics. No redundant 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 4-param navigation tool with no annotations and no output schema, the description explains inputs, defaults, and return shape, which is nearly complete. Lacks failure handling or edge cases but sufficient for correct invocation.

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

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

Schema description coverage is 100%, so parameters are already documented. The description reinforces the new_tab and pointer behavior, but adds no syntax or constraints beyond what the schema provides.

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

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

States a specific verb (导航/navigate) and resource (URL), and the scope (tab handling) is spelled out. An agent can immediately tell it performs page navigation as opposed to the code-execution 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?

Describes default behavior (current tab) versus new_tab=true, but doesn't reference alternative siblings like run_drission_code when programmatic navigation is needed. Clear context for the primary usage, minor gap on alternatives.

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 a non-obvious side effect: Target.createTarget/activateTarget silently change which tab subsequent commands act on. That is exactly the kind of behavioral trait annotations would otherwise cover. It still omits return shape, error behavior, and any auth/permission constraints.

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, front-loaded with the core action and followed by the tab-scoping caveat and a pointer to get_manual. No filler, though the parenthetical about tab switching is dense and could be split for readability.

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 raw passthrough tool with no output schema and no annotations, the description covers what it does, its scoping constraint, the auto tab-switch side effect, and where to get deeper detail (get_manual). Return values and failure modes are undefined but are inherently method-dependent, so this is close to 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?

Schema description coverage is 100%, so the baseline is 3. The description's example ('Page.captureScreenshot') and its note that params is an optional argument object largely restate what the schema already documents for method and params, adding little new semantic content.

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: passing through Chrome DevTools Protocol commands to the current tab, with a concrete example method. It implicitly distinguishes itself from siblings like execute_js, capture, and run_drission_code by being the raw-CDP escape hatch, though it never names an alternative.

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 useful operating context (commands always act on the current tab, no attachToTarget needed, createTarget/activateTarget auto-switch the operating tab) and defers to get_manual. However, it never says when to prefer this over execute_js, capture, or run_drission_code, which is the main selection decision an agent faces.

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 runtime behavior: it runs server-side, exposes preset page/browser/context variables, and must return results. However, for arbitrary code execution it omits any warning about side effects, permissions, or failure behavior, which is a notable 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?

A single dense block, front-loaded with the purpose before environment details, with no filler sentences. The ⚠️ return requirement is correctly emphasized, though the run-on layout slightly reduces 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?

For a code-execution tool with no output schema and no annotations, the description supplies the essential execution context: environment, preset variables, preset functions, and the return convention. It is largely complete, missing only error/edge-case behavior.

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 both parameters (code, timeout) are already documented, establishing the baseline of 3. The preset variables and functions listed in the description enrich the code-writing context but do not clarify the parameters themselves beyond what the schema provides.

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

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

States a specific verb and resource ('执行 DrissionPage Python 代码') plus scope ('server 进程内'), which clearly separates it from the JS-oriented execute_js sibling. It never explicitly names an alternative, so it lands at clear-but-undifferentiated rather than a full 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 when-to-use/when-not guidance and no mention of alternatives like execute_js, run_cdp, or navigate. The phrase '完整能力底座' only hints that this is the general-purpose escape hatch; the agent must infer selection criteria on its own.

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