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 the one-shot user-data-dir (auto-deleted on close), that it won't hijack the user's existing profile, that the port binds only to 127.0.0.1, and that it returns the port number. It omits failure/timeout behavior and whether the caller must close the instance.

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 core capability and the key scoping guarantees are front-loaded, and the sentences are dense with useful facts. Slightly verbose with the parenthetical profile explanation, but no real waste.

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?

Despite no output schema, the description explicitly says it returns the port number and points to desktop_cdp_open for the next step, covering the round-trip an agent needs. All optional params have defaults documented in 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 coverage is 100%, so the schema already documents all five parameters and their defaults. The description echoes the userDataDir purpose (persist login state) and headless behavior, adding only marginal value beyond 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 verb (启动/launch) and resource (a CDP-debuggable Edge/Chrome instance) and names the essential flags. It is clearly distinguishable from desktop_cdp_open, which it explicitly hands off to.

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 clear context: use this first, then connect via desktop_cdp_open, and headless=true is for automation while false shows a real window. It does not explicitly state when NOT to use it (e.g., if an instance is already running), but the workflow guidance is strong.

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 does disclose meaningful traits: real mouse events via CDP, center-of-rectangle targeting (no coordinate guessing), and explicit error-on-duplicate behavior. It omits prerequisites such as needing an open CDP target/session (see desktop_cdp_open, desktop_cdp_targets) and says nothing about what is returned.

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 tight sentences, front-loaded with the action, then the mechanism, then the failure mode. 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?

For a mutation-style UI action with no annotations and no output schema, the description covers mechanics and the ambiguity case but not the CDP session precondition or the result of a successful click. An agent could still mis-invoke it without an attached target.

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 three params are already documented, including fuzzy matching and role-based disambiguation. The description only reinforces the duplicate-name/role interplay, so 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?

States a specific verb+resource ('按名称点击页面里的控件') and adds the mechanism ('走 CDP 注入真实鼠标事件'), which separates it from plain desktop_click. It doesn't explicitly name which sibling to prefer among desktop_click / desktop_click_element / desktop_cdp_type, so it stops short of full differentiation.

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 one useful usage condition: ambiguous names cause an error with candidates listed, implying the role param should be used to disambiguate. It never says when to choose this over desktop_click or desktop_click_element, leaving the biggest routing decision to inference.

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 destructive side effect (killing the launched browser process) and the leak risk of not calling it. It does not say whether the kill is unconditional, what happens if the session is already gone/dangling, or what the call returns on partial failure.

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 sentences, both earning their place: the first defines behavior, the second is a front-loaded obligation with a stated consequence. No redundancy with the title or restated field names.

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 2-parameter, no-output-schema, no-annotation cleanup tool this is largely sufficient — purpose, side effects, and the imperative to call it are all present. The residual gap is failure-mode behavior (dead session, browser already closed) which an agent would have to probe empirically.

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 bump by identifying whose browser process gets killed ('由 desktop_browser_launch 启动的'), which is what an agent needs to reason about setting killBrowser=false. The 'session' parameter's 'omit = close all' behavior is left entirely to 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 verb+resource ('关闭 CDP 会话') and the additional effect of killing the browser process, explicitly tying it to the counterpart launcher 'desktop_browser_launch'. An agent can distinguish this cleanup tool from desktop_cdp_open/desktop_cdp_* siblings and from desktop_browser_launch without opening 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 explicit when-to-use guidance plus the consequence of skipping it, which is strong for a cleanup tool. It stops short of naming alternatives (e.g. what to do if you want to keep the session alive) or stating any preconditions about which session must be active.

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 real behavior: de-duplication of AX nodes (only the operable button is kept) and full preservation of Chinese names. That is meaningful context beyond the schema. It does not disclose that it is read-only, what connection state it requires, or pagination/truncation behavior when `limit` is hit, leaving notable gaps.

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 short and front-loaded: the first line states what it does and where, and the dedup note is the most useful extra detail. The Chinese-name preservation remark is marginally useful. Minimal waste overall.

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 does cover the return shape (role, name, depth), which is the main completeness need. But for a tool with no annotations it omits prerequisites (CDP session/attach state) and truncation semantics for `limit`, leaving an agent without enough to call it reliably in edge cases.

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% — all three parameters (`role`, `limit`, `session`) carry their own descriptions, so the schema does the heavy lifting. The description adds nothing about parameter behavior (e.g., what role values are valid or how limit truncation surfaces), so the baseline of 3 applies.

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: enumerate the controls in the current page via the CDP accessibility tree, and it names the fields returned (role/name/depth). The phrase '当前页面' (current page) signals a browser/CDP context. However, it never explicitly contrasts with the sibling desktop_elements, which appears to be the non-CDP equivalent, so an agent must still infer the distinction.

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 CDP context and 'current page' scope, but the description never states when to prefer this over desktop_elements or desktop_perceive, nor does it say any prerequisites (e.g., an attached CDP session). The optional `session` param hints at a session model, but the conditions for choosing this tool are left to inference.

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 burden; it states that results are JSON-serialized and that it runs in the current page. It omits that arbitrary JS can mutate the page, how errors/exceptions surface, and whether the expression runs in the page's main world, which are meaningful gaps for an eval tool. What it does disclose about behavior is accurate, so no contradiction arises.

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 short sentences lead with the operation and then give a comparative rationale. Nothing is padded, and the second sentence directly supports tool selection.

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 3-parameter tool with full schema coverage and no output schema, this is nearly complete: the return value (JSON-ified) is described and the scope (current page, or session) is implied. The missing piece is failure behavior when the expression throws or the result is not serializable.

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%, with every parameter documented in the schema, including expression and the IIFE hint, so the baseline is 3. The description adds no additional detail about expression syntax, session handling, or when to set awaitPromise.

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: execute JavaScript in the current page and return the result, JSON-serialized. That is clearly distinct from siblings such as desktop_cdp_elements or desktop_cdp_click, but the description never names those alternatives explicitly, so differentiation must be inferred.

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?

