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

With no annotations, the description carries the full burden. It usefully discloses that all app data is deleted and that the app is stopped, but it omits whether the deletion is irreversible, what permissions or confirmations are required, and how failures are handled.

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 compact sentence delivers the destructive action, the fresh-install analogy, and the stop side effect with no wasted text. It is front-loaded and appropriately sized.

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 destructive operation with no annotations and no output schema, the description covers the core action and side effect but leaves important operational gaps: reversibility, error behavior, and confirmation requirements are unstated.

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 50%: serial is documented in the schema, while package has no schema description. The tool description maps package to the target app, but does not add package format details or explain device-selection behavior beyond what the schema already implies.

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

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

The description states a specific verb and resource: deleting all app data, compared to a fresh install, and also stopping the app. It is clear enough to distinguish from stop_app, but it does not explicitly name or contrast sibling 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 phrase 'like a fresh install' implies the reset use case, but there is no explicit guidance on when to use this instead of stop_app or launch_app, and no exclusions or prerequisites are stated.

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

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

No annotations exist, so the description carries the full behavioral burden and does not meet it. It never states that this is a side-effect-free read, what happens when no app is foreground (home screen/launcher), or whether it errors with multiple devices attached — all relevant for an adb-backed tool.

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

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

A single seven-word sentence with no filler, front-loading the key output concepts. It is a sentence fragment rather than a complete statement of purpose, which keeps it just short of ideal.

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

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

With no annotations and no output schema, the description must supply both safety profile and return shape. It hints at the return shape (package + activity) but omits the no-foreground-app case and any device-selection caveat, leaving a simple tool only minimally covered.

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

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

Schema description coverage is 100% and the single optional `serial` parameter is fully documented in the schema ('optional when exactly one device is connected'). The description adds nothing about parameters, so the baseline 3 applies.

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

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

The description states the information the tool surfaces (foreground package and activity), which is a real clarification over the bare name 'current_app'. However it is a noun phrase with no verb, and it does nothing to distinguish itself from siblings like get_screen_info, get_ui, or list_dev_apps, so an agent must infer that this is the read-only foreground-app lookup.

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

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

There is no when-to-use guidance at all: no statement of the scenario this answers ('which app is on screen right now?'), no contrast with get_screen_info or list_dev_apps, and no mention of prerequisites such as a connected device. The agent is left to infer placement from the name 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?

With no annotations, the description carries the full behavioral burden. It discloses the returned content (header and stack trace), but does not clarify read-only behavior, device-selection requirements, or how max_lines may truncate the claimed 'complete' stack trace.

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 states the tool's scope and return content without wasted words. It is appropriately sized for the core 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?

There is no output schema and two of four parameters lack schema descriptions, so the description should do more to explain package and max_lines. It summarizes the returned report but leaves important invocation details unspecified.

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

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

Schema description coverage is only 50%, and the description does not compensate by explaining the required package parameter or the max_lines behavior. It only loosely connects the id to list_crashes, which is already documented in the schema.

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

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

The description clearly identifies the resource as one crash report and distinguishes it from the sibling list_crashes by emphasizing a single crash and full detail. It lacks an explicit retrieval verb, but the intended action 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?

The phrase 'from list_crashes' implies this tool should be used after obtaining a crash id from the listing tool. However, it does not explicitly state when to use this instead of alternatives, nor does it mention any exclusions or prerequisites beyond the schema.

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 does not say whether the tool is read-only, whether it has side effects, what the return format looks like, or what happens if zero or multiple devices are connected; only the returned data categories are listed.

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, but the fragmentary phrasing leaves out the action verb and makes it read as a label rather than a complete tool description. It is concise but under-specified.

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 no output schema, the description should explain device-selection behavior, what is returned and in what form, and how it relates to current_app. It lists the data categories but omits the operational context needed to invoke it confidently.

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

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

The single optional serial parameter is fully described in the schema, including the one-device shortcut. The description adds no parameter meaning beyond that, so the baseline score of 3 is appropriate.

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

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

