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

With no annotations, the description carries the behavioral disclosure burden and does it well: type supports clear and submit, scroll is in pixels with negative meaning up, and targeting can use ref or CSS selector. It does not cover failure behavior or navigation side effects, but the core behavioral surface is disclosed.

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 no filler. The action list is front-loaded, and every clause adds useful information such as negative-scroll direction, targeting options, and ref provenance.

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 provides a compact action mini-language plus targeting guidance, which is enough for an agent to invoke most actions correctly with the schema defaults. It omits session/device semantics and action-specific parameter requirements, but the output schema covers return-value expectations.

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 by explaining parameters. It successfully embeds most parameters in action syntax: type(text, clear, submit), press(key), select(value), scroll(amount px), and ref/selector. However, session and device are never explained, leaving the parameter model incomplete for a tool with 11 parameters.

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

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

The description states a concrete action catalog on the page resource: click, type, press, focus, hover, select, check/uncheck, scroll, and scroll_into_view. It also specifies how to target elements via ref from browser_find/browser_read or CSS selector, which clearly separates it from the read-only browser 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?

Usage is implied: perform actions on the current browser page, and obtain refs from browser_find/browser_read. However, the description does not explicitly state when not to use this tool, nor does it contrast it with mobile interaction siblings like tap, type_text, or press, leaving the domain boundary to inference.

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

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

No annotations are provided, so the description must carry the behavioral burden. It does disclose the key side effect (blanking the page) and the additional effect of close_app (stopping the app), but it leaves unclear whether session state is persisted, what happens to active tabs, or whether there are irreversible consequences.

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 that front-loads the main action and tucks the optional behavior after a semicolon. It is efficient, though it could have used the saved space to define the ambiguous parameters.

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?

This is a session-mutating tool with no annotations gaps are meaningful: device/session semantics are undocumented, the response/output schema is not hinted at, and the consequences for the browser session are only partially disclosed.

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?

With 0% schema description coverage, the description needed to explain device, session, and close_app. It only adds meaning to close_app ('also stops the browser app'); device and session remain undefined, leaving an agent to guess their values and roles.

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-resource pair ('Detach a browser session') and clarifies the destructive scope with 'blanking the page.' It also distinguishes the close_app flag behavior, which helps separate this tool from the many browser_* 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 a clear context for when to call this tool (to detach or close a browser session) and explains the close_app option. However, it does not explicitly compare this tool to sibling alternatives like browser_handoff or browser_open, nor state when not to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the return shape for the table kind, but does not state whether the operation is read-only, whether it requires an active page, whether it scrolls or navigates, or what happens on failure. This is a notable gap for a tool with zero annotation coverage.

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

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

A single dense sentence with no filler. The pipe-separated list is efficient and front-loads the core decision (which kind to extract). Every word adds signal.

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 5 parameters, no schema descriptions, and no annotations, a one-line description is not complete. It omits how to target an element (selector), how to bound results (limit), and how to specify device/session. The output schema may cover return values, but the tool's overall behavior and parameter roles are underdocumented.

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 schema's silence. It explains the 'kind' parameter with its three values and the table row/header structure, but says nothing about 'limit', 'device', 'session', or 'selector'. The majority of the five parameters remain 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 states a specific verb ('Pull') and resource ('structured data'), and enumerates the exact output kinds: table with headers and row dicts, links, and text. This makes the primary intent clear, though it does not explicitly differentiate from sibling tools like browser_read or browser_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?

There is no guidance on when to use this tool versus alternatives. The description implies it is for extracting structured content from the current page, but it does not state selection criteria, prerequisites, or when to prefer browser_read, browser_find, or other 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 transparency burden. It discloses the important visible-only filter and the fact that the tool returns refs rather than performing an action, implying a read-only operation. It does not cover no-match behavior or exact/substring matching, but those are secondary for a locator.

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

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

One compact sentence with the core behavior front-loaded and the output purpose attached. 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 simple locator with an output schema and defaulted optional parameters, the core contract is complete: query by accessible attributes, only visible elements, return refs usable by browser_act. Minor omissions are explicit matching semantics and any session-only precondition, but they do not block 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%, so the description must compensate. It adds useful semantics to query by enumerating which accessible attributes are matched. However, it says nothing about limit, device, or session, leaving an agent to infer their roles mostly from names/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?

"Find visible elements" names a specific verb, resource, and scoping constraint, followed by the accepted match attributes (text, label, placeholder, alt, name). The explicit return of refs for browser_act distinguishes this locate/query tool from sibling action and extraction 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 clearly positions the tool as the discovery step that feeds browser_act by returning refs. It does not spell out exclusions or when to prefer browser_extract/browser_read, so it misses the top tier.

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 correctly discloses the core behavior (foregrounding the browser, delegating to a human) and the follow-up step. However, it does not disclose what happens during the handoff — whether the tool blocks until the human finishes, whether there is a timeout, or how the session is affected — which matters for an agent deciding how to sequence actions.

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 totaling roughly 25 words, with the core action and purpose front-loaded and the follow-up instruction placed second. Every word earns its place; there is no filler or redundancy.

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

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

An output schema exists, so return values need not be explained in the description. The description covers the core invocation scenario and sequence adequately, but it omits parameter semantics and any statement about waiting/timeout behavior. For a tool of this simplicity, this is a minimum-viable description with a few meaningful gaps.

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

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

Schema description coverage is 0% and the description mentions none of the three parameters (device, message, session). Since coverage is below 50%, the description was expected to compensate but does not. The parameter names are conventional and self-hinting, but an agent gets no guidance on what 'message' is for (e.g., a prompt shown to the user) or how 'session' scopes the handoff.

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 ('bring the browser to the foreground') with a concrete purpose (human finishes a login or captcha). It also differentiates itself from siblings by naming its continuation flow ('call browser_read afterwards'), making clear this is the human-handoff tool rather than a programmatic browser action or an input-injection tool.

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

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

