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

With no annotations, the description fully carries behavioral disclosure. It precisely states that the window is never raised, the cursor never moves, which UIA/Win32 mechanisms are used, what response fields are reported, and how focus_guard behaves when a provider steals foreground. This is exemplary transparency for a mutation tool with no annotation safety hints.

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

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

The description is dense but front-loaded: the purpose is stated first, followed by behavior, caveats, and retry guidance. Every sentence carries technical value, though the length is considerable and the closing compatibility note about 'background=true' slightly repeats information already given earlier.

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 10-parameter tool with no output schema and no annotations, the description covers a lot: response reporting, visible-change verification, hidden-desktop support, and foreground restoration. It is still missing guidance on the 'mode' parameter and the intended meaning of 'text' versus 'text_input', which an agent would need to select the right arguments confidently.

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 description adds meaningful semantics beyond the schema: name|role identification, window anchoring, background default behavior, and the effect of type/click mechanisms. However, the 'mode' parameter's enumerated values (instant/deliberate/instant_only) and the 'text'/'description' parameters remain unexplained despite only 50% schema coverage, so compensation is strong but incomplete.

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 opens with a specific verb+resource: 'Find an element and act on it in one call,' making the combined find-and-act behavior immediately clear. It also distinguishes the tool from siblings like ghost_find and ghost_see by emphasizing the one-call action model and the background/covered-window capability.

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 conveys when to use ghost_act: when the target window may be covered, hidden, or on a Chromium/Electron desktop page. It also gives an explicit fallback instruction: 'verified=false ... ghost_see before retrying.' It does not enumerate exclusions or contrast directly with ghost_tab_* tools, but the context is clear enough for selection.

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

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

With no annotations provided, the description carries the full behavioral burden and does meaningfully disclose two critical traits: assertion failure is an error, and text predicates OCR a specific anchored window 'by handle, never the foreground.' The foreground/window fallback rule ('Only without a window/anchor') further clarifies targeting behavior, which is exactly the kind of context an agent needs.

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 tightly packed sentences, each earning its place: core purpose, failure behavior, predicate taxonomy, and the value-check semantic. The front-loaded failure mode and the compact slash-notation for predicate groups make it dense but highly scannable 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?

For a six-parameter tool with no annotations and no output schema, the description covers the most important operational gaps: failure semantics, OCR window anchoring, and predicate-to-parameter relationships. Minor omissions remain — the success return value is never stated, and element matching via name/role is left to the schema — but these are secondary for a verification tool whose core contract (pass/fail-with-error) is explicit.

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 83%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it maps each predicate enum value to its semantic ('text-present/text-absent: OCR text check', 'element-exists: element found') and clarifies that value-equals/value-contains compare the element's actual ValuePattern against 'text' as a 'fill-then-verify check.' This clarifies how predicate and text interrelate in a way the schema's per-field descriptions do not.

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 ('Assert a predicate about screen state') and immediately distinguishes itself from observation siblings like ghost_see/ghost_find/ghost_query by the failure semantics: 'Fails (error) if not satisfied.' The predicate taxonomy (text-present/absent, element-exists, value-equals/contains) fully enumerates the tool's scope, leaving no ambiguity about what it 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?

Per-predicate usage is implied through the compact labels ('OCR text check', 'element found', 'fill-then-verify check'), which give an agent a sense of when each mode applies. However, there is no explicit guidance on when to choose ghost_assert over sibling verification alternatives such as ghost_see, ghost_find, or ghost_wait, nor any stated 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 provided, the description carries the full behavioral burden and handles it well. It discloses that Ghost never closes a browser it did not start and that it drives background tabs without switching the user's active tab, which are important side-effect guarantees for an agent.

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

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

The description is two tight sentences with no wasted words. The core action is front-loaded, the use case is in a parenthetical, and the behavioral caveats are compactly appended.

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-complexity attach operation, the description covers the required invocation detail, the target use case, and key behavioral guarantees. It is not a 5 because the optional 'id' parameter remains undocumented and there is no mention of return behavior or failure conditions.

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 description clarifies that 'port' is the value from --remote-debugging-port=<port>, which directly aids invocation. However, the optional 'id' parameter is not explained at all, and schema description coverage is 0%, leaving a meaningful semantic gap.

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

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