The description names a clear resource and enumerates what the tool reports: screen size, density, coordinate scale, and foreground app. But it is a noun phrase with no verb, and it does not distinguish this tool from siblings like current_app, which also exposes foreground-app information.

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 call this tool versus current_app or screenshot, nor on when device selection matters. The description simply states what information is available, leaving the agent to infer usage from the name 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?

With no annotations the description carries the full burden, and it does disclose real behavior: ref is stable across calls and the call degrades to a screenshot when no tree exists. It omits anything about device/connection requirements (e.g. adb serial resolution) or failure modes beyond the fallback.

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

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

Three compact clauses, front-loaded with the return shape and with no filler. The middle clause about targeting elements is utility-oriented toward other tools but still 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?

No output schema exists, so the description must describe the return value, and it does so field by field, including the stability guarantee for refs and the screenshot fallback. For a two-optional-param read tool that is nearly complete; only connection/permission preconditions are absent.

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

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

Schema description coverage is 100%, so both parameters ('all' for layout-only nodes and 'serial') are already documented in the schema. The description adds nothing about either parameter; its 'ref (index), text or id' clause describes output addressing, not input arguments.

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

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

Names a specific resource ('the visible UI') and the exact shape of what comes back (a list of elements with ref/text/desc/id/centre/size/flags), which lets an agent tell it apart from screenshot or get_screen_info. It stops short of an explicit verb form ('get') and never names the sibling to prefer in a given situation.

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 rather than stated: 'Target elements by ref (index), text or id' tells the agent how the result feeds into tap/scroll, and the screenshot fallback hints at when the tree is unavailable. There is no explicit 'use this instead of screenshot when...' routing or precondition for calling 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 carries the full burden. It says nothing about whether the call waits for the app to settle, what happens on a blocked/unknown package, or that the default observe=changes returns a screen diff — behaviorally the most important thing an agent needs to know before calling.

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 front-loaded sentence with no filler; the parenthetical 'its launcher activity' efficiently explains the default. Slightly dense but every clause earns its place.

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

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

A 5-parameter action tool with no annotations and no output schema needs to explain the observe/settle_ms contract and failure modes; the description covers only the launch target. An agent cannot predict the return payload or error behavior.

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

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

Schema coverage is 80%, so parameters are well documented structurally. The description adds one useful mapping (package → launcher activity, activity → specific activity) but says nothing about serial, observe, or settle_ms beyond the schema.

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

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

States a specific verb+resource (launch an app) and clarifies the two modes: default launcher activity vs. an explicitly named activity. The 'allowed dev app' phrasing hints at a restriction that separates it from generic launchers, but it never names the sibling it replaces (e.g., open_url, start_emulator).

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 statement of when to use this rather than open_url, start_emulator, or list_dev_apps, and no note on what happens if the package isn't 'allowed'. Usage is only inferable from the phrase 'allowed dev 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 must carry full behavioral burden. It discloses several useful traits: newest-first ordering, inclusion of exception and top frame, and persistence across process restarts and logcat rotation. It does not disclose read-only safety, pagination/limit behavior, whether reports are collected on demand, or the response shape beyond two fields.

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 tightly packed sentences with no wasted text; the key scope and ordering facts are front-loaded and the survival trait is stated as supporting 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?

The tool has five parameters, one required, no output schema, and no annotations. The description omits the required package argument entirely and gives no guidance on limit, types, or since_minutes filtering, leaving an agent unable to construct a correct call from the description 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 only 40%: serial and since_minutes are documented in the schema, while limit, types, and package are not. The description does not compensate by explaining the required package argument, the default/maximum of limit, or how the types array filters crash categories. It only loosely names the crash kinds.

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

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