The description gives clear context for when to use the tool: when a human must complete a login or captcha by hand. It provides a sequencing guideline (follow with browser_read), but it does not explicitly state exclusions such as 'use browser_act when no human interaction is needed' or contrast with sibling tools like type_text or tap.

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 must carry the full behavioral burden. It mentions 'session' naming the attachment, but does not disclose important behaviors such as whether the tool waits for page load (wait parameter), timeout behavior, or side effects like changing the active session. It also doesn't explain what happens when both url and target_id are provided. The description is too sparse for a tool with no annotations.

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

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

The description is a single, dense sentence that front-loads the core action ('Open a URL') and then adds the attachment mode. It is efficient and free of filler, though it packs a lot of information into one sentence, which could be slightly clearer with separation. Overall, it is concise and well-structured.

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 7 parameters and no annotations, the description is incomplete. It does not explain the return value (though an output schema exists), nor does it clarify the roles of wait, timeout, or device. It does not describe how to handle errors or whether the tool blocks until the page loads. For a tool with such complexity, the description falls short of providing sufficient context for correct invocation.

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

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

Schema description coverage is 0%, meaning the description is the only source of parameter meaning. It explains target_id, app, and session, but ignores url, wait, device, and timeout. The description provides partial clarity for 3 of 7 parameters, leaving the rest undefined. It does not compensate for the complete lack of 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's primary function: 'Open a URL in the on-device browser' and its secondary attachment mode. It specifies the resource (URL/browser) and the verb (open/attach), and distinguishes from siblings like browser_tabs and browser_read by mentioning target_id and app for WebView. The purpose is unambiguous.

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

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

The description explains when to use the tool: to open a new URL or attach to an existing page (via target_id or app). It gives a specific source for target_id (browser_tabs) and hints at the app parameter for WebView. However, it does not explicitly state when not to use this tool or compare it to other browser_* tools, but the usage context is clear enough for an agent to decide when to invoke it.

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

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

With no annotations, the description bears the full burden and does disclose the main behavior: it reads the page and returns title, URL, and visible text, optionally listing interactive elements with refs. It lacks details on side effects, permissions, or truncation behavior, but for a read operation this is reasonably 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 sentence with no filler. It front-loads the core action and output, then uses a semicolon to add the optional structure mode and its purpose, making it easy 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 basic invocation is clear and the presence of an output schema covers return formatting, but the description is thin for a 5-parameter tool with no schema descriptions. It omits guidance on `selector`, `max_chars`, and session/device selection, and it does not direct the agent to related tools, leaving gaps for non-default 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?