The description states a specific action ('Attach') and a precise resource: a browser already running with --remote-debugging-port=<port>. It also names the intended use case ('the user's own logged-in browser'), which clearly distinguishes this tool from launching or closing browsers.

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 explicitly frames when to use the tool: for an already-running remote-debugging browser and for the user's own logged-in browser. It does not explicitly name an alternative tool or list exclusions, so it falls just short of full 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 must carry the behavioral disclosure burden. It does add meaningful nuance by explaining that launched ghosts are closed while attached ones are only disconnected. Yet it omits important behavior such as what happens to the browser process, whether the operation is destructive, and what the effect of omitting the id parameter is.

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 no filler, and the most important distinction is placed in a clear parenthetical. It is appropriately sized for a simple tool with one parameter.

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 the tool's simple surface, the description is incomplete for reliable invocation: the only parameter is completely unexplained, and the effect of the operation on the browser ghost or attached browser is only partially clarified. A few more details about the expected id and lifecycle behavior would be needed for the tool to be self-sufficient.

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 schema defines a single 'id' property with no description, and schema description coverage is 0%. The description never mentions the parameter or its role, so an agent cannot tell what value to pass, whether it is required in practice, or what omitting it means.

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 action ('Close') and resource ('a browser ghost launched'), and the parenthetical distinguishes this from attached browsers. This clearly differentiates the tool from attachment-related siblings without needing to open the 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?

The phrase 'attached browsers are only disconnected' implies this tool should be used only for launched browser ghosts and not attached ones. However, it does not explicitly name an alternative tool or provide a clear decision rule for when to use this versus attach/disconnect flows.

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

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

With no annotations provided, the description carries the full burden, and it delivers rich behavioral context: per-id process/profile/DevTools isolation, concurrent processes never colliding, windowed mode running on a hidden desktop that never takes focus, and explicit warning that a new Chromium window takes foreground on creation. These are exactly the behavioral traits an agent needs to anticipate side effects.

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

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

The description is dense but every sentence earns its place: purpose first, then isolation guarantees, then parameter defaults, then safety caveats, then interaction model. It is front-loaded with the core action and avoids filler, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and no annotations, the description covers the key operational concerns: isolation semantics, browser and mode defaults, when windowed mode is appropriate, desktop safety, and how tabs should subsequently be driven. Nothing critical is missing for an agent to invoke and use the tool correctly.

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

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

Schema description coverage is only 33%, but the description substantially compensates by explaining the mode enum values ('headless' invisible/default, 'windowed' real window on hidden desktop), listing the browser enum values, and stating the default behavior ('first installed'). It also enriches 'id' by explaining that each id gets its own process, profile, and DevTools port.

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 ('Launch') and resource ('isolated browser for background automation'), and clearly distinguishes itself from ghost_browser_attach by emphasizing that each call creates its own process, profile, and DevTools port. The scope is unmistakable and the tool cannot be confused with its siblings.

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

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

The description gives explicit usage guidance: headless is the default, windowed should be used 'only for sites that behave differently headless,' and tabs should be driven via ghost_tab_* without focusing the window. However, it does not explicitly name ghost_browser_attach as the alternative when an existing browser should be controlled, leaving that comparison implicit.

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 of behavioral disclosure. It clearly indicates this is a read-only listing operation and scopes it to Chromium-family browsers, but it does not mention output format, sorting, paths, or any edge cases around detection, which would be useful for a no-annotation 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 a single, front-loaded sentence that immediately identifies the action, resource, and scope. Every phrase earns its place, with the example browsers adding useful specificity without bloat.

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 discovery tool, the description is nearly complete: it tells the agent what will be listed and the scope of what counts as installed. Since there is no output schema, it could have clarified the exact return shape or data type, but this is a minor omission for such a straightforward operation.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to compensate for. The baseline score of 4 applies here because the description accurately reflects that the tool requires no inputs.

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 ('List'), a clear resource ('Chromium-family browsers installed on this machine'), and gives concrete examples. This distinguishes it from sibling browser tools like ghost_browser_launch and ghost_browser_attach without needing to inspect their 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?

The phrase 'installed on this machine' implies this tool is used for discovery, likely before launching or attaching to a browser. However, it does not explicitly state when to use it versus alternatives or mention that it should be used before other browser operations.

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?

There are no annotations, so the description carries the behavioral burden. 'List' clearly signals a read-only operation, and 'open tabs' plus the output fields define what the agent can expect. It does not discuss optional-id behavior or assumptions like an active browser, but for a simple listing tool the core behavior is transparent enough.

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. Every part adds information about what the tool lists and what it returns.

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 the no-argument call, the description is sufficient: list all open tabs and return their ids, titles, and URLs. However, because there is no output schema, no annotations, and the optional `id` parameter is completely undocumented, the description is not fully complete for an agent that needs to understand all invocation variants.

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 schema provides only a string `id` with no description, and schema description coverage is 0%. The tool description never explains what `id` means or how it affects the listing, so the agent cannot determine whether passing `id` filters, selects, or targets a specific tab. The phrase 'target ids' refers to output fields, not 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?

The description uses the specific verb 'List' against the resource 'open tabs' and enumerates the returned fields: target ids, titles, and URLs. This makes the tool's purpose unambiguous and distinguishes it from single-tab action tools like ghost_tab_find, ghost_tab_describe, and ghost_tab_close.

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 clearly indicates this is the tool to call when the agent needs to enumerate open tabs. It provides enough context for the primary use case, though it does not explicitly mention when not to use it or name alternatives such as ghost_tab_find.

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 behavioral disclosure burden. It discloses the core behavior: get reads clipboard text and set writes text, with get as the default op. It does not detail side effects such as overwriting existing clipboard contents or whether get returns plain text only, but for a simple clipboard tool the disclosure is reasonably adequate.

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 extremely compact, using a clear shorthand format and front-loading the key concept. Every word earns its place, and the default op is stated clearly without unnecessary elaboration.

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 tool with two parameters and full schema coverage, the description is largely sufficient. It covers both operations and the default. It does not explicitly state what get returns, though 'read text' implies the clipboard text, and it omits any note about platform limitations, but these are minor for this tool's simplicity.

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 schema already documents both parameters with 100% coverage, including the enum values and their meanings. The description adds little beyond restating that op=get reads and op=set writes, with get as default. This matches the baseline for a fully schema-documented 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?

The description explicitly states the resource ('clipboard') and the two supported operations with verbs: 'read text' and 'write text'. It is immediately clear what the tool does and the clipboard domain distinguishes it from all listed sibling tools, which concern tabs, browsing, and other actions.

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

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

The description explains the op modes and the default behavior, so an agent knows how to request read versus write. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusion criteria. Usage context is implied rather than fully 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 provided, the description carries the full burden of behavioral disclosure. It explains the sequence (click-hold, move, release) and the important semantic detail that elements are resolved to their center. It does not cover coordinate system, duration, or failure behavior, but the core mechanics are transparent.

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 focused sentence that front-loads the gesture, immediately explains the two endpoint modes, and provides illustrative examples. Every clause 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 drag tool with 8 optional parameters, no annotations, and no output schema, the description covers the essential semantics: what qualifies as an endpoint and how element endpoints are resolved. Minor gaps remain, such as coordinate space and whether start/end must both be present, but the examples and mode explanation make the tool usable.

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%, so the description adds meaningful context by explaining that endpoints can be either raw coordinates (from_x/from_y, to_x/to_y) or elements (from_name/from_role, to_name/to_role) resolved to center. This clarifies how the eight optional parameters group together, though it does not specify units or required combinations.

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 names a specific action (click-hold, move, release = drag) and clearly identifies the resource (start and end points). It distinguishes this from siblings like ghost_tab_click or ghost_tab_scroll by describing the drag gesture and giving concrete examples.

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's usage context is clear: use it when an interaction requires dragging between two endpoints. It provides examples such as dragging a list row onto another or a slider handle. It does not explicitly contrast with alternatives or state when not to use it, but the behavior is distinct enough that the guidance is sufficient.

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, this description carries the full behavioral burden and meets it: it discloses that center is always returned, rect is conditional on UIA/cache hits, escalated signals a paid VLM call, and the default policy never focuses or raises the target window. It also reveals that the lookup works on covered or hidden-desktop windows, which is non-obvious and important.

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

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

The description is dense but each sentence earns its place: return contract, target-window precedence, and background policy. It is front-loaded with the core action and outputs and avoids 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?

The description covers the essential return fields, scoping, and side-effect-free background behavior for a 7-parameter tool with no output schema. It stops short of fully complete by not stating failure/not-found behavior or making explicit that a locator parameter is expected despite all params being optional.

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 adds a little extra meaning by grouping locator strategies and clarifying the window= anchoring hierarchy, but it does not substantially extend what the schema already documents.

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 opens with a precise verb and resource: 'Locate an element' using name/role/description/text, and states the return contract. The mention of 'UIA subtree', window anchoring, and hidden desktops clearly separates this from browser/tab-based siblings such as ghost_tab_find.

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

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

It gives useful context about target-window precedence and background behavior, implying it is for non-raising desktop UI lookups. It does not explicitly state when to prefer this over ghost_see, ghost_snapshot, or ghost_tab_find, nor does it list exclusions.

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 disclosure burden. It usefully reveals the operation (GET) and the exact return shape, but it does not disclose potential side effects, authentication needs, redirect/timeout behavior, or error handling. This is adequate but minimal.

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 sentence with zero filler. It front-loads the core action and immediately provides the return format, making it efficient for an agent to parse.

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 covers the essential action and return shape, which is useful given there is no output schema. However, it omits guidance on the headers parameter, usage versus ghost_http_post, and failure/error behavior, leaving noticeable gaps for an agent selecting and invoking the tool.

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

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

Schema description coverage is 0%, so the description must compensate, but it adds no meaning to the 'url' and 'headers' parameters. The agent is left to infer from the parameter names that 'url' is the request target and 'headers' is an object of HTTP headers, which is not explicitly confirmed.

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 operation, 'HTTP GET', and explicitly defines the return contract as '{status, body}'. This clearly distinguishes it from the sibling ghost_http_post and other tab/browser tools without requiring the agent to open the 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention that ghost_http_post should be used for POST requests, nor does it provide any context about when an HTTP GET is appropriate or inappropriate.

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 full responsibility for behavioral disclosure. It only reveals that an HTTP POST is performed and that a {status, body} object is returned. It does not describe side effects, error behavior, redirect handling, authentication, or security implications of making arbitrary external requests, which is a significant transparency gap for a network 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 extremely compact: two short sentences with no filler words. The core operation is front-loaded, and the return shape is stated efficiently. However, its brevity is partly a consequence of under-specification rather than deliberate compression of rich content, so it earns a 4 rather than 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?

For a tool with 4 parameters, no output schema, and no annotations, this description is insufficiently complete. It omits how parameters map to the HTTP request, what the `status` and `body` values look like, and any defaults for `content_type` or encoding. The presence of many sibling tools adds pressure to provide routing context, which is absent.

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

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

Schema description coverage is 0%, and the description provides zero parameter-level information. It does not clarify how `body`, `headers`, `content_type`, or `url` are used, leaving the agent to guess whether the body should be JSON-encoded, how headers are formatted, or what content types are accepted. The description completely fails to compensate for the schema's lack of descriptions.

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 action ('HTTP POST') and the resource being acted on (an HTTP endpoint), and it clearly distinguishes itself from the sibling ghost_http_get by naming the HTTP method. However, it could be more explicit that it sends a request to the provided URL and that `url` is the target, so it stops just short of a 5.

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

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

There is no guidance about when to use this tool versus alternatives such as ghost_http_get, nor any mention of typical use cases (e.g., submitting form data, calling an API) or exclusions. The verb 'POST' implies a use case but leaves all contextual decision-making to the agent.

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?

Despite no annotations, the description discloses the default background posting behavior, the supported key classes including semantic messages for editing shortcuts, the error for unsupported modifier combos, and the fallback when no anchor/window is set. This covers the agent's key decision points for side effects and limitations.

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?

Five dense sentences with zero fluff; the headline behavior is front-loaded, then supported details, then alternatives. Every sentence adds information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a key-sending tool with policy modes and anchoring rules, the description covers default behavior, limitations, alternatives, and fallback. It doesn't describe return values or error format, but the output schema is absent and the behavior around errors is at least mentioned ('error naming the alternative').

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?

Input schema already covers all three parameters (100%), so baseline is 3. Description adds meaningful nuance: 'window' anchors by title substring and omitting it falls back to session anchor or human foreground window; 'background' is a compatibility flag since posting is already default. This goes 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 action ('Send a key to a window') and a critical differentiator ('WITHOUT focusing it'), and clarifies target resolution via 'window=' or session anchor. Names a sibling (ghost_act) as alternative, so it stands apart.

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 recommends ghost_act action=type for text, warns that other modifier combos have no background path and will error naming the alternative, and states hold/release exist only under foreground policy. This gives the agent clear conditions for selecting this tool over alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the two-stage strategy (UIA name-matching first, then a single batched VLM call) and the exact return fields. It does not mention failure modes, cost, or side effects, but for a read-style extraction tool the disclosed strategy is substantial.

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 three compact sentences with the purpose front-loaded, followed by the extraction strategy and return value summary. Every sentence earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema and no annotations, the description usefully explains what the tool returns and how it operates. It is missing a brief explanation of the 'UIA name-matching' approach and edge-case behavior, but for a 3-parameter, zero-required-parameter tool it is largely sufficient.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning to the parameters beyond what the schema already says; it only indirectly references the schema fields via 'fields still unmatched.'

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 action ('Extract structured data') and a clear target ('from the screen'), and also names the returned information. It is not a tautology and is more specific than the tool name. It does not explicitly contrast with sibling extraction/vision tools like ghost_see or ghost_find, 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?

The intended use is implied: call this when you need structured data from the screen. However, there is no explicit guidance about when not to use it or which sibling tool to prefer for related tasks, such as ghost_see, ghost_snapshot, or ghost_tab_describe.

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 of behavioral disclosure. It clearly states the core state transition: clearing the stop flag and resuming automation. It omits edge cases such as behavior when no stop flag is set, but for a zero-parameter tool this is a minor gap.

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

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

Two short sentences, front-loaded with the primary effect and no wasted words. Every sentence contributes meaningful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter state-reset tool with no output schema, the description provides sufficient context: when to use it and what it does. There are no hidden inputs or complex return values an agent would need explained.

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

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

The tool has zero parameters, so the description does not need to document parameter meaning. The baseline score of 4 applies because there is no parameter information to add.

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 action ('Resume automation') and a specific resource ('after ghost_stop'), and explicitly mentions clearing the stop flag. This clearly differentiates it from sibling tools like ghost_stop and other ghost_* operations.

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 an explicit condition for use: after ghost_stop. It does not list alternatives or exclusions, but the direct pairing with ghost_stop makes the usage context clear enough for an agent.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It discloses retry behavior tied to max_retries, chaining substitution semantics, type preservation, window-following behavior across title changes, stale-title resolution, title_drift in responses, and the cost of fixed sleeps.

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

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

The description is dense but every sentence earns its place. It front-loads the primary purpose, uses clear CHAINING and SPEED sections, and includes a concrete example. No filler or repetition exists.

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 complex orchestration tool with no annotations and no output schema, the description is exceptionally complete. It covers step semantics, chaining, type behavior, window anchoring, retries, and wait guidance, giving an agent enough context to invoke it correctly and interpret key response behavior like title_drift.

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 60%, and the description compensates by explaining the steps format, the meaning of ${steps.N.path} references, and the effect of max_retries. However, it does not add much detail about json_flow, script vs json_flow differences, or stop_on_error behavior beyond what the schema already provides.

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

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

States a specific operation: executing a declarative step-by-step flow in one round-trip, with each step being an {op, ...params} invocation. This clearly distinguishes it from the many single-step sibling tools by emphasizing orchestration and batching.

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?

Clearly conveys when to use the tool: when multiple steps should run together in one round-trip. It also gives explicit guidance to use ghost_wait with 'for' instead of a fixed sleep. It does not explicitly say 'use a single sibling tool for one action', but the intended usage is strongly implied.

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 — and it delivers richly: captures BY HANDLE (works while covered, on a hidden desktop, or via CDP for a routed browser), default output is max 768px JPEG q=75 (~20-100KB), foreground fallback only when no anchor exists, and 'Always includes size_bytes.' This discloses capture mechanics, output format, size, and return guarantees far beyond the bare schema.

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?

Dense but purposeful — every clause contributes (targeting, capture mechanism, output format, fallback, crop modes, full-screen mode, PNG mode, size_bytes), and the logical flow from purpose to target to mechanism to options is sound. It is a long single paragraph, but with 8 parameters and zero annotations, the information density is warranted rather than 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?

Remarkably complete for an 8-param tool with no annotations and no output schema: targeting rules, handle-based capture behavior, output formats, crop modes, and fallbacks are all specified. The one notable gap is the return payload shape — with no output schema, the agent knows only that it 'Always includes size_bytes' but not whether the result is a file path, base64 data, or an object.

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 88% (7 of 8 params described), so the baseline is 3. The description adds only marginal value beyond the schema: the VLM-in-the-loop use case for rect, the 'ONE element inside the target' clarifier for name/role, and indirect jpeg_quality context via 'q=75.' No parameter gains substantial new meaning from the description.

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 pair ('Capture a screenshot of the window the agent is working in') with concrete scope. The handle-based capture mechanism, element-cropping modes, and full-screen option clearly carve out a distinct niche versus siblings like ghost_tab_screenshot (tab-level capture) and ghost_see/ghost_snapshot (likely vision/analysis), even without naming 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?

Provides clear within-tool routing: when to pass name/role vs rect, when to use full=true, and the exact fallback condition ('Only with no anchor does it fall back to the foreground window'). However, it never names sibling alternatives or states when to choose this over ghost_tab_screenshot, ghost_see, or ghost_snapshot, so cross-tool selection is left largely to inference despite a crowded sibling family.

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

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

With no annotations provided, the description carries the full behavioral burden and delivers detailed context: the wheel is POSTED to the target window, the pointer never moves, the window is never raised, covered and hidden-desktop windows work, and coord mode needs a foreground policy. This is substantial and actionable beyond what the schema provides.

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

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

The description is dense and front-loaded, with every clause contributing information about a mode or constraint. It is appropriately sized for an 8-parameter tool, though the semicolon-heavy, run-on middle sentence is harder to parse than a more structured breakdown would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the absence of an output schema, the description covers target selection, modes, defaults, and background behavior thoroughly. The main gap is that it only specifies the return value for 'until' mode ('returns found') and does not state what a normal scroll returns or how errors/edge cases surface.

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

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

The description adds meaning to nearly every parameter despite only 50% schema coverage: amount is in notches with default 3, window anchors the target or falls back to the session anchor, x/y are coordinate-mode values at the real pointer, and until_name/until_role/max_scrolls define the 'until' mode semantics. This meaningfully compensates for the schema's sparse coverage.

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

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

The description clearly names the action (Scroll) and the target resource (a window via 'window=' or the session anchor), and enumerates directions and modes. It is distinct enough to be understood, but it does not explicitly differentiate itself from sibling tools like ghost_tab_scroll, leaving some sibling comparison to inference.

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 context for when each mode applies: background-window scrolling under the default background policy, coord mode requiring a foreground policy, and 'until' mode for repeated scrolling until an element appears. It does not explicitly state when not to use this tool or name alternatives, so the when-not guidance is implied rather than explicit.

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—and it delivers. It discloses that the tool 'Never focuses or raises anything', how session anchoring works, what happens when neither window nor anchor is provided, coverage of hidden-desktop windows, and hard caps on elements and text.

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

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

The description is dense but every clause earns its place: target resolution, no-focus guarantee, per-mode semantics, and limits. It is front-loaded with the core purpose and preserves a clear structure through semicolon-separated mode explanations, making it efficient for a tool with six parameters and multiple modes.

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 and no annotations, the description must cover return shape and side-effect behavior itself. It states the element shape, target source reporting, mode-specific outputs like 'SoM debug image' and 'selected text', plus caps for elements and text. This is sufficient for an agent to invoke the tool correctly across all modes.

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 adds meaningful extras beyond the schema: window= 'becomes the session anchor', mode=full is the default when a window is targeted, fast is only for the foreground quick path, and text is positioned as the cheapest read path. These details improve parameter selection beyond the schema alone.

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

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

The opening sentence states a specific verb and resource: 'Describe a window's UI as elements {name, role, rect}.' This clearly sets it apart from sibling tab-focused or action-oriented tools, and the target/window semantics solidify what object the tool operates on.

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

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

The description gives explicit guidance on when each mode applies, e.g., 'full (default whenever a window is targeted)', 'fast (foreground-only quick path, used only when nothing is targeted)', and 'text (READ the visible text - the cheapest way to read content)'. It stops short of explicitly contrasting this tool with sibling tools like ghost_find or ghost_tab_describe, but the mode-level usage 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 provided, the description carries the full behavioral burden and meets it: merged stdout+stderr with a 24000-char tail cap, timeout asymmetry (op=run kills the process; op=send leaves it running, drainable via op=read), persistent state across send, and the GHOST_SHELL=off kill switch. Destructive and stateful traits are all surfaced explicitly. No annotation contradiction exists because there are no annotations to contradict.

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 long but densely packed, front-loading the core purpose before the op semantics, output behavior, and escape hatch. Compact notation (op=run, shell=bash) and enumeration avoid redundancy. It could be trimmed slightly, as the Claude Code session workflow is arguably supplementary material, but every section 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 stateful six-op tool with no output schema and no annotations, this is remarkably complete: return values, timeout nuances, output caps, session lifecycle, emergency stop, and disable condition are all specified. An agent has enough information to select and invoke the tool correctly without consulting external documentation.

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%, establishing a baseline of 3. The description adds real value beyond the schema for the op parameter, which the schema merely labels 'Operation (default run)': it defines each op's semantics, return shape ({output, exit_code, timed_out} vs an 'id'), and session behavior. The remaining parameters are already well covered by their schema descriptions.

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

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

The opening sentence, 'Run shell commands and drive persistent shells,' names a specific verb and resource, and the op enum breakdown (run/open/send/read/list/kill) makes the scope unmistakable. It also enumerates concrete use cases: builds, git, CLIs, scripts, apps, and file editing. However, it never explicitly differentiates itself from the sibling ghost_run, which by name could be the one-shot variant, so sibling differentiation is implicit 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 description gives clear when-to-use context: shell work for builds, git, CLIs, scripts, and file editing on machines lacking file tools. It also names follow-on alternatives for terminal driving (ghost_see / ghost_act / ghost_key) and an emergency backstop (ghost_stop). It stops short of explicit when-not-to-use exclusions, such as preferring ghost_http_get for network calls.

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 disclosure burden. It does so well: it enumerates what is returned, defines the actionable flag precisely with the greyed-out button example, and signals a non-mutating, read-oriented operation through 'view' and 'planning view.'

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 deliver purpose, behavioral semantics, workflow guidance, and parameter summaries without wasted words. The key purpose is front-loaded, and every sentence 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 read-only inspection tool with three optional parameters and no output schema, the description covers what is returned, how actionable is computed, default window behavior, and the intended planning-then-acting workflow. No material information needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly adding 'enabled' to actionable_only's meaning beyond the schema's 'interactable' phrasing, and by tying it to noise reduction for planning. It adds little for limit beyond the schema, so it earns a 4 rather than 5.

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: it produces a structured, agent-planning view of a window's UI, listing concrete element fields and accepted actions. It also distinguishes itself from screenshots and from ghost_act by framing the tool as the 'plan here' step.

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

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

It explicitly tells the agent when to use this tool: reason over the UI cheaply before acting, then act via ghost_act by name/role. It also contrasts itself with screenshots on cost, which is a clear selection signal among the sibling tools.

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 of explaining behavior. It does so by describing that this is telemetry for debugging, listing the metrics returned, and implying a non-mutating read-only role. It stops short of explicitly stating 'no state changes' or describing the output format, but those are not hidden given the tool's zero-parameter stats nature.

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 carry all the needed information: what the tool reports, which metrics are included, and when to call it. The description is front-loaded with the core purpose and contains no filler or repeated schema content.

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-only telemetry tool, the description is nearly complete: it names the resource, metrics, and call triggers. There is no output schema, so a sentence about the return shape would fully close the last gap, but the description's explicit metric list leaves little ambiguity for correct selection and invocation.

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

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

The tool has zero parameters, so the empty input schema already exhaustively describes the parameter surface. The description adds no parameter detail, but none is needed; with 0 params this is the baseline 4 case.

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 identifies a concrete diagnostic resource — grounding and cache telemetry — and enumerates the specific metrics it exposes (which tier is winning, VLM escalation rate, cache hit/miss counts, UIA-mirror stats). This clearly distinguishes ghost_stats from the action-oriented sibling tools (ghost_tab_click, ghost_act, etc.), so an agent can tell what it is for 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?

It gives explicit trigger conditions: 'Call when a flow is slow or a find is unreliable.' This is strong usage guidance for a diagnostic tool. It does not mention alternatives or exclusions, but among the siblings there is no other stats/telemetry tool, so the context is sufficient.

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 are provided, the description carries the full behavioral disclosure burden. It transparently states both the main effect (halting all automation) and an important side effect (releasing held modifier keys). It could mention whether the browser or session is left open, but for an emergency-stop command the description is substantially transparent.

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. The 'Emergency stop' label is immediately actionable, and both behavior components are stated with minimal words.

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 tool, the description covers what it does, when it is used, and what effect to expect. It does not explicitly distinguish itself from ghost_reset, but the emergency framing plus the modifier-key release detail make the tool's role clear enough.

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

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

The tool has zero parameters, so the schema provides no parameter documentation burden. The description correctly focuses on behavior rather than explaining nonexistent inputs.

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 names a specific verb ('stop'), a clear resource ('all automation'), and a concrete side effect ('release held modifier keys'). It is immediately distinguishable from siblings like ghost_wait or ghost_reset because it is framed as an emergency halt rather than a pause or 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?

The 'Emergency stop' label explicitly establishes when this tool should be used: when automation must be halted immediately. It does not name alternatives or explicitly say when not to use it, but the emergency framing supplies sufficient usage context for a zero-parameter stop tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal meaningful traits: ~1-2ms execution, no cursor movement, trusted synthetic event, and background-tab capability. It does not disclose timeout behavior, side effects such as triggering navigation, or failure behavior when the selector is absent or non-clickable, leaving a notable transparency gap.

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

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

The description is a single compact sentence with the action front-loaded. The performance and capability details ('~1-2ms; no cursor movement; works in a tab that is not in front') are packaged efficiently with no filler. Every clause contributes useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tab-click action, the description covers the core invocation facts: target tab, CSS selector, synthetic trusted event, and background-tab support. However, with no annotations, no output schema, and 0% schema coverage, the missing timeout semantics, error behavior, and lack of alternative routing leave clear gaps. It is adequate but not fully 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 schema has 0% description coverage, so the description must compensate. It adds meaning to selector ('CSS selector') and partly to tab ('inside the tab's renderer'), but leaves browser and timeout_ms semantically unexplained. While timeout_ms is somewhat self-explanatory by name, its exact behavior is not described, so the description only partially compensates for the schema gap.

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

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

The description states a specific verb and resource: 'Click an element by CSS selector' inside the tab's renderer. It adds distinguishing mechanism details ('trusted synthetic mouse event', 'no cursor movement', 'works in a tab that is not in front') that separate it from generic click or act tools. This is clear and sibling-differentiating.

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 provides useful contextual signals, such as the click being synthetic, fast, and working in background tabs, which implies when it should be used. However, it never names alternatives or states exclusions, so an agent must infer when to prefer ghost_tab_click over ghost_act, ghost_tab_eval, or ghost_tab_press. Usage guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without noting that closing is irreversible, what happens to unsaved state, or whether confirmation is needed. The tool name and verb imply destruction, but the description does not make behavioral consequences explicit.

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 immediately conveys the operation and target. While terse, every word 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 tool with no output schema, no annotations, and zero schema description coverage, this description is too thin. It fails to explain the optional browser parameter, any side effects, or how this interacts with the tab lifecycle. An agent would likely need to infer or probe behavior to use it confidently.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It clarifies that the tab is referenced 'by id,' which maps to the required 'tab' parameter, but it does not mention the optional 'browser' parameter at all. This leaves the agent without semantic guidance for half of the input schema.

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

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

The description states a specific verb and resource: 'Close a tab by id.' This clearly distinguishes it from sibling operations like ghost_tab_open, ghost_tab_navigate, and ghost_tab_click. The scope is unambiguous for an agent selecting among many tab-related 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 description provides no guidance on when to use this tool versus alternatives, such as ghost_browser_close for closing an entire browser or ghost_reset for broader cleanup. There are no stated exclusions, prerequisites, or context cues. An agent must infer usage entirely from the tool name and sibling set.

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 behavioral disclosure burden. It discloses that the output is a structured list containing visible interactive elements, selectors, and coordinates. It does not mention side-effect safety, failure modes, or whether results are bounded by the limit parameter, but the read-only inspection nature is reasonably implied.

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 no filler. The output definition is front-loaded, followed immediately by practical usage guidance. Every sentence 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?

The tool has three parameters and no output schema, so the description needs to clarify required tab semantics and optional limit/browser behavior; it does neither. The return value is described, but the input side is too underspecified for confident invocation.

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

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

Schema description coverage is 0%, and the description adds nothing about the tab, limit, or browser parameters. An agent must guess what tab identifies and what limit caps. There is no parameter-level guidance in the description to compensate for the empty schema descriptions.

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

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

The description clearly states the tool returns a structured list of visible interactive elements with selectors and coordinates. It gives the tool a specific role: helping the agent decide what to click. It distinguishes itself from screenshot-based tools, though not from nearby tools like ghost_tab_find.

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 explicitly says to prefer this tool over screenshots when deciding what to click. This is a direct when-to-use statement with a named alternative. It does not cover when screenshots would be better, but the core usage context is clear.

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

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

The description does add one useful behavioral trait: it awaits promises before returning the value. However, there are no annotations, so the description carries the full burden, and it does not disclose potential side effects of executing arbitrary JavaScript, error behavior, serialization limits, or security implications. This is a significant gap for a code-execution tool.

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

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

The description is one tight sentence with no filler. It front-loads the core action and then adds the important promise-awaiting detail parenthetically. Every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that evaluates arbitrary JavaScript, the description is too thin. With no output schema, no annotations, and 0% parameter coverage, the agent is left without guidance on return value formats, exception handling, side effects, or parameter semantics. The promise handling is helpful but not enough for safe and correct invocation.

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

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

Schema description coverage is 0%, and the description only gives meaning to 'expression' (it is a JavaScript expression). The 'tab' and 'browser' parameters are left unexplained—no guidance on their formats, how to identify a tab, or whether browser is optional. The description does not compensate for the lack of parameter documentation.

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 ('Evaluate'), resource ('a JavaScript expression in the tab'), and outcome ('return its value'). This clearly distinguishes it from sibling tab tools like ghost_tab_navigate or ghost_tab_click, which do different operations. No ambiguity about 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 implies the tool is used when you need to run JavaScript inside a tab and get a result, but it does not explicitly state when to prefer this over alternatives such as ghost_query, ghost_run, or ghost_tab_describe. No exclusions or alternative-routing guidance is provided.

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?

There are no annotations, so the description must carry behavioral disclosure. 'Find' implies read-only, non-navigating behavior, and the substring criterion is stated. However, it does not mention what is returned on success or failure, whether matching is case-insensitive, or whether search is scoped to a specific browser.

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 12-word sentence, immediately front-loaded with the verb and resource. Every word earns its place and there are no redundant phrases.

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 tool with no annotations and no output schema, the description is incomplete: it omits the browser parameter's role and the return value or behavior when no tab matches. An agent can invoke it, but may guess at the optional parameter and result format.

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

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

Schema description coverage is 0%, so the description needed to document both parameters. It defines query as a substring for URL or title, but the optional browser parameter is left entirely unexplained; an agent cannot tell what values it accepts or what it selects.

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 names a specific verb ('Find'), a concrete resource ('a tab'), and a precise criterion ('URL or title contains a substring'). This clearly distinguishes it from page-oriented siblings like ghost_find and from navigation/action tab 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?

Use is implied: call it whenever a tab must be located by URL or title substring. There is no explicit guidance contrasting it with ghost_browser_tabs for listing tabs or ghost_find for page-level search, but the purpose statement gives enough context for basic selection.

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 disclosure burden. It meaningfully reveals that navigation happens in a background tab, does not change the user's view, and waits for load. It does not cover failure handling or timeout behavior, but the disclosed traits are significant and not inferable from the schema.

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 no filler. The core action is front-loaded, and the second sentence adds critical behavioral context without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with four parameters, no parameter descriptions, no annotations, and no output schema, the description is too thin. It omits timeout semantics, return behavior, failure conditions, and how it relates to sibling tab tools, leaving an agent to guess important invocation details.

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

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

Schema description coverage is 0%, so the description must compensate. It only implies the roles of 'tab' and 'url' through the verb 'Navigate', and says nothing about 'browser' or 'timeout_ms'. The meaning of timeout and the permissible URL format are left undocumented.

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 names a specific verb ('Navigate'), a resource ('a tab'), and a behavioral outcome ('wait for load'). It is clear and distinct from scroll/click/type siblings, though it does not explicitly distinguish itself from ghost_tab_open or ghost_act.

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 phrase 'Runs in a background tab; the user's view never changes' gives useful context, but there is no explicit guidance about when to choose this tool over alternatives such as ghost_tab_open, ghost_act, or ghost_tab_find. No exclusions or recommended 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 provided, the description carries the full behavioral burden. It openly states the key side effect (never focuses the tab/window) and the return contract (id for sibling tools). However, it omits prerequisites, such as whether a browser must already be launched, error behavior, or permissions, which would be valuable for a tool of this type.

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 that delivers the core behavior, the negative guarantee, and the output contract. Every clause earns its place; no redundant or filler wording exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two undocumented parameters, no annotations, and no output schema, the description is incomplete. It explains the purpose and return value but leaves the 'browser' parameter undefined and does not clarify preconditions (e.g., an already launched browser) or what happens if the tab cannot be opened. This is a gap an agent must resolve before invoking the tool.

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

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

The schema has 0% description coverage and the tool description does not explain either parameter. 'url' is implicitly the address to open, but 'browser' is entirely unexplained, and with 0 required parameters it is unclear what values are allowed or whether either parameter is optional. The description adds no semantic meaning beyond the parameter names.

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

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

The description precisely states the action ('Open a new background tab') and adds a critical constraint, 'never brings the tab or window to the front', which distinguishes it from navigation or foreground tab operations. It also names the resource (tab) and the output (the tab's id), making the purpose 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 makes the usage context clear: this is for creating a new tab that stays in the background, and the returned id is meant for other ghost_tab_* tools. It does not explicitly name when-not-to-use or alternatives like ghost_tab_navigate, but the context is specific enough that an agent can select this tool for background tab creation.

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 does disclose that the key is sent to the focused element and that modifiers are limited to Alt/Ctrl/Meta/Shift, which is useful. It does not explain what happens if no element is focused, whether the press also triggers default browser actions, or what the tool 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?

The description is two short sentences with no filler; the core action and examples come first, and modifiers are added as a compact second clause. Every phrase contributes useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite its concise clarity, this is not enough for a 4-parameter tool with no schema descriptions, no output schema, and no annotations. The agent is left guessing about the required tab identifier and optional browser value, as well as the return/error behavior, so the definition is not self-sufficient.

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 schema has zero descriptions, so the tool description must explain parameters. It provides semantic detail for key (with examples) and modifiers (allowed values), but leaves tab and browser underspecified—an agent still has to infer how to identify a tab or choose a browser instance.

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 the action as 'Send a key' to 'the tab's focused element,' which clearly identifies a keyboard-press operation scoped to a tab. The examples of possible keys and modifiers help an agent distinguish it from text-typing or clicking siblings like ghost_tab_type and ghost_tab_click, though it does not explicitly name those alternatives.

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 intended use is implied: use this tool when a single key press needs to be delivered to the element currently focused in a tab. However, it offers no explicit guidance on when not to use it or which sibling tool is preferred for related actions such as typing text, clicking, or scrolling.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the screenshot is rendered by the tab itself and does not require the tab to be in front or focused, addressing the most likely behavioral surprise. It also specifies PNG output, though it does not discuss side effects or whether the tab must already be loaded.

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

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

The description is a single efficient sentence that front-loads the core purpose ('PNG of a tab') and then adds the distinguishing behavioral caveat. Every word contributes meaning; there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is relatively simple, but the complete absence of parameter descriptions, combined with no output schema and no annotations, leaves notable gaps. The description adequately conveys the main operation but does not fully equip an agent to correctly set optional parameters or handle the return value beyond knowing it is a PNG.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It clarifies that 'tab' is the target of the screenshot, but it gives no meaning for 'browser' or 'full_page', leaving an agent to guess whether full_page captures the entire scrollable page and whether browser selects a specific browser instance.

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

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

The description clearly states the tool produces a PNG of a specific tab, and the key qualifier 'regardless of whether it is in front or focused' distinguishes it from general screenshot tools like ghost_screenshot. It identifies the resource (tab), the output format (PNG), and a defining behavioral characteristic in a single focused sentence.

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

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

The description implies when to use this tool: when you need a tab's visual rendering even if it is not foreground or focused. However, it does not explicitly name alternatives such as ghost_screenshot or ghost_snapshot, nor does it state when those should be preferred instead.

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 burden of behavioral disclosure, but it only restates the core action. It does not say whether scrolling is instant or animated, whether it waits for scroll completion, what happens if no scrollable element is found, or what the tool 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?

The description is a single, front-loaded sentence with no wasted words. It is concise and easy to parse, though it is too sparse to stand alone as a full behavioral specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given five parameters, no output schema, and no annotations, the description is not complete enough for reliable invocation. It lacks information about scroll semantics, parameter behavior, return values, and edge cases, which an agent would need for correct use.

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 schema has 0% description coverage, and the tool description does little to clarify the parameters. 'tab' and 'selector' are vaguely implied by 'a tab or a scrollable element inside it', but dx, dy, and browser are completely unexplained, leaving the agent to guess their meaning and defaults.

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

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

The description uses a specific verb ('Scroll') and identifies the resource: a tab or a scrollable element inside it. It is clear about the intended scope and is distinguishable from the sibling ghost_scroll by the tab-based targeting, though it does not explicitly name any 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?

No guidance is provided about when to use this tool versus alternatives such as ghost_scroll or other tab-scoped tools. There is no mention of when to target the tab versus supplying a selector, nor any exclusion criteria 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 provided, the description carries the full burden, and it does disclose the single most important behavioral trait — that input/change events fire exactly as with a real choice. However, it is silent on failure modes (invalid/missing option value, disabled or hidden select), prerequisites, and whether the operation mutates page state irreversibly.

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 16-word sentence that front-loads the core action ('Choose an option in a <select>') and appends the essential behavioral caveat about event firing. There is no filler; 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?

Given zero annotations, no output schema, and 0% schema parameter coverage, the definition is under-specified for a tool with four parameters and three required ones. An agent cannot recover what value refers to structurally (option value attribute vs. label), what selector format is expected, or how failures surface — none of that is available in any other field.

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

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

Schema description coverage is 0%, so the description must compensate. It implicitly tells an agent that selector targets a <select> element and value is the option to choose, but tab and browser receive no semantic explanation at all. With a 4-parameter tool, this partial compensation leaves real gaps.

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 names a specific verb and resource — 'Choose an option in a <select>' — and adds the decisive detail that it 'fir[es] the input/change events a real choice fires.' This makes the operation concrete and implicitly separates it from generic interaction siblings like ghost_tab_click or ghost_act, though it never names an alternative 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 context is implied: reach for this tool when you need to simulate a real user choice on a <select>, including its event side effects, rather than a bare click or key press. No explicit when-to-use or when-not-to-use guidance is given, and no sibling is called out among the many interaction tools available.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It transparently states that only visible text is returned and that omitting the selector causes the whole page to be used. The 'reading content' wording implies a read-only operation, though it does not explicitly mention edge cases like missing selectors or empty text.

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 wasted words. It states the core behavior, the selector fallback, and a usage preference in a compact form.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity of the tool and the explicit statement about return content and selector behavior, the description is mostly complete. It lacks explicit return-format details and edge-case behavior, but the absence of an output schema is partly mitigated by the clear statement that visible text is returned.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It usefully explains the selector parameter and its omission behavior, but it does not explain the 'tab' or 'browser' parameters beyond their names, leaving some ambiguity for the agent.

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

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

The description clearly identifies what the tool returns: visible text of an element or the whole page when selector is omitted. It also distinguishes the tool from screenshots for content reading, though it does not explicitly differentiate it from sibling text/describe tools like ghost_tab_describe.

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 phrase 'Prefer over screenshots for reading content' gives clear guidance on when to use this tool instead of an alternative. It does not explicitly state exclusions or when to prefer other tab tools, but the context is clear enough for typical text-extraction scenarios.

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 must carry the behavioral burden. It does disclose non-obvious traits: the action is layout-independent and does not touch the user's keyboard. However, it says nothing about the default clearing behavior, whether the field value is replaced or appended, visibility requirements, or failure behavior.

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 focused sentence that front-loads the core action and adds only high-value differentiators. Every word earns its place; there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with five parameters, no annotations, and no output schema, the description is too thin. It lacks parameter semantics, default behavior for 'clear', browser/tab context, and guidance on selecting this tool from its many siblings. An agent would need to inspect the schema and infer too much.

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 only 20%, and the description only clarifies 'selector' by mentioning CSS selector. It does not explain the meaning or format of 'tab', 'text', or 'browser', though some are inferable from names. The description fails to compensate for the low schema coverage.

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

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

The description states a specific action ('Focus an element by CSS selector and type into it'), naming both the resource and the operation. It adds useful differentiators ('Layout-independent; does not touch the user's keyboard') that separate it from keyboard-level siblings, though it does not name any sibling 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 description implies use when element-focused, layout-independent typing is needed without affecting the user's keyboard, but it does not explicitly state when to choose this tool over alternatives like ghost_key, ghost_tab_press, or ghost_tab_text. There is no when-not-to-use 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 bears the full burden of explaining behavior. It states that the tool waits until a selector matches an element, but it does not disclose timeout behavior, what happens when the selector never matches, whether the element must be visible, or whether the tool returns a result or fails. This is a significant gap for a wait operation.

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

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

The description is a single concise sentence that front-loads the core action and target. It avoids fluff, but it may be slightly too terse given the lack of annotations and the presence of several parameters that need explanation.

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 tool has four parameters, no output schema, and no annotations, yet the description only covers the basic waiting condition. It does not explain return values, failure modes, default timeout behavior, or how the tab and browser parameters relate. The description is not sufficient for an agent to confidently invoke this tool in varied situations.

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

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

Schema description coverage is 0%, so the description must compensate for explaining parameters. It adds meaning for 'selector' by clarifying it is a CSS selector and for the general waiting behavior, but it does not explain the 'tab' identifier, the optional 'browser' parameter, or the unit/default behavior of 'timeout_ms'. The description only partially compensates for the missing schema documentation.

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

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

The description clearly identifies a specific action (wait) and resource (an element matching a CSS selector in the tab). It is not a tautology and is distinguishable from sibling tools like ghost_wait by explicitly mentioning the tab and selector-based matching, though it does not strongly differentiate itself from all related tab 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?

No guidance is provided about when to use this tool versus alternatives such as ghost_wait, ghost_tab_find, or ghost_assert. There is no mention of prerequisites, conditions, or situations where this tool should be preferred or 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 provided, the description carries the full behavioral burden and does well by disclosing key side effects: navigate loads a URL 'WITHOUT raising it,' 'sets the address bar over UIA, presses Enter,' and 'returns when the window title changes'; ms 'costs its full length every run.' It does not describe timeout or failure behavior, so it is not a perfect 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?

The description is dense but appropriately sized for eight modes, and it is front-loaded with the unified purpose before enumerating the for= variants. It uses a consistent semicolon-separated structure, though bullet formatting would make it easier for an agent to scan.

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 14-parameter tool with no output schema and no annotations, the description explains every mode, specifies the target-window rule, and even gives the navigate response fields. Minor gaps remain around since_seq for event waits and the click-target parameter for text waits, but the overall guidance is sufficient for correct invocation.

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

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

Schema coverage is already 93%, and the description adds meaningful context beyond the schema: value waits for equals/contains/changes semantics, element waits for appearance or disappearance 'in the target window,' and navigate has a settle_ms pause after the title changes. The for=text mode is slightly ambiguous about how the click target is identified, which prevents a 5.

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 opens with 'Unified wait - use it instead of sleeping' and enumerates eight distinct wait modes (element, value, navigate, idle, text, event, cond, ms), so the verb and resource are clear. It does not explicitly contrast itself with the sibling ghost_tab_wait_for, so it stops short of full sibling 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?

The description provides mode-specific selection guidance, explicitly calls for=ms a 'last resort' that 'costs its full length every run,' and notes the condition under which navigate uses the old focus-and-type path. It does not mention when to prefer the sibling ghost_tab_wait_for, but the within-tool routing between modes 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 provided, the description carries the full burden of behavioral disclosure, and it delivers: focus 'ANCHORS the window and does NOT raise it,' state operations 'never activate the window, so the user's focus stays put,' and launch 'starts on a hidden desktop, never on your screen.' These are exactly the surprising, non-obvious side effects an agent needs to know before invoking the 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 one dense paragraph, but every sentence earns its place and the op= prefixes make it scannable. It is long only because it covers five operations with real behavioral nuance; still, a bullet-per-op layout would have improved readability over the wall-of-text format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description covers a remarkable amount: list output fields, anchor mechanics, state-operation effects, launch destination, and a hint about target.surface. Minor gaps remain — 'the anchored verbs' and 'operator-unlocked prefer_background/foreground policy' are referenced without definition, and the non-default policy path is only partially explained.

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 adds genuine value beyond the schema by tying parameter effects to policy: 'name= sets the anchor, clear=true clears it, no args reports it,' 'name+state' for op=state, and the note to 'see target.surface in the response' for launch. This enriches parameter meaning rather than repeating the schema.

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

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

The first sentence names a specific verb and resource: 'Window management across the user's desktop AND Ghost's hidden desktops.' The op= enumeration then concretely details what the tool does for each operation (list, focus, anchor, state, launch). No sibling tool claims desktop/hidden-desktop window management, so it is clearly differentiated from ghost_tab_* and ghost_browser_* 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 description provides clear conditional context: each op states what it does under the default background policy, and it explains when restore is the path to making a minimized window actionable and when launch places an app on a hidden desktop. It never explicitly names alternatives or exclusions among siblings (e.g., when to prefer ghost_run for a visible launch), so it stops short of full when-to-use vs. when-not-to guidance.

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