The description gives a specific verb and resource ('List recorded crashes, ANRs and native crashes'), its scope ('of a dev app'), and what each entry contains ('exception and top frame'). It implicitly distinguishes itself from logcat ('survive the process and logcat rotation') but never mentions the sibling get_crash, which is the most likely confusion point.

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 'Reports survive the process and logcat rotation' implies when this is useful over logcat, but there is no explicit when-to-use guidance, no exclusions, and no mention of get_crash as the alternative for a single detailed crash.

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

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

With no annotations present, the description carries the full load and does disclose the most important behavioral trait: the result is filtered to debuggable, testOnly, adb-installed builds, so it is not an enumeration of all installed apps. It does not say whether the call is read-only or what happens on a device that permits none of these builds, which are minor remaining 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?

Two short sentences, front-loaded with the verb and resource, then the eligibility constraint. No filler, though the 'Android Studio (Run)' parenthetical phrasing is slightly dense compared with simply saying 'debuggable and testOnly'.

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

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

For a one-optional-param read-only listing tool with no output schema, the definition covers what is listed and what qualifies. It stops short of describing returned fields or multi-device behavior, but an agent can call it correctly with what is here.

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

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

Schema coverage is 100% and the single optional serial parameter is fully documented in the schema, so the schema does the work. The description adds nothing about serial or multi-device selection; baseline 3 applies.

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

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

States a specific verb (list) and resource (apps this server may use), and the second sentence narrows it to debuggable + testOnly builds installed via adb, so an agent can tell it apart from current_app or launch_app. The name is a little ambiguous (dev apps vs. all installed apps) but the description resolves it.

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 criterion for inclusion is given, which implies 'use this to discover which apps are launchable', but there is no explicit when-to-use/when-not framing or reference to a sibling such as current_app or launch_app. Usage is inferred rather than stated.

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

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

No annotations are provided, so the description carries the burden. The wording makes clear this is a read-only enumeration and clarifies that both emulators and physical devices are covered, but it says nothing about side effects (e.g. whether it starts the adb server) or the shape of the response.

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

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

A single front-loaded sentence with no filler. The key qualifiers ('connected', 'emulators and physical', 'available AVDs') are packed in without redundancy.

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

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

For a zero-parameter, read-only listing tool with no output schema and no annotations, the description tells an agent enough to call it and to know what categories of results to expect. A brief note on return format (e.g. device IDs and states) would make it fully complete.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly reflects a no-argument call and adds the useful scoping note that both connected devices and available AVDs are included.

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

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

The description gives a specific verb ('List') and two concrete resources ('connected adb devices' and 'available AVDs'), so an agent knows exactly what comes back. It does not explicitly contrast itself with siblings like start_emulator or list_dev_apps, which keeps it from a 5.

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

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

The usage context is only implied by the phrase 'connected' and 'available' – an agent can infer this is a discovery step before start_emulator or launch_app, but nothing states when to call it versus those alternatives or any preconditions.

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

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

With no annotations, the description carries the full burden and does disclose two genuinely non-obvious traits: crashed earlier processes' lines are included, and the default is incremental (new lines since the previous call with the same filters). It does not disclose first-call behavior when since_last=true, truncation via max_lines defaulting to 200, or whether the call blocks.

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, front-loaded with the core action, followed by the non-obvious default. No wasted clauses, though the incremental-behavior sentence could name the since_last parameter to link description to schema.

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

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

A six-parameter read tool with no annotations and no output schema. The description covers scope and the incremental default, but leaves gaps an agent needs: return line format, what happens on the first call, truncation behavior at max_lines, and prerequisites on the target app.

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 50% (grep, level, serial documented; package, max_lines, since_last undocumented). The description compensates for since_last by explaining the incremental default and the 'same filters' scoping, but adds nothing about package, max_lines truncation, or the device serial resolution.

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: 'Read the log of an allowed dev app'. The parenthetical about crashed earlier processes adds scope detail, and 'allowed dev app' signals a permission boundary. It does not explicitly distinguish itself from siblings like list_crashes/get_crash, which are the closest 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?

