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

Beyond the annotations, it discloses the full behavioral profile: duplicate check on host/type, add-vs-modify decision, save and read-back verification, and the pause-with-screenshot behavior on login expiry or slider challenges. It also states it will not blindly continue clicking and returns step trajectories plus failure screenshots.

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 dense but well organized: purpose, flow, mode behavior, and failure handling all appear in a logical order. It is longer than minimal, but the tool is complex enough to justify each operational sentence.

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?

It covers the workflow, mode constraints, expected outputs (step trajectory and screenshots), and recovery path. No output schema exists, so the description's output disclosure is valuable and sufficient for an agent to invoke and verify the 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 100%, so the baseline is 3; the description adds meaning by explaining the duplicate-detection rule for subDomain/recordType and the mode decision. It does not add new details for ttl/line/cdpPort, but those are already well documented 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 states a specific high-level operation: add or modify a DNS record for a specified domain in the DNSPod console, and details the exact workflow. This clearly distinguishes it from generic browser/sibling tools like take_screenshot or configure_security_group.

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 clear context for mode selection (auto/create/update) and names interact_element as a manual fallback for auth/slider failures. It does not explicitly enumerate sibling tools as alternatives, but the intended use is unambiguous.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses that the tool really modifies cloud firewall config, warns but does not block high-risk port exposals, and returns failure screenshots with manual steps when UI changes break the flow. This is exactly the kind of behavioral context annotations cannot express.

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 somewhat long, but the safety warning is front-loaded and every major behavior is economically explained. The enumerated UI workflow ('按地域打开实例列表…') is arguably more operational than necessary for an API-style wrapper, which keeps it from a perfect 5, but the density is justified for a destructive 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?

For a tool with 11 parameterstons of schema detail and no output schema, the description covers the key behavioral aspects: product inference, port syntax, risk reminders, and failure handling. However, the prose focuses on the 'add' path and does not mention the read-only 'list' mode, which the schema does document but the description could usefully surface.

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?

Even though schema coverage is 100%, the description adds substantial meaning: product auto-inference from instanceId prefixes, supported port formats (single, comma-separated, ranges), protocol/policy value interpretations, and the risk reminder behavior for dangerous CIDR/port combinations. This goes well beyond the raw schema field 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 clearly states the tool's purpose: adding an inbound/outbound rule (allow or deny a port) to a specified instance's security group/firewall. It is also clearly distinct from the sibling browser-automation and DNS tools, naming the specific resource type (CVM vs Lighthouse) it operates on.

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 explains when to use the tool as a high-level wrapper, how product is inferred from instanceId, how to select direction, and the difference between add and read-only list modes. It does not explicitly say 'use this instead of interact_element' or enumerate when not to use it, but the context is strong enough for an agent to route correctly.

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?

The annotations already indicate readOnlyHint=true, openWorldHint=false, and destructiveHint=false, but the description adds valuable guarantees: it will not launch a new browser, will not close the user's window, and will not read or save credentials. It also discloses the returned browser version, CDP endpoint, and tab information, going beyond the structured annotations.

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 dense sentences each earn their place: the connection method and target, the prerequisite relationship to other tools, and the return value plus safety guarantees. Essential information is front-loaded and there is 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 two optional parameters, no output schema, and existing annotations, the description still explains the return value (browser version, CDP endpoint, tab URLs/titles), the prerequisite Edge launch flag, and the non-destructive safety profile. An agent has everything needed to invoke it correctly and interpret the result.

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 both `force` and `cdpPort` well. The description reinforces that the port must match the --remote-debugging-port value, but it adds no substantial new semantic meaning beyond what the parameter schemas already provide.

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 (connect via CDP), a specific resource (local Microsoft Edge started with --remote-debugging-port), and clearly frames itself as the prerequisite step for all other tools. This distinguishes it from the sibling browser-action and cloud-management tools without ambiguity.

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 explicitly says this is a prerequisite for all other tools and that other tools will auto-connect when not connected, giving a clear sense of when a manual explicit connection is needed. It does not spell out when not to use it, but the guidance is sufficient for an agent to decide.

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?

Adds substantial context beyond the destructiveHint=true annotation: failed operations return structured errors with a page screenshot to enable retry, clicks degrade to force-click when obstructed (and mark it in the return), fill degrades to simulated typing, and the tab auto-selection order is disclosed along with a delay floor of 20ms for web terminals to avoid dropped characters. The mutation actions align with destructiveHint=true, so there is no contradiction with the annotations.

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 paragraph that front-loads the core purpose, then flows coherently through action semantics, selector syntax, and error behavior. Given the tool's complexity (12 parameters, 9 action enums), the length is proportional — every sentence carries operational content and nothing is redundant. It could marginally benefit from bulleted structure, but the density is justified.

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 12-parameter tool with no output schema, the description achieves strong coverage: per-action semantics, selector grammar, degradation paths, tab disambiguation (pageUrlContains), iframe targeting (frameUrlContains), and error-return format. Two minor gaps remain — the undocumented 'reload' action and the unsaid success return payload (e.g., what get_text returns) — but neither blocks a competent agent from calling 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 coverage is 100%, so the baseline is 3; the description earns a point above baseline by giving operational meaning the schema lacks. The schema's action field only says '要执行的动作', while the description explains what each action does and how text/delay/submit apply per action, plus the full selector grammar (CSS, text=, xpath=, :has-text()). The only gap is that 'reload' appears in the enum but is absent from the description's action enumeration, leaving the agent to infer its meaning from the English name alone.

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 — '在当前页面上执行基础 DOM 操作' (execute basic DOM operations on the current page) — and then enumerates nearly all actions (click, fill, wait_for, hover, select, press, type, get_text) with one-line semantics each. This sharply separates it from functionally distinct siblings like connect_edge, take_screenshot, and add_dns_record, so an agent knows at a glance this is the page-interaction tool.

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?