"Information you can't get, just ask the page for it" implies a when-to-use condition: fall back here for data that the structured extraction tools miss. It gives no when-not guidance, no warning that this is arbitrary code execution, and never points to desktop_cdp_elements/desktop_elements as the cheaper alternative.

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 exist, so the description carries the full burden. It usefully discloses the persistent session model and that the port is auto-scanned, but it states '带 url 时会先导航过去' while the schema says url is a filter by default (navigate=false), which is a behavioral conflict an agent could trip over. It also omits whether a browser is launched if none is running and whether only one session may be active.

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 core action and session relationship, then selection modes, then the entry-point rationale. Dense and largely waste-free; only the url-navigation sentence works against the tool rather than for it.

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 five-parameter, zero-required, no-output-schema connection tool, the description covers the session model, selection strategies and the Chromium rationale. What's missing is what happens on failure (no debug port found, no target match) and whether the session must be released with desktop_cdp_close.

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 and the schema already explains url, title, index, port and navigate. The description adds the selection modes (title/url substring or index) but muddies the url parameter by implying it always navigates, contradicting the navigate flag's documented default of false.

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 (connect to a browser page, establish a CDP session) and immediately clarifies that all subsequent cdp_* tools operate on that session, which separates it from desktop_cdp_click/type/eval in the sibling list. The added note that this is the entry point for Chromium-family apps (Chrome/Edge/Electron) makes the scope unmistakable.

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 real routing guidance: use this for Chromium apps because UIA can't see inside them, which tells the agent when to prefer CDP over the desktop_perceive/desktop_click family. It does not cover sequencing explicitly (whether desktop_browser_launch is a prerequisite, or that desktop_cdp_close ends the session), so it stops short of full when/when-not 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 provided, the description does carry the burden of behavioral disclosure. It usefully states that the result is a PNG and that the capture is page-level rather than full-screen, but it does not mention prerequisites such as an open browser/CDP target, read-only/safety behavior, or failure cases.

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 short, front-loaded, and every sentence adds useful information: scope, return format, and rationale for choosing page-level screenshots.

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 simple one-parameter screenshot tool with no output schema and no annotations, the description covers the key behavioral facts: current page only, PNG output, and when it is more useful than full-screen capture. It could be more complete by noting browser/CDP prerequisites, but the essentials are present.

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 optional session parameter is already documented in the input schema. The description does not add any parameter-level semantics beyond the schema; a 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 specific verb and resource: capture the current page, explicitly not the full screen, and returns PNG. It also distinguishes the tool's scope from full-screen screenshots, which is a sibling capability (desktop_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 gives clear usage context: use page-level screenshots when the goal is to judge the browser page state, compared with full-screen screenshots. It does not explicitly name the alternative sibling tool or state when not to use this tool, so it stops short of full when/when-not 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 well: it declares the read-only/no-mutation guarantee and explains the meaning of an empty result. It stops short of describing what a populated result looks like (endpoint addresses, page titles/URLs, fields per target), which matters since no output schema exists.

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 safety profile, then the decision it supports, then the fallback action. Every sentence earns its place 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?

For a zero-parameter read tool with no output schema, purpose, safety, and the empty-result routing are all covered. The only meaningful omission is the shape of a non-empty result, which the agent must discover by calling it.

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 schema is empty and the description correctly adds no parameter guidance where none is needed.

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: scans all open CDP debug endpoints on the local machine and their pages, explicitly read-only. This clearly separates it from siblings like desktop_cdp_open, desktop_browser_launch, and desktop_list_windows, which act on windows or connections rather than enumerating endpoints.

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 decision rule: use it to determine whether a browser can be connected to right now, and if the result is empty, use desktop_browser_launch to start one. Both the when-to-use and the fallback path are named, leaving nothing to inference.

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, so the description carries the full burden. It does disclose the underlying mechanism and one useful behavioral trait (bypasses keyboard layout, so IME/emoji safe), but omits meaningful traits such as the need for an attached CDP session (cf. desktop_cdp_open/desktop_cdp_targets), whether key events fire, and what happens when target matches nothing.

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 sentences, front-loaded with the action and then the mechanism rationale. Little waste, though the parenthetical comparison to SendKeys/clipboard is more justification than invocation guidance.

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?