Usage is implied (inspect app log output) but there is no explicit statement of when to prefer this over list_crashes, get_crash, or read_all. The 'allowed dev app' phrasing hints at a precondition without spelling out the requirement to have the app installed/launched.

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

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

No annotations are provided, so the description carries the full burden and discloses nothing: no mention of mutation side effects, that reverting requires another action, or how the result is returned. The observe/settle_ms schema descriptions carry the disclosure work, but that is not the description's contribution.

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

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

A single front-loaded sentence with no filler, and the two targeting paths are presented in parallel. It is slightly under-specified rather than wasteful, since no timing or device context is mentioned.

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 11-parameter device-interaction tool with no annotations and no output schema needs more: device/serial selection, press duration behavior, and what the default 'changes' observation returns are all left unexplained. The description covers only target selection for a tool whose complexity is much broader.

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 82%, so the structured fields already explain most parameters, including the observe modes and settle_ms. The description only restates the identifier parameters and says nothing about duration_ms (which has no schema description) or the serial/device targeting, adding no meaning beyond the schema.

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

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

States a specific verb (long-press) plus both targeting strategies: element by index/text/id, or a raw screen point (x, y). This is clearly distinguishable from the sibling 'tap' and 'swipe' by the press duration, though no sibling is named explicitly.

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

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

Usage is only implied: you use long_press when you need a sustained press. It never says when to prefer it over tap or swipe, nor does it state prerequisites such as calling get_ui first to obtain an index, or the need for a screenshot for x/y targeting.

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

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

No annotations are provided, so the description carries the burden; it does disclose the delivery mechanism (ACTION_VIEW intent) and the 'allowed dev app' constraint, which is real behavioral context. It omits failure behavior for a disallowed package, whether the previous screen is replaced, and any permission prerequisites, which matters for a tool that mutates device UI 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?

One front-loaded sentence with the verb, resource, and mechanism, and zero filler. Nothing is repeated from schema or annotations.

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

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

With no annotations and no output schema, the description plus the rich observe parameter documentation covers how to call it and what to expect back. The remaining gap is error/whitelist behavior for the package argument, a modest omission rather than a blocking one.

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 80%: url, package, observe, and settle_ms are all documented in the schema, and the description adds nothing parameter-specific beyond implying package must be an 'allowed dev app'. Serial is undocumented in both places. Baseline 3 applies since the schema does the heavy lifting.

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 ('Open') and resource (URL / deep link) plus the mechanism (ACTION_VIEW intent), so the effect is unambiguous. It does not distinguish itself from the near-neighbor sibling launch_app, which also starts things in an app, leaving that discrimination to the agent.

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 word 'allowed' implies a package whitelist exists but never states how to check it (list_dev_apps is a sibling) or what happens for a disallowed package. No when-to-use vs launch_app or when-not guidance is given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It lists valid key values but does not disclose side effects, device requirements, whether key presses are state-changing, or how observation behavior works beyond what the schema already says.

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. The long enumeration is necessary for the key parameter, though it dominates the description and leaves no room for usage or behavioral 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?

For a simple key-press tool with schema-documented optional parameters, the description covers the required key values adequately. However, with no annotations and no output schema, it should do more to explain usage context and behavioral effects.

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 75%, and the key parameter has no schema description. The description compensates by enumerating accepted key strings and KEYCODE_* forms, which is meaningful input guidance beyond the schema. The remaining optional parameters are already described in the schema.

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

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

The description states a specific verb and resource ('Press a key') and enumerates accepted key names, making the resource concrete. It does not explicitly distinguish itself from siblings like type_text or tap, but the hardware/navigation-key framing is 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?

There is no guidance on when to use this tool versus tap, type_text, or other input tools. The list of valid keys implies hardware/navigation key usage, but no alternatives or exclusions are stated.

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

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