Provides strong action-selection guidance: type is explicitly scoped to xterm/Canvas web terminals (Tencent Cloud OrcaTerm), fill is described as auto-compatible with controlled components with a degradation fallback, and pageUrlContains is flagged as strongly recommended in multi-tab scenarios with the auto-selection order spelled out and an honest '可能会选错' warning. It does not explicitly name sibling tools as when-not-to-use alternatives, but the siblings are functionally distinct enough that little exclusion guidance 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?

The description discloses behaviors beyond the annotations: it auto-detects login/captcha status, attaches a screenshot when human intervention is needed, and returns a clear error if all candidate addresses are unavailable. The annotations only indicate openWorldHint=true and destructiveHint=false, so the description adds valuable context about side effects and error handling. No contradiction with annotations.

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, well-structured paragraph that front-loads the main purpose, then lists targets, then explains behavioral details. Every sentence adds value—no fluff. It is concise yet comprehensive, covering all key aspects without unnecessary repetition.

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 navigation tool with 4 parameters and no output schema, the description covers the core functionality, target options, and error handling. It does not explicitly describe the success response format, but given the tool's nature (navigation), the response is likely a status or screenshot, which is partially implied. The auto-detection and error behavior are well explained, making it sufficiently complete for an agent to use 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 100%, so all parameters are already documented in the schema. The description adds some context (e.g., custom requires customUrl, screenshot is forced on login/captcha), but these details are also present in the schema's property descriptions. The description does not significantly enhance parameter understanding beyond what the schema provides, so a baseline score of 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 clearly states the tool's purpose: '快捷导航到腾讯云控制台的指定页面' (quickly navigate to specified pages of Tencent Cloud console). It enumerates the four targets (dnspod, cvm, lighthouse, custom) and explains the auto-detection behavior. This is a specific verb+resource definition that distinguishes it from sibling tools like add_dns_record or configure_security_group, which perform different actions.

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 when to use the tool: when you need to navigate to a Tencent Cloud console page. It provides a specific usage hint: '当腾讯云控制台改版时可据此改用 custom 目标' (when the console changes, use custom target). However, it does not explicitly contrast with alternatives like add_dns_record or interact_element, though the context of sibling tools makes the distinction clear. It could be more explicit about when not to use this tool.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds valuable behavior details: returns Base64 PNG, auto-degrades to viewport if full-page exceeds ~3.5MB, and notes this in the return. No contradiction.

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 structured: main function, use cases, usage recommendation, and degradation note. It's slightly wordy but each sentence contributes value, and key information 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?

Covers return format, degradation behavior, and usage suggestions. It doesn't mention prerequisites like an active connection, but that's implied by sibling tools (connect_edge) and not essential. Overall, it's complete enough for an agent to call 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 coverage is 100%, so all four parameters are already documented in the schema. The description adds minimal extra meaning (e.g., the degradation note relates to fullPage), but doesn't go beyond the baseline for high 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?

Description states a specific verb (screenshot) and resource (Edge current active tab), and lists concrete use cases like verifying page state and detecting captchas. It clearly distinguishes from sibling tools, none of which handle screenshots.

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?

Provides clear usage context: recommended after every key operation, and lists specific scenarios. However, it doesn't explicitly state when not to use it or mention any alternatives, though none exist among 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?

Annotation Contradiction: the description says mode=confirm 'clears pending state', which is a state mutation, while annotations declare readOnlyHint=true. The description is otherwise behaviorally rich (polling, timeout bounds, return values), but the direct contradiction with readOnlyHint makes the annotation untrustworthy for an agent.

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 front-loaded with the trigger case, then organizes modes in a consistent, scannable structure. Every sentence covers a distinct aspect—trigger, mode behavior, and return values—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?

With no output schema, the description correctly covers return values (screenshot, current URL/title) and explains all three modes plus timeout defaults and limits. The main gap is that it does not state the result or error shape when wait times out, nor explicitly mention a prerequisite connection, though cdpPort and sibling context partially cover that.

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, but the description adds meaningful semantics for mode behavior and timeout semantics (e.g., detect returns immediately and can be polled, wait polls until completion, timeoutMs only applies to wait). note and cdpPort are not expanded beyond the schema, but the schema covers them.

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 trigger (login expiry, captchas, WeChat scan) and a specific action: pause the automation flow and wait for human intervention. The three modes are individually described, making the tool's role unmistakable and clearly distinct from siblings like take_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?

It explicitly says when to use the tool (when login/verification needs human handling) and gives mode-level guidance, including the note that detect suits clients with tool timeout limits and can be repeatedly polled. However, it does not name alternative sibling tools or state explicit when-not-to-use conditions.

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