Four parameters with complete schema documentation and no output schema, so the description need not explain returns. However, for a UI-mutating tool with zero annotations it should state prerequisites (attached CDP page) and failure behavior for target mismatch, which it does not.

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 four parameters are already documented. The description repeats the target-focus behavior ('可用 target 先聚焦') without adding format or edge-case detail beyond the schema, so the baseline of 3 applies.

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 ('向页面输入文本') and immediately names the mechanism (CDP Input.insertText), which distinguishes it from the OS-level desktop_type/desktop_key siblings. It never names desktop_type explicitly, so an agent must infer the routing from the mechanism comparison.

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?

Implies the right context ('中文 / emoji 天然无损', '比 SendKeys 和剪贴板都干净'), which suggests when to prefer it, and mentions using target to focus first. But there is no explicit 'use this instead of desktop_type when X' statement or any exclusion, leaving the choice between the two typing tools to inference.

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 flag the key trait: this performs a real OS-level click with real side effects, so the agent should verify the target first. It omits other behavior an agent needs: whether the target window must be focused first, whether the call blocks, what failure looks like, and what the verify flag actually returns.

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 clauses, all load-bearing: what it does, the risk warning, and the coordinate-sourcing tip. The most important information (real desktop operation) is front-loaded 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?

For a 6-parameter, nested-object, no-annotation, no-output-schema mutation tool, the description covers purpose, risk, and coordinate derivation but says nothing about the verify/verifyRegion feedback loop — the very mechanism an agent must understand to know whether the click landed. Adequate but with a clear gap for a side-effecting desktop 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 67%, and the two undocumented parameters are exactly the required ones (x, y). The description compensates by explaining what those coordinates refer to and how to obtain them from desktop_perceive's window rect rather than guessing, which is genuine added meaning over 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?

States a specific verb and resource (click the mouse at given coordinates) plus the concrete constraint that it really manipulates the desktop. It distinguishes itself from the pure-read siblings by pointing at desktop_perceive as the coordinate source, though it never explicitly contrasts with desktop_click_element, the element-based 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?

Gives a clear precondition ("confirm the target position before calling") and an actionable how-to for building the arguments (derive coordinates from the window rect returned by desktop_perceive, e.g. its center). It stops short of saying when NOT to use it, e.g. preferring desktop_click_element when an element handle is available, so routing between the two click tools is left to inference.

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 the crucial trait that this "会真实操作界面" (really manipulates the live UI) plus the fallback to clicking the element's center, which implies positional mis-click risk. It leaves open what happens on fuzzy multi-match or no-match, and says nothing about the effects of verify/verifyRegion.

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 lines: the action, the dispatch strategy, then the safety caution. Front-loaded and free of filler, though the middle line leans toward implementation detail an agent cannot act on.

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 live-UI mutation tool with no annotations and no output schema, the description covers the safety warning and matching strategy but omits the result contract (what is returned on success/failure) and multi-match ambiguity handling with fuzzy text. Adequate but with clear gaps.

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 name, handle, verify and verifyRegion are already documented in the schema; that sets the baseline at 3. The description reinforces the text-matching intent of `name` but adds no meaning beyond the schema for handle or the screenshot-comparison parameters.

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 (trigger) plus a specific locating strategy (visible text), which distinguishes it from the coordinate-based sibling desktop_click. It stops short of naming desktop_click/desktop_elements explicitly as the alternative, so the differentiation is implied 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?

The "prefer InvokePattern, fall back to center click" sentence describes internal dispatch, not when an agent should choose this tool over desktop_click or desktop_elements. The only actionable directive is the caution to confirm the control name first; there is no explicit when-not condition or named alternative.

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 does disclose the key behavioral trait: read-only, no side effects. However it says nothing about return format, coordinate space (screen vs window, multi-monitor origin, DPI scaling), which is the main behavioral risk for a coordinate-reading 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?

A single short clause with the operation and its safety property front-loaded; every word earns its place and nothing is 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?

For a zero-parameter, no-output-schema tool, the description conveys what is returned (cursor coordinates) and that it is safe. A note on coordinate reference frame would make it fully complete for multi-monitor or scaled-display setups.

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; there is nothing parameter-related the description needed to explain and none is missing.

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: reads the current mouse cursor coordinates, which is clearly distinct from siblings like desktop_move, desktop_click, or desktop_perceive. It doesn't explicitly name what it is not, 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?