Schema description coverage is 0%, so the description must compensate for the five undocumented parameters. It only clarifies `structure`; it leaves `device`, `session`, `selector`, and `max_chars` without added meaning, so an agent cannot infer how they affect the read.

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 ('Read the page') and enumerates the exact output: title, URL, and visible text. It also distinguishes its interactive-element listing mode from the acting tool by mentioning refs 'for browser_act', making its role in the browser suite clear.

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 that `structure=true` should be used when the agent needs interactive-element refs to pass to `browser_act`, providing some context for when to enable that option. However, it gives no explicit guidance on when to choose this tool over similar alternatives like `read_screen`, `browser_extract`, or `browser_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?

The description discloses a key behavioral trait: the owning app is brought to the foreground before capturing, because a hidden WebView cannot render. This is useful and beyond what annotations would provide (since there are none). However, it omits other behaviors like return format, side effects on app state, or permission requirements, which are important given no annotations exist.

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 concise: two sentences, with the purpose stated first and a behavioral note second. No wasted words, and the structure is front-loaded.

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

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

For a tool with three parameters, no output schema, and no annotations, the description is inadequate. It fails to explain what the output looks like (e.g., file path, base64), what each parameter does, or any prerequisites like permissions. The only useful context is the foregrounding behavior, which is not enough for safe 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 0% and the description provides no explanation of the three parameters (device, session, full_page). The agent is left to infer their meaning from names and defaults alone. Since the description does not compensate for the lack of schema descriptions, it fails to add value here.

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 tool takes a screenshot of page content, which is clear and specific to a browser context. It doesn't differentiate from siblings like get_screenshot or screenshot, but it does mention 'page content' and the owning app, so it's not a tautology. A clear verb and resource, but lacks explicit 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?

There is no guidance on when to use this tool versus alternatives like get_screenshot or screenshot_path. The description only mentions a technical behavior (foregrounding the app) but doesn't advise on selection criteria, such as when to prefer this over other screenshot 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes scope, not whether this is a read-only listing, whether it opens any sessions, what permissions are needed, or what happens with attached sessions. It adds minimal context about coverage but no real behavioral transparency.

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 short, front-loaded sentence with no filler, and the scope detail is useful. However, it sacrifices necessary verb and parameter information for brevity, reading more like a category label than a complete tool description.

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

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

With no annotations, a 0%-covered parameter, and a one-line noun-phrase description, the definition is insufficient for an agent to safely invoke the tool. The presence of an output schema reduces the need to describe return values, but the missing action and device semantics remain significant gaps.

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

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

The single optional 'device' parameter has 0% schema description coverage, and the description never mentions it. The agent cannot determine what device selects, whether null means the current device or all devices, or how the parameter interacts with 'attached sessions'.

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 the resource (open pages in the on-device browser and WebViews, plus attached sessions) and helps distinguish it from sibling browser tools, but it is a noun phrase rather than an explicit action. It never states that the tool lists or returns tabs, so an agent must infer the behavior from the name 'browser_tabs'.

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

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

There is no guidance on when to use this tool versus alternatives like browser_close, browser_read, get_ui_tree, or perceive_screen. No context is given for when querying attached sessions is appropriate or how this relates to the optional device parameter.

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 does reveal an important side effect: host files are pushed to /sdcard/Download first, and hidden directories are disallowed. However, it does not explain what happens after attachment, whether the file is immediately submitted, or what state changes occur in the browser. Some useful behavior is disclosed, but significant gaps remain.

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 sentences with no filler. The core action is front-loaded, and the critical path constraint is stated immediately after. 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 five parameters, no schema property descriptions, and no annotations, yet the description only explains the `path` parameter. It does not cover selector/ref semantics, session targeting, or device routing. Although an output schema exists, the agent still lacks enough context to correctly construct a call beyond supplying a path.

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

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

Schema description coverage is 0%, so the description must compensate. It provides strong semantics for the required `path` parameter, explaining device paths and the host-file push behavior. However, the other four parameters (`ref`, `device`, `session`, `selector`) are not explained at all, leaving the agent to guess how to target the correct browser session or file input.

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: 'Attach a file to an <input type=file>'. This clearly identifies the tool's function and distinguishes it from sibling browser tools like browser_read, browser_find, and browser_act, none of which handle file attachment.

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 case is implied: use this when a file needs to be attached to a file input in a browser context. However, the description does not explicitly state when to use it versus alternatives, nor does it mention prerequisites such as an active browser session or visible file input. Context is clear but not fully developed.

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 for behavioral disclosure. It explains what is waited for, but not how the wait behaves: whether conditions are combined as AND or OR, what happens on timeout, whether it polls, or whether it errors when the condition is not met. The phrase 'and/or' is also ambiguous.

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 core verb and target front-loaded. It avoids fluff, though the ambiguous 'and/or' slightly detracts from clarity.

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 six parameters, zero annotations, and 0% schema description coverage, the description is too sparse. It omits critical operational details such as timeout behavior, how multiple conditions interact, and the role of device/session parameters, leaving agents to guess.

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 adds meaning for text, selector, and url_contains, but it does not explain the semantics of device, session, or timeout, all of which remain undocumented in both schema and 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?

The description clearly states the action ('Wait until') and the target resource ('the page'), and enumerates specific conditions (text, selector, URL fragment, finished loading). It is not a tautology and gives a concrete sense of the tool's purpose, though it does not explicitly differentiate itself from sibling wait_for.

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

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

There is no explicit guidance on when to use browser_wait versus alternatives like wait_for or browser_read. The intended use is only implied through the condition list, and no exclusions or alternatives are mentioned.

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 full burden of behavioral disclosure. It implies reconnection is idempotent and recovery-oriented, but does not explain side effects, prerequisites, failure behavior, or whether the operation disconnects before reconnecting.

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 communicates the action and the trigger condition with no filler. Every part 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 low-complexity tool with an output schema, the description is mostly adequate: it says what the tool does and when to use it. However, it leaves the optional device parameter's default behavior and the meaning of 'Portal' unexplained, so an agent may still be uncertain on some edge cases.

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

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

Schema description coverage is 0%, and the description only says 'for a device,' which adds minimal meaning beyond the parameter name. It does not explain what the device value should be, what null/default means, or what happens when the parameter is omitted.

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: (re)connecting adb and the Portal for a device, which distinguishes it from diagnostic siblings like ping_device or get_device_status. The term 'Portal' is somewhat domain-specific and unexplained, but the core verb and resource are clear.

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 a clear usage condition: use it after the network path has recovered. It does not mention alternative tools or explicit when-not-to-use cases, but the recovery context is enough to guide 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 burden of behavioral disclosure. It mentions 'clearable' but does not explain side effects, irreversibility, permissions, or how the tool handles the clear_all flag. It does not disclose whether dismissing is destructive or if it affects other system state.

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, front-loaded with the main action. It avoids fluff and directly states the core functionality. However, it is so terse that it under-specifies important details, but that is a completeness issue rather than a structure issue.

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 5 parameters and no annotations, the description is incomplete. It does not explain the selection logic clearly, omits the device parameter, and does not describe return values or error conditions. The existence of an output schema does not compensate for the lack of parameter and usage context.

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

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

Schema coverage is 0%, so the description must explain parameters. It mentions key, package, title, and clear_all indirectly ('every clearable one'), but the phrasing 'by key, or package/title' is ambiguous about how selectors combine. The 'device' parameter is entirely unmentioned, and the logic for when clear_all applies is unclear.

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 action (dismiss) and the resource (notification), and distinguishes two modes: single (by key or package/title) or all clearable. It is specific and understandable, though it does not explicitly contrast with sibling tools like notification_action.

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

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

No guidance is provided on when to use this tool versus alternatives such as read_notifications or notification_action. The description implies usage (dismissing notifications) but does not offer exclusions or context about when to prefer this over related 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 provided, the description carries the full burden. It does disclose one useful behavioral trait—'both taps are issued concurrently so they land together'—but it does not mention outcome, failure behavior, effects on the device, or implications of null coordinates. This is too thin for a gesture tool with zero annotation support.

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

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

A single sentence, front-loaded with the action and target, containing no filler. The ambiguity of 'a mark' costs some clarity, but the structure is efficient.

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

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

For a tool with no annotations, sparse schema metadata, and an output schema that is not explained, the description is under-specified. It fails to clarify what a 'mark' is, how device selection works, and what the tool returns or reports. An agent would need to guess at core 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 explains x and y as coordinates and hints at a 'mark' alternative, but it does not connect 'mark' to som_id and never mentions the device parameter. Most of the four parameters remain effectively 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 action ('Double-tap') and target ('at (x, y) or a mark'), which distinguishes it from gesture siblings like tap and long_press. However, the phrase 'a mark' is ambiguous and is not explicitly tied to a parameter or sibling concept.

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 given about when to use double_tap versus alternatives such as tap or long_press. There are no conditions, prerequisites, or exclusions, leaving the agent to infer the appropriate context.

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

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

No annotations are present, so the description carries the disclosure burden. It discloses the important behavioral constraint that the tool does not touch the device, implying a safe, server-side probe. However, it does not say that the message is echoed back or describe failure/error behavior; the output schema may cover some of this.

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 no filler. The core purpose and the key distinction from device tools are front-loaded, and every word contributes 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?

The tool is very simple, has one optional and self-explanatory parameter, and an output schema is available. The description covers the server-side scope and the no-device safety aspect. It doesn't explicitly describe the echo response or alternative liveness checks, but these are minor given the simplicity and output schema.

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

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

The description makes no mention of the message parameter, and schema description coverage is 0%, so it adds no parameter meaning beyond the schema's name/type/default fields. The parameter is named transparently, but the description still fails to compensate for the absent 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 the tool as a connectivity check for the MCP server itself, which is a specific verb-plus-resource statement. The explicit 'does not touch the device' distinction separates it from the many device-oriented sibling tools, so an agent can tell what it is for.

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 a clear usage context: use it to verify MCP server connectivity rather than device state or control. The 'does not touch the device' clause provides a useful exclusion, though it does not name a specific alternative like ping_device or state explicit when-not-to-use conditions.

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

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 discloses that success may be refused based on findings count, and that the call should occur after a final perceive_screen. This adds valuable behavioral context beyond the schema. It does not mention other side effects, but the key behavior is covered.

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 sentences, front-loaded with the core action. It includes essential constraints and ordering without any fluff. Every sentence earns its place, and it is structured efficiently.

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?

An output schema exists, so return values are covered. The description explains the outcome options, the refusal condition, and the calling order. It does not elaborate on the 'device' or 'summary' parameters, but these are optional and likely self-explanatory. Overall, it provides sufficient context for an agent to call 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 0%, so the description must explain all parameters. It only describes 'outcome' with its allowed values (success, partial, failed). It does not explain 'device' or 'summary' at all, leaving them undocumented. This is a significant gap given the zero 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 states the action: 'Close out the run.' It specifies the resource (the run) and the outcome values. It is not a tautology and distinguishes from siblings by being the terminal session action. The verb and resource are 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 gives explicit usage context: 'Call after a final perceive_screen.' It also explains a condition for success (refusal if fewer findings than target_count), which guides when to use and when success may not be granted. This is clear and actionable.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals one non-obvious behavior (empty query lists everything), but it does not state whether the search is recursive, how `max_depth` and `limit` behave, what `device` selection implies, or any side effects. This leaves a substantial transparency gap for an unannotated 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 entire description is a single sentence with a useful parenthetical. The primary verb and resource are front-loaded, and every word adds value without repeating the title or schema defaults.

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 and no annotations, a one-sentence description is thin. It omits the default root path, depth/limit semantics, and device-selection role, forcing an agent to infer from parameter names alone. The presence of an output schema does not compensate for the lack of parameter context.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only clarifies the `query` parameter ('name contains' matching and empty behavior); `path`, `limit`, `device`, and `max_depth` receive no semantic explanation beyond their names and default values. The description does not disambiguate what `max_depth` means or how `limit` is applied.

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 the verb 'Find' and specifies the resource ('files under shared storage') plus the matching rule ('name contains query'), with a parenthetical clarifying empty-query behavior. This distinguishes it clearly from sibling tools like list_apps or browser_find, so an agent can recognize what the tool does and what it does not do.

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 explicit when-to-use or when-not-to-use guidance and does not name alternatives or exclusions. Usage must be inferred from the one-line purpose, which is clear in context but lacks any direct comparison to other 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 provided, the description carries the full burden of behavioral disclosure, and it does convey what the report contains (a state snapshot across seven dimensions), which is useful. However, it does not disclose prerequisites (e.g., a connected device), the meaning or behavior of the null device default, failure modes, or confirm the read-only nature beyond what the name 'get' implies.

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 eight words long with zero wasted tokens; every term carries information about the returned status. For a one-parameter read tool this is an appropriately minimal size, though the lack of a verb is a structural weakness already accounted for in purpose clarity.

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?

Complexity is low: one optional parameter, an existing output schema, and a clear field list, so an agent can likely invoke it correctly with no arguments. Still, there are clear gaps — no usage routing against the many siblings and no explanation of the device parameter or null behavior — making it adequate but incomplete.

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 was expected to compensate by explaining the device parameter, yet it is entirely silent on it. The schema's string/null type and default null weakly suggest an optional device selector, but the description adds no meaning about device identifiers or what null resolves to, so it misses the only parameter entirely.

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 is a fragment listing seven concrete status dimensions (battery, screen power, foreground app, size, storage, network addresses, volume), so it clearly conveys what the tool reports and avoids tautology. The verb must be inferred from the tool name since no verb is present, and the field list implicitly separates this state/health read from pixel- or UI-tree-focused siblings like get_screenshot, read_screen, and get_ui_tree, though no sibling is named explicitly.

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

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

The description offers no guidance on when to use this tool versus alternatives such as read_screen, get_ui_tree, ping_device, or volume_up. It names no alternatives, gives no exclusions, and never states that this is the read-only status query among the many action-oriented sibling tools; the intended usage is only implied by the tool name and the field list.

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 disclosure burden. It lists the output contents but does not say whether the operation is read-only, whether device defaults to the active device, what include_system changes, or whether any side effects occur. Basic output information is present, but behavioral context is largely missing.

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 terse sentence with no filler and the core resource is front-loaded. However, it is so abbreviated that it reads like a fragment rather than a complete sentence, and it omits parameter context. Still, the structure itself is efficient.

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

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

Despite having an output schema, the description leaves the two optional parameters unexplained and provides no usage context or behavioral notes. It is minimally acceptable for a simple getter, but for a tool that accepts a device selector and an include_system flag, the description is incomplete.

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 does not mention either parameter, device or include_system, at all. The parameter names offer limited hints, but the description adds no meaning about device targeting or what including system sessions would mean. This is a significant 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 identifies the resource (media sessions and music volume) and the specific payload fields (app, playback state, title/artist), which clearly distinguishes it from sibling control tools like media_control or volume_up. It lacks an explicit verb like 'retrieves' or 'returns', but the tool name supplies the action, so the purpose is still clear.

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 given about when to use this tool versus siblings such as media_control, volume_up, or get_device_status. The description implies it is a read action, but it does not state exclusions, prerequisites, or alternative conditions.

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 only says the result is an image; it does not mention permissions, device applicability, side effects, failure modes, or whether the screenshot reflects the current screen. This is minimal disclosure for an unannotated 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 short and front-loaded with its main point, but it is under-specified rather than appropriately concise. The single sentence sacrifices essential usage and parameter information for brevity.

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 one parameter, no output schema, and no annotations, the description should explain the device parameter and distinguish the tool from similar screenshot siblings. It does neither, leaving the agent without enough information to invoke 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?

The input schema has one optional device parameter with 0% schema description coverage, and the description does not mention this parameter at all. The description completely fails to explain what device means, how it should be specified, or what the default behavior is.

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 that the tool produces a screenshot as an image, giving the agent the resource and output form. However, it does not distinguish get_screenshot from sibling tools like screenshot, screenshot_path, or browser_screenshot, so differentiation is left 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?

No guidance is given about when to use this tool versus alternatives such as screenshot, perceive_screen, or read_screen. The word 'plain' weakly implies a raw image without analysis, but there is no explicit when-to-use or 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, the description carries the full burden. It adds that the tree is 'compact' and lists output fields, but does not disclose how accessibility data is obtained, what happens when the tree is unavailable, whether permissions are needed, or how max_depth affects results. These are significant behavioral gaps.

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

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

The description is a single dense sentence with no filler and the key output concept is front-loaded. The field list is compact and informative, though the brevity comes at the cost of missing guidance.

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

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

The output schema covers return structure, so explaining field contents is less critical. However, with zero annotations and zero parameter documentation, the description is too sparse to fully support correct invocation; it lacks device handling, depth semantics, and sibling differentiation.

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 device and max_depth parameters. It does not mention either parameter, leaving an agent unable to infer device selection or depth behavior 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?

The description identifies the resource (accessibility tree) and specifies the exact contents: class, id, label, flags, and bounds. It is not a tautology, but it does not differentiate from sibling tools like read_screen or perceive_screen.

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 given on when to use this tool versus alternatives such as get_screenshot, read_screen, or perceive_screen. The description provides no context about suitable scenarios or 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates that the tool provides a guide, but it does not state whether the operation is read-only, what happens when topic is null, or what form the response takes. The output schema may describe the return shape, but behavior beyond that is unexplained.

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 compact sentence plus a topic list, with no wasted words. It front-loads the core purpose and then gives concrete options for the only 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?

For a simple tool with one optional parameter and an output schema, the description is mostly sufficient: an agent can invoke it correctly by picking one of the listed topics. It could be more complete by stating what an omitted topic returns and whether the topic list is exhaustive, but these are minor gaps given the 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?

Schema description coverage is 0%, so the description's topic list ('overview, shortcuts, text_entry, failures, ledger, browser') is the only semantic guidance for the single 'topic' parameter. It compensates for the empty schema by enumerating likely values, though it does not define what each topic contains or explain the null default.

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 title 'Get Usage Guide' and description 'How to use this server well' clearly establish that this tool returns usage documentation for the server. The topic list distinguishes it from the many action-oriented siblings like screenshot, tap, and type_text, though the description itself lacks an explicit verb.

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 'How to use this server well' implies this should be used when an agent needs orientation or guidance on server features. However, it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or a recommended call order relative to other 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 behavioral disclosure burden, and it reveals genuinely non-obvious behavior: the tool does not guess on ambiguous names but returns ranked candidates. That is important context beyond what the schema alone would provide. It omits failure modes and device context, but the core launch and disambiguation behavior is 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?

Two sentences with the main action front-loaded and the disambiguation rule following naturally. There is no filler, and every phrase adds information an agent needs.

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 launch tool, the description covers the normal call patterns and the key ambiguous-name behavior, and an output schema exists so return values do not need to be described. The main gaps are the role of the device parameter and the lack of comparison to start_app, but the tool is largely usable from this definition alone.

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 0%, so the description must compensate; it does map 'name' to the app_name parameter and 'package' to the package parameter, including its disambiguation role. However, the device parameter is never mentioned, and the description does not state valid combinations or formats for the package and app_name values.

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 and resource: 'Open an app by name (fuzzy) or exact package.' It also adds a distinctive behavioral detail about returning ranked candidates for ambiguous names. However, it does not explicitly differentiate launch_app from the sibling start_app, so it falls just short of full sibling distinction.

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

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

The description provides practical guidance for the main decision: use a fuzzy name or an exact package, and if the name is ambiguous, 'pass package to pick one' instead of letting the tool guess. This is clear invocation context, though it does not explicitly state when to prefer this tool over alternatives like start_app or lookup_app.

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

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

With no annotations, the description carries the full behavioral burden and does well by disclosing that each entry is probe-resolved on the device and explaining the resolved=true semantics. It doesn't cover side effects, but for a read-only listing operation that 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?

A single sentence that is front-loaded with the core purpose and packs meaningful detail (registered filters, curated entries, probe resolution) with no wasted 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?

The output schema exists, so return values are already documented. The core behavior is described, but the complete absence of parameter usage guidance is a significant gap for a tool with three optional, undocumented parameters.

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 does not mention device, package, or app_name at all. An agent cannot determine how to target a specific app or what combinations of parameters are valid.

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) and resource (app deep links), then adds detail about what's included (registered VIEW intent filters plus curated entries) and the resolution status. An agent can distinguish this from sibling tools like resolve_deeplink and open_deeplink purely from the description.

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 explicit when-to-use or when-not-to-use guidance is given, and no alternatives are named. The description only defines what the tool does, leaving an agent to infer when to call it versus a sibling like resolve_deeplink.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does disclose the main behavioral trait, user-only filtering by default, but it says nothing about permissions, output content, or whether system=true includes both user and system apps.

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

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

A single sentence with no filler. It front-loads the operation and immediately qualifies the key optional behavior with a conditional.

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 simple, has only optional parameters, and an output schema exists, so the core call is close to self-evident. However, the missing explanation of the device parameter and the lack of any sibling differentiation leave meaningful gaps for an agent choosing and invoking this tool.

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

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

Schema coverage is 0%, so the description must compensate. It explains the system parameter's default and effect, but the device parameter is left entirely to inference from its name and null default.

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: "List installed apps". The clause "user apps only unless system=true" immediately adds a scoping distinction that separates it from lookup or launch tools among the 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?

No guidance is given on when to choose this tool over alternatives such as lookup_app or launch_app. The "unless system=true" condition is parameter behavior, not a usage guideline, and the device parameter is not addressed.

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 of behavioral disclosure. It only reveals the output fields (serial and state) and the adb source, but it does not say whether this is a safe read-only operation, whether it might start the adb server, require device authorization, or what state values mean. There is no contradiction, but the behavioral disclosure is 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 extremely compact and front-loaded, using a single sentence to state the output source and content. Every word earns its place, and the parenthetical adds the two most useful data fields without padding.

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

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

For a zero-parameter enumeration tool with an output schema, the description provides the core operational facts: no inputs needed, returns adb-visible device serials and states. It doesn't clarify when to use it instead of nearby device tools, but that gap is already captured under usage guidelines, and the output schema likely covers return structure.

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 there is no parameter documentation burden. The empty schema already communicates that no arguments are needed, and the description adds no parameter details, which is appropriate. The baseline of 4 applies here.

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 title already communicates the verb and resource, and the description adds useful specificity: it returns devices visible to adb, including serial and state. It is not tautological, and while it doesn't explicitly contrast with sibling device tools like get_device_status or connect_device, the 'adb can see' qualifier makes the scope reasonably clear.

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 list_devices versus alternatives such as get_device_status, connect_device, or ping_device. There are no usage conditions, exclusions, or references to more appropriate sibling tools, so the agent must infer selection from names alone.

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, but it only names the gesture. It does not disclose the default hold duration (800ms), what a 'mark' is or how it is resolved, whether a device must be specified, or any side effects. 'Or a mark' introduces an unexplained behavior not reflected in 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?

One short, front-loaded sentence with no filler; it states the action immediately. However, the unexplained 'mark' concept makes it less self-contained than it appears.

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 5 optional parameters, a 0% described schema, and no annotations, this description is too sparse to fully prepare an agent. It fails to explain the 'mark' alternative, coordinate origin/format, device targeting, or duration semantics. The presence of an output schema only removes the need to describe return values; it doesn't fill these input gaps.

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

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

Schema description coverage is 0%, and the description only glosses x/y via 'at (x, y)' and vaguely references a 'mark' that is not a parameter. The device, som_id, and duration_ms parameters receive no semantic explanation, leaving the agent to infer them from names/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 states a specific action ('Press and hold') and a target ('at (x, y) or a mark'), which clearly sets it apart from sibling gestures like tap and double_tap. It is not a tautology and gives enough to identify the tool's core function.

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 choose long_press over tap, double_tap, or swipe. There is no mention of contexts (e.g., triggering context menus), exclusions, or alternative 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 burden of behavioral disclosure. 'Search' implies a non-destructive read-only operation, and 'returns ranked candidates' hints at the output, but it does not explicitly confirm that no device state is changed, nor does it cover error cases, privacy, or permission requirements. The basic behavior is evident, but the disclosure is 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, well-structured sentence that front-loads the action ('Search installed apps') followed by the criteria and the result type. Every word adds value, and there is no redundancy or 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 tool with three parameters and no annotations, the description is reasonably complete but not fully. It covers the core intent and result shape, but leaves the optional parameters' effects unexplained. The presence of an output schema helps, but the description does not mention how limit or device affect behavior, nor does it address alternative tools. Overall, it's adequate but with gaps.

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

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

Schema description coverage is 0%, so the description must compensate for all parameters. It does explain the 'query' parameter by saying 'by name or package', but it entirely omits 'limit' and 'device'. The description adds some value for the required parameter but leaves two optional parameters undocumented, failing to fully compensate for the lack of 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 a specific verb ('Search'), a resource ('installed apps'), and the search criteria ('by name or package'). It also specifies the output ('ranked candidates with scores'), making its purpose unambiguous and easily distinguishable from siblings like list_apps or launch_app.

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 usage when you need to find an app by name or package, but it does not explicitly state when to prefer this over alternatives like list_apps, nor does it mention any exclusions or prerequisites. The context is clear but the guidance is not 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 reveals that screen pixels are ephemeral ('the pixels are gone next turn'), which is a useful context for note-taking. However, it does not disclose other behavioral aspects such as side effects of updating a step, whether the change is reversible, or any permission requirements. It adds some value but remains thin for a state-changing 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?

Two sentences with no wasted words. The purpose is front-loaded, and the note guidance is appended efficiently. Every sentence adds value, and the structure is clean and scannable.

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 4 parameters, no schema descriptions, and no annotations. The description covers purpose and the ephemeral screen context, but it omits parameter meanings for index and device, and doesn't describe expected behavior beyond the status update. While an output schema exists (which might define return values), the input semantics are incomplete. For a tool of this complexity, more context is needed.

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 explain parameter meanings. It covers 'status' by listing allowed values and explains 'note' as a place to put facts from the screen. However, it does not explain 'index' (likely the step number) or 'device' (which device to target), leaving two of four parameters ambiguous. The partial coverage is insufficient for a tool with no 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 'Update a plan step' with a specific list of valid status values (pending, in_progress, done, skipped, failed). This is a specific verb-resource pair that distinguishes it from sibling tools like set_plan (which likely creates a plan) and record_finding (which records findings). The purpose is unambiguous.

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

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

The description implies when to use it (when updating a plan step's status) but provides no explicit guidance on alternatives or when not to use it. It does offer a practical hint about using 'note' for facts read off the screen, which is a usage consideration, but it doesn't contrast with other plan-related tools like set_plan or record_finding. Clear context exists, but no exclusions or alternative routing.

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, and the description does not disclose whether this sends a key to a default media session, requires active playback, changes state, or returns errors. It essentially restates the command and its options without explaining behavioral consequences.

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 a compact list of valid actions. There is no filler, repetition, or unnecessary detail.

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

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

The tool is simple and an output schema exists, so return-value details are not needed. However, the optional device parameter and the behavioral effects of sending a media key are not addressed, which leaves some ambiguity for correct invocation on a specific device.

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 the action parameter by listing valid values that are not represented as an enum in the schema. However, it never explains the device parameter or its null default, and with 0% schema description coverage, device semantics are left entirely 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 uses a specific verb ('Send') with a clear resource ('a media key') and enumerates the valid key actions, making its purpose immediately understandable. It does not explicitly differentiate from sibling tools like press or volume controls, but the listed media key names are distinctive enough.

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

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

There is no guidance on when to use this tool versus alternatives such as press, volume_up, or get_media_sessions. The intended context is only implied by the action list, with no exclusions or conditions described.

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 transparency burden. It usefully discloses that muting sets volume to 0 and remembers the previous level, which explains how unmuting restores it. However, it does not mention behavior around the device parameter, current mute state, or potential 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 a single efficient sentence with no wasted words. The key behavioral note about remembering the previous volume level is front-loaded, though 'music stream' could be more precise.

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 0% param coverage, the description is too sparse for an agent to confidently invoke the tool. It omits how to specify unmute, what device does, and when this tool is appropriate versus media siblings. The presence of an output schema reduces the need to explain return values, but the missing parameter and usage context remain significant gaps.

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

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

Schema description coverage is 0%, so the description must compensate but does not. The mute/unmute wording loosely implies the 'muted' boolean, but the 'device' parameter is entirely undocumented, leaving an agent without essential parameter meaning.

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

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

The description clearly states the tool's action: muting or unmuting the music stream. It identifies a specific verb and resource, making it distinguishable from volume_up and volume_down siblings, though it does not name those alternatives explicitly.

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

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

No guidance is provided about when to use this tool versus volume_up, volume_down, or media_control. The description simply states the action without contextual conditions or 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 burden. It usefully discloses that the operation is best-effort and drives the notification shade, and that reply_text sends an inline reply. However, it omits important behavioral context such as prerequisites, failure modes, or 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 compact and front-loaded with the core purpose, followed by a clarifying example and a brief caveat. Every sentence contributes meaningful information without repetition or 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 tool with six parameters, zero schema descriptions, and no annotations, this description is incomplete. An agent cannot confidently determine how to identify the target notification using key/title/package, nor understand the limitations of the best-effort behavior beyond a vague hint.

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 only explains reply_text and gives examples for action. The key, title, device, and package parameters are left completely unexplained, which is a significant gap since they likely determine which notification is targeted.

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: 'Tap one of a notification's own buttons' with concrete examples like reply, archive, and stop. This clearly differentiates it from generic tapping or notification dismissal tools, though it does not name a sibling tool 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 intended use is implied: use when you need to click a notification's embedded action button, and reply_text is for inline replies. However, there is no explicit guidance on when not to use it or which alternative to choose, such as dismiss_notification or type_text.

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 must fully disclose behavior. It only states the action and package role, without mentioning error handling, prerequisites (e.g., app installed), side effects, or return behavior. For a tool that opens external screens, this is a significant 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 concise sentence with no filler. It is front-loaded with the core action and the package qualifier. However, it is almost too brief, missing important details, so it doesn't earn a 5.

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

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

With 3 parameters (only one required), no schema descriptions, and no annotations, the description is far from complete. It doesn't explain what happens on success or failure, how the device parameter affects execution, or the exact URI format. Even with an output schema present, the description lacks critical context for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'package pins the target app' but leaves 'uri' and 'device' entirely unexplained. The description adds minimal value beyond the schema's field names, failing to clarify URI format or device selection.

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

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

The description clearly states the tool's function: jumping to a screen via URI or intent action, with package pinning the target app. It uses a specific verb (jump) and resource (screen), and the 'package pins' detail adds specificity. However, it doesn't explicitly distinguish itself from sibling tools like launch_app or start_app, which also handle app opening, so it falls 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 on when to use this tool versus alternatives. It doesn't mention conditions like 'use when you have a URI' or 'prefer over launch_app for deep links'. The description is purely declarative and leaves the agent to infer usage context from the name and basic action.

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 of behavioral disclosure. It reveals that the file is handed off to whatever app handles its type, which is useful, but it does not mention side effects, permissions, whether the app opens visibly, or what happens if the file type has no handler. This is a significant gap for a tool that triggers external 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, front-loaded sentence with no filler. It is appropriately concise for a simple tool, though the brevity comes at the cost of important behavioral and parameter context.

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

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

With no annotations, 0% parameter schema coverage, and an output schema that is not described in the text, the description leaves too much unexplained. It does not cover device targeting, failure modes, or the implications of launching an external app. A basic agent might invoke it correctly by name, but it would lack the context needed to use it safely and effectively.

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 indirectly clarifies that path refers to the file to open, but it says nothing about the optional device parameter or how device selection affects the operation. The schema's raw types and default do little to explain the semantics, leaving the agent under-informed.

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

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

The description states a clear verb and resource: it opens a file using the system's default handler for that file type. It is distinguishable from sibling tools like launch_app and open_deeplink because it focuses on file paths rather than apps or links. It does not explicitly call out sibling tools, but the action is unambiguous.

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

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

The description implies the tool is for opening an existing file, but gives no guidance about when to prefer it over find_files, launch_app, or open_deeplink. There are no explicit conditions, exclusions, or alternative recommendations, so an agent must infer the appropriate context.

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

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

No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects, prerequisites (e.g., device must be awake), or what happens if no recent apps exist. The optional 'device' parameter hints at multi-device support but the description doesn't explain behavior across devices.

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 short sentence with no wasted words. It is front-loaded with the action. However, it is so brief that it sacrifices useful context, but for what it contains, it is concise.

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 an output schema and one optional parameter, the description is minimal. It lacks context about device targeting, prerequisites, and expected outcomes. The output schema may cover return values, but the description doesn't help an agent understand when or how to invoke this 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 0%, and the description does not explain the 'device' parameter at all. The schema shows it's an optional string/null with a default of null, but the description adds no meaning about what device values are valid or how the parameter affects behavior.

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 ('Open') and resource ('recent-apps overview'), which clearly identifies the tool's function. It distinguishes it from sibling tools like launch_app or open_deeplink, though it doesn't explicitly name 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?

No guidance is provided on when to use this tool versus alternatives like launch_app, press_home, or system_intent. The context is implied by the name and description, but there is no explicit when-to-use or when-not-to-use information.

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

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

No annotations are provided, so the description carries the full burden. It discloses that ids are single-use and go stale after any action, and explains the ocr modes including the 'auto' condition. These are genuine behavioral details beyond a simple 'captures screen' statement, but it omits permission requirements and return format.

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

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

The description is compact—three sentences with no filler. The main function is front-loaded, followed by the critical staleness warning and the ocr parameter semantics. Every sentence serves a distinct purpose.

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

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

A 5-parameter tool with no annotations and no output schema demands more context. The description explains the tool's purpose but fails to cover the meaning of most parameters and does not describe the return structure of the annotated screenshot or marks. This is a significant gap for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for all 5 parameters. It explains 'ocr' semantics (auto/always/never) but leaves lang, device, max_marks, and include_image completely unexplained, providing minimal help for an agent selecting parameter values.

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

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

Description states a specific verb (Capture), resource (screen), and output (numbered marks plus annotated screenshot). It clearly differentiates from sibling tools like get_screenshot (plain screenshot) and get_ui_tree (tree only) by promising interactive som_ids for tappable/readable items.

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 doesn't explicitly name alternatives or when-not-to-use conditions. It implies usage when interactive elements with ids are needed, but lacks explicit comparison to get_screenshot or read_screen. The ocr explanation gives parameter guidance but not tool-selection 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?

Since no annotations are provided, the description carries the full behavioral burden. It communicates that this is a read-only reachability check and names the return value, but it does not disclose prerequisites, what the optional device parameter changes, or any connectivity/network caveats. Adequate for a simple ping, but not rich.

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 entire description is one front-loaded, efficient sentence with no filler. It leads with the purpose and immediately follows with the key return value, making every word useful.

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 one optional parameter and an output schema, this is close to minimum viable. However, the missing parameter meaning and lack of sibling usage guidance leave a visible gap; the description alone may not fully prepare an agent to select or invoke it correctly in all contexts.

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 does not mention the `device` parameter at all. The agent is left to infer what a string value means and what `null` default does. The parameter name gives a weak semantic clue, but the description fails to connect it to the 'Mobilerun Portal' check.

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 a specific action ('is the Mobilerun Portal reachable?') and the key return value ('its transport (http or content_provider)'), which makes the tool's job unambiguous. It does not explicitly name a sibling alternative, but the check-and-transport phrasing is distinctive enough to separate it from general device-status or connection 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 given about when to use this tool versus alternatives such as get_device_status or connect_device. The description implies a reachability check but provides no context, exclusions, or preferred scenarios, leaving the agent to infer applicability from the tool name.

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