With no annotations, the description usefully discloses a side effect: the list is left scrolled to the end afterwards, which is a real state change an agent must account for. However, it omits what happens when max_scrolls is reached (truncated/partial results?), whether the read can fail or time out on endless lists, and any cost or rate implications beyond 'cheaper'.

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

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

Three short sentences, front-loaded with what the tool does, then the cost comparison, then the side effect. Nothing is redundant or padded.

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

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

For a zero-required-parameter read tool with no output schema, the description conveys outcome, ordering, cost benefit, and post-state. The remaining gap is the interaction between max_scrolls and result completeness, plus the shape of the returned entries, which keeps it from a 5.

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 50%: index and serial are documented, while direction and max_scrolls are not. The description doesn't compensate—it never mentions direction or explains that max_scrolls (default 20, cap 50) bounds how far it scrolls and hence whether the returned list is complete. Baseline 3 fits given the partial schema coverage and marginal added 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 names a specific verb and resource ('Read a whole scrollable list or form') and specifies the outcome ('returns every entry it contains, in order'). It implicitly separates itself from step-by-step scrolling, but never explicitly contrasts with siblings that also expose on-screen content, notably get_ui or scroll.

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

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

It gives a clear condition for use: read an entire list/form in one call rather than scrolling repeatedly, which is the key decision an agent faces. There are no explicit exclusions (e.g., don't use on infinite or extremely long lists), so it falls short of a full when/when-not treatment.

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 disclosure burden and does well: it warns about token cost relative to get_ui and flags the critical coordinate-frame trap that a crop's pixels are NOT screen coordinates. It does not mention multi-device behavior or failure modes, but the important behavioral caveats are present.

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

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

Three short sentences, front-loaded with the action and cost signal, then the coordinate rule, then the region nuance. Nothing is redundant and every clause carries decision-relevant 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?

There is no output schema, and the description adequately implies an image result plus the coordinate frame of the returned pixels, which is the main ambiguity for a screenshot tool. Minor gaps remain around serial/device selection and resolution behavior, but they are documented in the schema.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds real meaning the schema lacks: region produces a sharper crop rather than a resized image, and the returned crop's pixel frame differs from screen coordinates. That resolves the most likely misuse of the region parameter.

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

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

Starts with a specific verb+resource ("Take a screenshot") and immediately distinguishes itself from the sibling get_ui by stating the cost/benefit tradeoff. An agent can pick between the two without opening either schema.

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

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

Explicit when-to-use guidance: cheaper get_ui is the default, screenshot is for "visuals the tree lacks", and region is for "reading small text". The alternative and the conditions that select it are both named.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses target-resolution fallbacks (largest scrollable element, screen centre only when no UI tree exists), which is real behavioral context. It does not mention what happens at list boundaries, whether the gesture settles before observing, or that the default 'observe' returns a diff rather than a full tree – that last point lives only 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 front-loaded sentence with the direction semantic up front and target fallback in a parenthetical. Dense but every clause carries information; the nested parenthetical is slightly hard to parse but not wasteful.

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

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

For a 6-parameter, no-annotation, no-output-schema tool, the description covers target selection and direction well. It leaves the observation/return behavior entirely to the schema and says nothing about boundary conditions or device serial implications, so an agent calling it blind has minor 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 coverage is 83%, so the baseline is 3, but the description adds genuine meaning for the two most important semantics: the direction mapping and what 'index' selects when omitted. That added context for the default/fallback behavior goes beyond the schema's '[ref] of the scrollable element'.

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 ('scroll the content in a direction') and immediately clarifies the direction semantic ('down = reveal content below'). It also spells out target resolution (given index, else largest scrollable element, else screen centre), which is more than the name conveys. It does not distinguish itself from the sibling 'swipe', which is the obvious nearby alternative.

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

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

Usage is implied by the direction/target explanation, but there is no explicit guidance on when to reach for scroll rather than swipe or press_key, nor any prerequisite or exclusion notes. An agent can infer the intent but must decide on its own between this and the swipe sibling.

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 full burden; it does convey that this mutates device display state and is reversible via the auto option. It omits permission/authorization needs, persistence across reboots, and side effects on running apps, which are the remaining behavioral facts an agent would need.

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

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

A single front-loaded sentence with zero filler that covers the full behavior set. Nothing to trim, nothing buried.

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

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

For a simple 4-param setter with no output schema, the schema itself handles return-shape concerns via the 'observe' enum, so the description's shortfall is limited. Still, it leaves device targeting, side effects, and permissions to inference, which leaves the definition adequate rather than complete.

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

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

Schema coverage is 75% and the schema already documents serial, observe, and settle_ms thoroughly. The description adds only one piece of meaning beyond the schema: that 'auto' means re-enabling auto-rotation, which maps the enum to intent — helpful but marginal, so baseline 3 is right.

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 ('lock the screen to portrait or landscape') and enumerates the reversible alternative ('re-enable auto-rotation'), covering all three enum values. It doesn't differentiate itself from any sibling, though none of the listed siblings overlap in the orientation domain.

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 mutating action implies when it is relevant, but there is no explicit guidance on prerequisites, when not to use it, or how it relates to read-only siblings like get_screen_info or screenshot. The agent must infer the context of use.

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

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

With no annotations, the description does disclose the two most important traits: it blocks until boot completes and it is idempotent. It omits failure behavior (nonexistent AVD, boot timeout), approximate duration, and whether the emulator persists after the call returns — gaps that matter for an unattended mutation 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?

Two sentences, no filler, with the blocking/idempotency behavior front-loaded immediately after the purpose statement. Nothing to trim.

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

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

No output schema and no annotations, so the description must carry the whole load. It covers the happy path and idempotency but leaves out the return value (if any), error/timeout conditions, and side effects such as a lingering emulator process — meaningful omissions for a long-running start operation.

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

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

Schema coverage is 100% and each of the three parameters carries its own description, including the cross-reference to list_devices for the AVD name. The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (start) and resource (Android emulator / AVD) plus the post-condition ('wait until it has booted'), which makes it trivially distinguishable from siblings like launch_app (app) or list_devices (enumeration). The idempotency clause further pins down the semantics.

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 'returns immediately if it is already running' line implies it is safe to call unconditionally, but there is no explicit guidance on when to prefer it over alternatives, no stated prerequisites (AVD must already exist — only implied via the schema's 'from list_devices'), and no note on whether it must precede screenshot/tap calls.

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

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

No annotations are provided, so the description carries the full behavioral burden. "Force-stop" implies a forced termination, but the description does not disclose side effects such as unsaved state loss, permission requirements, or error 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 wasted words. It is structurally clean, though its extreme brevity contributes to gaps in other dimensions.

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

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

For a mutation tool with no annotations, no output schema, and incomplete parameter documentation, the description is too sparse. It should explain required inputs, device selection behavior, and the consequences of force-stopping an app.

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

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

Schema description coverage is only 50%, and the required `package` parameter has no schema description. The description says "an app" but adds no format details for `package` and does not mention the optional `serial` parameter.

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

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

The description states a specific verb and resource: "Force-stop an app." This clearly distinguishes it from siblings like launch_app or clear_app_data, though it does not explicitly name those alternatives.

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

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

The description gives no guidance on when to use this tool versus alternatives such as clear_app_data or launch_app, and it omits prerequisites like device selection. The intended usage is only implied by the verb "force-stop".

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 slow swipes act as drags, but it does not state that this mutates UI state, requires a connected device, or that behavior may depend on the observe parameter.

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

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

Two short sentences, front-loaded with the core action and followed by the one non-obvious behavioral caveat. There is no wasted text.

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

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

For an 8-parameter UI gesture tool with no annotations and no output schema, the description is thin. The observe parameter's schema documentation covers return behavior, but the description should still mention coordinate assumptions and device requirements.

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

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

Schema coverage is only 38%, but the description adds a key semantic detail not present in the schema: duration >= 1000 changes the gesture into a drag. It does not clarify coordinate space, screen-relative units, or how from/to points interact with device resolution.

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: 'Swipe/drag from one screen point to another.' It is clearly a gesture tool, but it never names or differentiates itself from siblings such as tap, long_press, or scroll, leaving the agent to infer the boundary.

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 drag threshold ('duration >= 1000') gives useful implied usage guidance for turning a swipe into a drag. However, there is no explicit when-to-use guidance versus tap, long_press, or scroll, and no prerequisites or exclusions are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose that tapping mutates UI state, whether it waits for settle, what observe mode defaults to, how multi-device serial selection works, or what happens when multiple elements match; the schema covers some of this but the natural-language description adds almost nothing.

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

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

A single front-loaded sentence that names the action and its two targeting approaches with no wasted words. It is efficiently sized for an agent scanning tool descriptions.

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

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

For a 10-parameter interaction tool with no annotations and no output schema, the description is too sparse. It omits behavioral context about device selection, observation defaults, settling, match resolution, and side effects, leaving the agent to infer important interaction semantics from the schema 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 description coverage is 90%, so parameters such as observe, settle_ms, exact, occurrence, and serial are already well documented in the schema. The description repeats the targeting modes (index, text, id, x/y) but adds no meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb and resource (tap an element or screen point) and names the targeting modes (index, text, id, x/y). It is clearly distinguishable from long_press and swipe by virtue of being a tap, but it does not explicitly call out those sibling boundaries.

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 lists possible targeting modes but gives no guidance on when to use tap versus long_press, swipe, or scroll, nor whether get_ui should be called first to obtain an element ref. It provides no exclusions or prerequisites.

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

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

With no annotations, the description must carry behavioral burden; it usefully discloses that a target can be tapped first, cleared, and that enter can be pressed afterwards. It omits other consequential behaviors present in the schema — observation mode (changes/ui/screenshot), settle delay, multi-match disambiguation, and device targeting — and doesn't say what happens if the target isn't found.

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, front-loaded with the core action, zero filler. Every clause maps to an actual capability in the schema.

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

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

Hmm — reconsider: 13 params, no annotations, no output schema. The description covers the core flow and the schema covers all field semantics richly (92%). Missing: failure behavior and the observe-mode return shape, but observe is fully described in-schema. This is arguably a 4.

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 92%, so parameters are already well documented; baseline is 3. The description adds a coherent framing of the targeting→clear→submit sequence but no details beyond the schema's own field 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?

States a specific verb and resource ('Type text into the focused field') and names the optional targeting step. It is distinguishable from siblings like tap or press_key, though it doesn't spell out the relationship to those tools 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?

Implies usage ('into the focused field', optionally tap a target first to focus it), which gives an agent a workable mental model. However, there is no explicit guidance on when to use this vs. press_key/tap or what to do when no field is focused.

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 states the core wait-for-appear/disappear behavior, but omits critical traits: timeout behavior, default timeout, observe output, exact-match semantics, device-selection via serial, and what happens on timeout.

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

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

The description is one tight sentence with no filler and the wait condition is front-loaded. It could be slightly more structured by grouping parameter-related behavior, but it is efficiently written.

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 7-parameter tool with no annotations, no output schema, and only 14% schema description coverage, this single sentence is not complete enough. An agent lacks essential details about timeout, observe, exact matching, serial selection, and return behavior.

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

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

Schema description coverage is 14%, so the description should compensate. It clarifies only text/id targeting and gone=true meaning, while exact, serial, observe, and timeout_ms receive no explanation beyond their bare schema entries.

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: wait for an element identified by text/id, with an optional gone=true inversion. It is clear what the tool does, but it does not explicitly distinguish itself from siblings like get_ui or screenshot.

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

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

The description only explains the wait condition. It gives no guidance on when to use this instead of get_ui, screenshot, or other sibling tools, and no exclusions or prerequisites are provided.

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