Usage is only implied — an agent can infer this is the tool to call when it needs the cursor position (e.g. before a relative desktop_move). No explicit when-to-use context, prerequisites, or alternatives are given.

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 does disclose key traits: rule-based matching, millisecond latency, and no LLM invocation — so the agent knows it is cheap, deterministic, and safe to call freely. What is missing is any hint of the response shape or whether a low-confidence/unmatched input returns nothing useful.

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 sentences, front-loaded with the value proposition, then the relation to automatic diagnostics, then the cost profile. No filler or repetition of the tool name.

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 low-risk, three-parameter analysis tool with no output schema, the description covers purpose, cost, and invocation context adequately. It could say more about what the 'why + what to do' payload looks like or when a match fails, but nothing essential is missing to call it 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 three parameters are already documented in the schema. The description only refers generically to 'an arbitrary error text' and adds nothing about how `output` or `command` change the diagnostic (the schema's note about auto-patching is the only guidance). 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?

States a concrete transformation: turn an error string into 'why + what to do'. It also positions the tool against the built-in automatic diagnosis that accompanies tool errors, so an agent can tell what this adds. The verb and resource are both specific, not a restatement of 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?

Explicitly says the tool is for manually diagnosing an arbitrary error text, and notes that errors from any tool already carry a diagnosis — a strong implicit 'when you don't need this'. It stops short of an explicit exclusion statement (e.g., 'do not call this on an already-diagnosed tool error').

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 mostly does: it discloses the return shape, the handle dependency on desktop_list_windows/desktop_perceive, and the important behavioral caveat that Electron/Chromium apps return few or zero elements. It does not mention cost, latency, or that UI Automation queries can hang on unresponsive windows — minor omissions for an unannotated read 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?

Front-loaded with the operation, then return fields, then intended use, then the caveat — a clean progression with no filler. The persuasive line about being more reliable than coordinate guessing is slightly redundant with the usage sentence, keeping it just under perfect.

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 tool with no annotations and no output schema, the description compensates by enumerating the return fields and flagging the main failure mode. It lacks only robustness details (empty-result handling, latency on hung windows) that an agent would want before calling it blind.

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 (handle and maxElements with default 300) are already documented in the schema. The description only implies that a window scope is required ("a window") and adds no format or default detail beyond the schema, so baseline 3 applies.

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 (enumerate UI controls in a window via UI Automation) and immediately names the sibling it must not be confused with (CDP-based element access for Electron/Chromium). The listed return fields (name, type, AutomationId, rect, Invoke-ability) pin down what kind of data comes back, letting an agent distinguish it from desktop_perceive / desktop_screenshot without opening 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?

Explicitly says when to use it (locating a concrete control like an "OK button" rather than guessing coordinates) and when not to (Electron/Chromium apps that expose no control tree — use CDP instead). The alternative route is named and the failure condition is quantified ("very few or 0 elements").

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. It usefully discloses the non-obvious trait that a minimized window is restored before focusing, but says nothing about what happens with a stale/invalid handle, whether the call can block, or what is returned on success/failure.

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 short sentences, zero filler, with the core action front-loaded and the handle provenance trailing as supporting detail. Every clause earns its place.

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 mutation-style GUI action with no annotations and no output schema, the description covers the main behavior and input source but leaves the 'verify' parameter and the return/failure semantics entirely unexplained.

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 only 50%: 'handle' is minimally described in-schema (the description adds the useful detail of which tools produce it), but the optional 'verify' parameter is never mentioned anywhere. With half the parameters undocumented, the description does not compensate for the coverage 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?

A specific verb+resource pair ('bring the window with the given handle to the foreground') that an agent can distinguish from siblings like desktop_screenshot or desktop_click. It does not differentiate itself from other activation-adjacent tools (there are none obvious), but the action is 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?

The second sentence tells the agent exactly where the handle must come from (desktop_list_windows / desktop_perceive), which is a concrete prerequisite and effectively routes the agent to call discovery first. No explicit exclusions or failure conditions are stated.

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 must carry the full burden, and it does disclose the key behavioral trait: input goes to whatever window currently has focus, so results depend on desktop state. It says nothing about side effects (keystrokes go to a live desktop), failure modes (no focused window), or what `verify`/`verifyRegion` do.

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 short sentences, front-loaded with the action and examples, then the targeting constraint. Every sentence carries information; no padding.

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-parameter input tool with no annotations and no output schema, the description covers what it does and where input lands, which is the minimum an agent needs. It leaves the verification parameters and return/error semantics unexplained, which is a real gap given `verify` is entirely undocumented.

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 67%, and the description merely repeats the combo examples already present in the schema's `combo` description. The `verify` boolean has no description anywhere, and the description does not compensate for that undocumented parameter or explain what verifyRegion comparison returns.

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 (send a key combo) with concrete examples (ctrl+c, alt+tab, f5) and the target scope (current focused window). This separates it in practice from desktop_type, though the sibling is never named, so differentiation is inferred rather than explicit.

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 note that it acts on the currently focused window implicitly tells the agent it must focus a target window first (e.g. via desktop_focus_window), which is useful implied guidance. There is no explicit when-to-use vs desktop_type or desktop_click_element, and no when-not-to-use.

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 exist, so the description carries the full burden. It does disclose the returned field set, which is genuinely useful behavioral context, and 'enumerate' implies a read-only operation. But it never explicitly confirms it is side-effect free, says nothing about cost/latency of enumerating all windows, and doesn't note whether hidden or off-screen windows are excluded from '可见'.

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: purpose, return payload, then use case. No filler. The opening '结构通道：' is mild jargon that costs a few tokens without adding much, keeping it just shy of a 5.

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 usefully enumerates the return fields, which is exactly the gap it needs to fill for a zero-parameter listing tool. What remains missing is the relationship to the other desktop discovery tools, but the core call information 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no filtering arguments are needed.

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 ('枚举当前所有可见窗口') and immediately lists what it returns (handle, title, process name, PID, rect, focus/minimize state). The '结构通道' framing implicitly contrasts it with the pixel-based siblings (desktop_screenshot / desktop_perceive), though it never names them, so the differentiation is inferential rather than explicit.

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?

Offers an implied use case: learn 'what's on screen' and locate a target window's position, which naturally precedes desktop_focus_window / desktop_click. However, it never states when to prefer this over desktop_perceive, desktop_elements, or desktop_cdp_targets, 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?

With no annotations, the description carries the behavioral burden. It usefully discloses that the tool does not click and has low side effects, and that verify can screenshot-compare UI changes, but it omits coordinate system, permissions, return behavior, and failure modes.

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 compact sentence with the action front-loaded and no wasted text. The parenthetical '不点击' is high-value clarification.

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 simple mouse-move tool with no output schema and no annotations, the description covers the basic action and verify option. However, it leaves important gaps around coordinate semantics and what verify returns or does, so it is only minimally 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 coverage is only 33%, and the x/y parameters have no schema descriptions. The description says only '指定坐标' without explaining origin, units, or screen/window coordinates. The verify parameter is already described in the schema, and the description adds usage context rather than deeper semantics.

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 uses a specific verb and resource: '移动鼠标到指定坐标' and explicitly clarifies '不点击'. This distinguishes it clearly from sibling tools like desktop_click, so an agent can immediately tell what the tool does.

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 concrete usage contexts: '可用于定位或配合 verify 观察界面反应'. It does not explicitly name alternatives or state when not to use it, but the intended use is clear enough.

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 the two-channel process, the per-window consistency verdict, the enumerated failure reasons (minimized / offscreen / blank), and a non-obvious side effect — results are auto-written into the memory layer. It does not mention cost/latency of per-window visual sampling or that image data is returned, which is why it is not a 5.

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 core capability and followed by mechanism, output and follow-up. No filler, though the parenthetical '(核心能力)' is a self-assessment that adds little for 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?

There is no output schema, and the description compensates by stating what is returned (per-window consistency verdict plus inconsistency reasons). It leaves a gap about the image payload implied by format/maxWidth/includePng, but for a zero-required-parameter perception tool the essentials are covered.

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 format, maxWidth and includePng are already fully documented in the schema. The description adds no parameter-level meaning beyond the visual-sampling concept, so the baseline 3 applies.

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 mechanism (dual-channel: structural window enumeration + visual region sampling with cross-validation) and the resource it operates on (each desktop window). This is clearly distinct from a plain capture tool like desktop_screenshot or desktop_list_windows, though it never names those siblings explicitly to make the contrast airtight.

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 establishes the follow-up flow ('结果会自动写入记忆层，之后可用 memory_recall 按指代定位'), which is useful routing guidance. But it never says when to prefer this over desktop_screenshot or desktop_list_windows, nor any precondition or exclusion — the when-to-use is only inferable from '核心能力'.

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 does solid work: it discloses the return format and that dimensions are included, plus a practical cost/payload tradeoff. It does not state capture scope (full virtual desktop vs. primary monitor) or whether other windows occlude the result, which matters for a screenshot 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?

Three short lines, each doing distinct work: what it captures and returns, why it is different from the structural channel, and how to control size. Front-loaded and zero 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?

No output schema exists, but the description still states the return shape (encoded image + dimensions), so an agent knows what to expect. Residual gap is operational context — multi-monitor/DPI behavior and capture scope — which is not covered anywhere else.

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 baseline is 3, but the description adds genuine meaning: it explains the joint use of maxWidth and format as a payload-size lever, with a concrete example value. That is behavioral guidance the schema's terse per-field descriptions do not convey.

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?

Opening line states a specific verb and resource: 截取主屏幕 (capture the main screen), and immediately names the return payload (PNG/JPEG base64 + dimensions). The second line differentiates it from the structural/accessibility channel (desktop_elements, desktop_perceive), which is the key sibling distinction an agent needs.

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?

Explicitly says when to reach for this tool: to see layout, colors, and icons that the structural channel cannot provide. It also gives a concrete usage recipe (pass maxWidth ~1280 + format:"jpeg" when message size matters). It does not mention the browser-specific alternative desktop_cdp_screenshot, so it falls short of a full when/when-not map.

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. It discloses delta sign/direction, but says nothing about the verify/verifyRegion verification flow, what happens after scroll, what is returned, or whether the operation is synchronous — a major gap for a tool with a built-in verification mechanism.

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 short sentences with the core action and the most important parameter detail front-loaded. No wasted text, though it is quite terse given the tool's complexity.

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 5-parameter tool featuring a nested verifyRegion object and a verify flag (a verification feature), the description omits any explanation of that mechanism, which is a substantial omission given no annotations and no output schema offsetting it.

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 only 40%. The description usefully expands delta (positive = up, 120 per notch) beyond the schema's default note, but leaves verify and verifyRegion unexplained, and verify has no schema description at all. Partial compensation for the coverage 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?

States a specific verb and resource: scrolling the wheel at a given coordinate, which is distinct from siblings like desktop_click or desktop_move. It does not explicitly contrast with those siblings, but the action itself is 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?

The description explains delta semantics but gives no guidance on when to use this tool versus alternatives (e.g., desktop_perceive, desktop_click) or any prerequisites/conditions. An agent must infer the usage 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, the description carries the burden and does well: it discloses that the clipboard is overwritten, that input goes to whatever window currently has focus (a real risk of misdirected input), and why the clipboard hack exists (SendKeys mangles Unicode). It does not say whether the prior clipboard is restored, nor anything about timing or what is returned.

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 lines, front-loaded with what it does and supports, then the mechanism rationale, then the side-effect warning. Every sentence earns its place and the most important caveat is last but still prominent.

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?

A mutation tool with no annotations and no output schema needs its description to carry safety and result semantics. The clipboard/focus side effects are covered, but the verify/verifyRegion behavior, whether focus must be set beforehand, and what the call returns (success text? verification result?) remain unaddressed.

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?

Coverage is 67%: only 'text' is documented in the schema, while 'verify' has no description anywhere and 'verifyRegion' is explained only in the schema. The description adds no parameter meaning at all — notably it never mentions that verification (likely a screenshot comparison) can be requested, which is a meaningful behavioral toggle for the caller.

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 (type text) and target (current focus), plus a notable capability constraint (Chinese/Unicode supported). It implicitly separates itself from key-press typing via the Ctrl+V mechanism, but never names desktop_key or desktop_cdp_type, so an agent must still infer the boundary with the browser typing sibling.

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 only implied: 'types into the currently focused window' suggests the agent should focus a window first (desktop_focus_window) but doesn't say so, and there is no guidance on when to prefer desktop_key for shortcuts or desktop_cdp_type for browser fields. No explicit exclusions or alternatives are given.

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. It discloses that the operation clears the timeline and window index, which identifies the destructive scope. However, it does not state whether the clearing is irreversible, what permissions are required, or how it affects related memory tools.

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 front-loaded sentence with no filler. It is efficient, though extremely terse for a destructive operation.

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 description identifies the memory layer and the two targets being cleared, which is the minimum needed to understand the operation. Because there are no annotations and no output schema, it should do more to warn about irreversibility, impact on related memory data, or preconditions.

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 in the description. The empty schema is consistent with the description, and no additional parameter explanation is needed.

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 ('时间线与窗口索引') within the memory layer, so the tool's action is clear. It does not explicitly name or contrast with sibling tools such as memory_timeline or memory_stats, but the destructive clear action is distinguishable.

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 use this tool versus alternatives like memory_recall, memory_timeline, or memory_stats. It also does not state prerequisites, warnings, or conditions under which clearing should be avoided.

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 adds real behavioral context — returns window-center coordinates usable directly by desktop_click, and will resolve down to individual controls for element references. It does not disclose what happens on a miss, how ambiguity is resolved, or whether the memory persists across sessions.

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 purpose, then supported by concrete examples and the downstream consumer (desktop_click). Every line carries information; 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?

There is no output schema, so the description should fully pin down the return shape. It says 'window center coordinates' but is ambiguous about what element-level hits return (element coordinates? a handle?) and gives no failure-mode behavior, leaving a gap for a tool whose whole job is producing a value the agent then feeds to desktop_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?

Only one parameter with 100% schema description coverage, so the schema already documents 'query'. The description's examples largely duplicate the schema's example string, adding only the element-level variant ('that button just now'). Baseline 3 is correct.

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: resolve a natural-language reference phrase into clickable window/element coordinates, with two named resolution modes (window-level and element-level). This is enough to separate it from memory_clear/memory_timeline/memory_stats, though it never names those siblings 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 examples ('just now that window', 'that button just now') imply the usage context: when the agent has a vague pronoun-style reference rather than a precise handle. However, there is no explicit guidance on when to prefer desktop_list_windows, desktop_elements, or desktop_focus_window instead, and no stated preconditions.

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 exist, so the description carries the full burden. '查看' implies a non-mutating read and the sentence does disclose what information comes back, but it says nothing about cost, whether the index can be empty, or how the numbers should be interpreted.

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 short sentence with the resource ('记忆层') front-loaded and the returned values listed immediately after. Nothing is padded or 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?

With no output schema, the description must say what comes back, and it does (index size, last update time). Given a zero-param, low-complexity tool this is close to sufficient; only the meaning of 'index' and its relation to memory_recall/memory_timeline is left implicit.

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 baseline for a no-param tool applies.

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 ('查看' / inspect) plus the exact data returned: index size and last-updated time. This makes it clearly a stats/inspection tool, distinguishable in spirit from memory_recall and memory_timeline, 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?

Usage is only implied: an agent can infer this is the 'check memory health/scale' call before or after memory_recall/memory_timeline, but the description never states when to prefer it or what it does not cover. No exclusions or alternatives are given.

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 content categories of the timeline, which is genuinely useful, and '查看' implies a read-only operation, but it never states ordering, retention window, or whether results are newest-first — traits an agent needs to interpret the output.

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 short sentence with the resource front-loaded and the category list parenthetical and compact. No waste, though the brevity leaves the gaps noted elsewhere.

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 one-optional-parameter read tool this is nearly adequate, but with no output schema and no annotations the description should say something about the shape of a timeline entry (timestamp? ordering?) — it only names the event categories, leaving the return format to inference.

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% ('返回条数，默认 20'), so the single optional parameter is fully documented in structured data. The description adds no additional meaning about how limit interacts with the timeline, so the baseline of 3 applies.

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 ('查看' / view) and resource ('最近的操作时间线' / recent operation timeline), and enumerates the event categories it contains (perceive/click/type/command). This distinguishes it reasonably well from memory_stats and memory_clear, though it never explicitly contrasts with memory_recall.

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 only implied by '最近' (recent) and the event-type list; there is no explicit statement of when to reach for this over memory_recall or memory_stats, nor any exclusion. An agent can infer it is the chronological-view option, but must guess.

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 bears the full burden. It does disclose the key non-obvious behavior—the change is persistent and affects later shell_exec calls in the session—but says nothing about failure behavior for a nonexistent path, sandbox/permission restrictions, or whether running commands are affected.

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?

One short sentence that front-loads the action and appends only the consequence that matters, with zero redundant text.

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 one-parameter, no-output tool with full schema coverage, the description plus schema is nearly sufficient: the agent knows what is mutated and the scope of the effect. Missing only error/prerequisite behavior for an invalid path.

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% and the single path parameter is documented as 目标目录路径, so the schema already carries parameter meaning. The description adds no format details (absolute vs relative, home expansion) beyond the schema, so the baseline of 3 applies.

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 uses a specific verb (修改/cd) and resource (持久化会话的工作目录) and states the downstream effect on shell_exec, which distinguishes it from the read-only sibling shell_cwd. It does not name the sibling explicitly, so differentiation requires the agent to infer it from the read/write contrast.

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 clear usage context: call this before running commands so that subsequent shell_exec invocations land in the new directory. There are no exclusions or explicit alternatives, for example pointing to shell_cwd for reading the current path instead of mutating it.

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 burden. It implies a harmless read via '获取' and clarifies that the directory belongs to the persistent session rather than a transient one, but it says nothing about what happens if no session exists yet, whether a session is implicitly created, or the return form.

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 no filler and the key scope qualifier ('persistent session') placed before the noun it modifies. Appropriately sized for a trivial getter, though it is arguably too terse to carry the missing behavioral detail.

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 getter with no output schema, the description covers the essential. It does not say what is returned (a path string?) or whether the call fails when no persistent session has been established, which an agent needs to know before relying on it.

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 schema is trivially complete and there is nothing for the description to disambiguate. Baseline of 4 applies.

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: retrieves the current working directory, scoped to the persistent session. That scope wording implicitly separates it from shell_cd and shell_exec, though it never names them 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?

No guidance on when to call this versus shell_cd or shell_exec — e.g. checking the cwd before issuing relative-path commands, or verifying the effect of a shell_cd. The use case is only inferable from the name and the word 'persistent session'.

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 disclosure burden, and it contributes only the persistence scope. It says nothing about behavior for a missing variable (error vs empty/null), whether values are inherited from the OS environment, or whether the value is evaluated/expanded.

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 short sentence with the resource and the scoping qualifier front-loaded; nothing redundant or 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?

For a one-parameter getter with full schema coverage and no output schema, the definition covers what is needed to invoke it correctly. The main omission is missing-variable behavior, which keeps it short of 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% — the single 'name' parameter is already documented as '环境变量名' — so the baseline of 3 applies. The description adds only the notion of a persistent session, not format, case sensitivity, or lookup rules for the parameter.

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 ('获取...环境变量值') plus the scope ('持久化会话中'), so the agent knows this reads a stored variable rather than executing a command. It does not name the complementary sibling shell_env_set, but the read/write split is inferable from the names.

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 only implied: the phrase '持久化会话中' hints that this retrieves variables previously persisted (e.g. via shell_env_set) rather than live shell state. There is no explicit when-to-use or when-to-prefer-shell_exec guidance and no note about what happens if the variable is unset.

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. It usefully discloses that the variable persists and is visible to later shell_exec calls, but it omits whether existing variables are overwritten, how long persistence lasts, and what the call returns.

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 short sentences are tightly front-loaded: first the action and context, then the observable effect. 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?

For a simple two-parameter mutation tool with full schema coverage and no output schema, the description is nearly complete. It could be improved by mentioning overwrite behavior or return value, but the core behavior is clear.

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 are already documented as the environment variable name and value. The description adds no additional parameter-level semantics beyond the schema 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: setting an environment variable in a persistent session. It also clarifies the effect that later shell_exec calls can read it, though it does not explicitly distinguish this from shell_env_get or shell_reset.

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 statement that subsequent shell_exec calls will see the variable, but the description does not explicitly say when to use this instead of alternatives such as shell_env_get or shell_reset.

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?

Since no annotations were provided, the description must carry the full burden of behavioral disclosure. It highlights the 'core innovation'—that the Shell process is long-lived and maintains state (directory location, environment variables, and virtual environment status), which is the most critical behavior to understand for this 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?

The description is slightly longer than necessary but uses excellent structure. It follows a logical flow: general definition -> core benefit -> concrete effects -> application scenarios, ensuring all necessary value 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?

For a long-lived shell process, the description is maximally complete. It clearly states that state is retained after execution, which is the primary operational characteristic an AI agent needs to select this tool over a standard executor.

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?

Given that schema description coverage is 100%, the description adds functional meaning without needing to define the parameters. It does not elaborate on the syntax or complex constraints of 'command' or 'timeout' beyond what the schema implies.

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 purpose is highly specific: executing commands within a *persistent* PowerShell session. It clearly defines the resource (PowerShell session) and the action (executing commands), effectively distinguishing it from non-persistent execution tools.

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 tool explicitly outlines the ideal use cases: scenarios requiring continuous interaction, such as navigating directories and then listing contents ('cd' followed by 'git status'). This prevents misuse in one-off command contexts.

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 present the description carries the full load, and it delivers the key traits: this is a mutating executor that re-checks state via a separate filesystem API, retries failures with exponential backoff (default count in schema), and honors a per-command timeout. What it omits is the terminal-failure path — what the agent gets back if all retries exhaust — and any permission/safety framing.

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 tight sentences: the core mechanism comes first, then the rationale, then the assertion vocabulary. The trailing key list is dense but functional. Little wasted text, though the expect enumeration reads as a raw spec dump rather than prose.

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 a nested `expect` object and no output schema, the description covers the input and retry semantics adequately but says nothing about the returned result — whether the agent gets a pass/fail verdict, which assertion failed, or the command's stdout. That is a meaningful omission when there is no output schema to fall back on.

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 already 100%, so 3 is the floor; the description earns above that by enumerating the valid `expect` keys (pathExists, pathNotExists, isDir, isFile, fileContains:[path,content], cwd) and the shape of fileContains, which the schema only hints at with one example. It doesn't explain the retry semantics of `retries` or the timeout unit context beyond what the schema states.

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 mechanism: run a command, then independently verify the outcome through the filesystem API, with retries on verification failure. The 'mkdir → confirm the directory exists' example makes the intent concrete. It does not explicitly contrast itself with the sibling shell_exec, which keeps it 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?

'Don't trust the command's own return value' implies when to reach for this over a plain executor, and the expect-key list defines the required usage precondition. However, it never names shell_exec as the lightweight alternative or says when verification is unnecessary, so routing is inferred rather than stated.

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 exist, so the description carries the full disclosure burden. '重置持久化会话（重新启动 PowerShell）' does convey that a restart occurs, letting an agent infer that in-session state (cwd, env vars) is lost, but it never states this side effect explicitly or confirms what remains after reset.

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 short sentences with zero waste: the action first, then the recovery condition. Nothing to trim.

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-param, no-output-schema utility, the description covers what it does and when to reach for it. The only gap is the unspecified collateral effect on cwd/env state, which matters given the shell_* sibling set.

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 and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless 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?

Names a specific verb+resource ('重置持久化会话') and clarifies the concrete mechanism (restarting PowerShell), so an agent knows this tears down and restarts the shell session. It is distinguishable from siblings like shell_exec/shell_cwd, though it doesn't explicitly contrast with 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?

'用于会话状态异常时恢复' gives one clear trigger condition (abnormal session state), which is reasonable guidance. However, it names no alternative or exclusion — e.g., whether to prefer shell_cd/shell_env_set for smaller fixes before a full reset.

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