Robot Actions — Remote Device Control

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

With no annotations provided, the description carries the full burden and does so well: it discloses that memory is persistent, auto-prepended to the system prompt on every chat, capped at 10240 bytes, and that over-cap appends return 413. It also gives content guidance (Markdown encouraged, terse and factual). This goes well beyond the schema and gives the agent a clear picture of side effects and constraints.

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

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

Three dense sentences with no wasted words. The core action is front-loaded, and the usage triggers, negative guidance, persistence behavior, cap, error code, and content style are all packed efficiently. Every sentence earns its place.

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

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

For a single-parameter tool with no annotations and no output schema, this description is remarkably complete. It covers when to use it, what it does, the persistence side effect, size constraints, failure mode, and content guidance. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by advising Markdown and specifying the desired content style ('terse and factual', 'preferences, project context, references'). This helps the agent compose the block parameter appropriately, though it doesn't add technical parameter details like encoding or length.

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: 'Append a block to the calling user's persistent agent memory.' It clearly distinguishes itself from the sibling agent_memory_replace by using 'append' and describing the persistent memory context. No ambiguity about what the tool does.

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

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

The description gives explicit trigger conditions: use when the user says 'remember X', 'save this', or 'note for next time', and explicitly warns DO NOT auto-update on every interaction. It does not explicitly name agent_memory_replace as the alternative for overwriting existing memory, but the append-versus-replace distinction is largely implied by the tool names and action verb.

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. It discloses the 10240-byte cap, the 413 over-cap response, and the warning that replace is riskier than append. It does not explicitly state that all previous memory content is discarded, but 'replace the entire memory file' strongly implies it.

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 sentences with no filler: the operation, the usage warning, the trigger conditions, and the cap/error are all packed in. The most important guidance is front-loaded with 'USE SPARINGLY.'

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 single-parameter tool with no output schema, the description provides everything needed: what it does, when to use it, when not to use it, the size limit, and the failure response. No critical context appears missing.

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

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

The schema already documents the single 'content' parameter at 100% coverage, including its Markdown format and the empty-string-to-clear behavior. The description reinforces that the content replaces the entire file and adds context about size limits, but it does not add substantial parameter 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?

The description states a specific verb and resource: 'Replace the entire memory file for the calling user.' It also distinguishes itself from the append alternative by explicitly calling append 'the safer primary,' so an agent can tell the two operations apart.

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

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

Usage guidance is explicit and actionable: 'USE SPARINGLY,' append is preferred, and replace should only be called when memory has drifted wrong, accumulated stale entries, or the user requests a clean rewrite. This clearly routes the agent between replace and append.

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 so exceptionally. It openly states that results are 'a screening signal, not a verdict,' documents that only on-screen elements are examined, explains the ancestor-touch-dispatch blind spot, and discloses that scroll mode changes the screen (further detailed in the schema). It also explains WHY contrast/text-size are excluded, which lets the agent set correct expectations.

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

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

The description is long but well-structured and front-loaded: purpose first, then checks, then usage, then a clearly marked 'IMPORTANT LIMITS' section. The prose list of the six checks partially duplicates the schema's enum descriptions, which is a slight inefficiency, but every other sentence earns its place by adding operational or interpretive value.

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

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

For a complex tool with 5 parameters and no output schema, the description is remarkably complete. It explains prerequisites, the full scope of what is audited, what is deliberately not audited and why, how the scroll mode behaves, and — critically — what findings carry ('label, class and pixel rect') so the agent can act on results despite the absent 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?

Schema description coverage is 100%, so the baseline is 3. The description's prose enumeration of the six checks largely restates what the schema's enum descriptions already provide, and it adds nothing beyond the schema for udid, scroll, maxScrollSteps, or localeIsEnglish. The one modest addition is the note that each finding's rect centre is tappable, but that concerns output, not 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 opening sentence states a specific verb and resource: 'Run an accessibility audit on the CURRENT screen of an Android device.' The platform and scope are explicit, which distinguishes it from the sibling ios_accessibility_audit even without opening the schema. The subsequent enumeration of the six checks gives the agent a concrete sense of what the audit produces.

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 sequencing guidance: 'navigate to the screen you care about FIRST (device_tap_by_text / device_launch_app), then call this.' It also states when to pass scroll:true and explicitly lists exclusions ('Contrast and text-size are NOT checked'). It does not name an alternative tool for exclusion, but the platform and workflow context are clear enough.

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

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

With no annotations, the description carries the behavioral burden. It discloses the command, the averaging over N runs, and launcher-activity resolution. It stops short of stating that the -S flag force-stops the app and may disrupt running state, but the mechanism is explicit enough for an Android-aware agent.

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

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

One dense sentence front-loads the outcome and then supplies method and scope. No filler or repetition of schema content.

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

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

Given no output schema, it tells the agent what the metric is (ms, averaged) and how it is obtained. It lacks an explicit statement of which am start timing field is reported (e.g., TotalTime vs WaitTime) and the force-stop side effect, but remains sufficient for basic 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 100%, so the schema already explains pkg, runs, and serial meaning. The description's 'averaged over N runs' and launcher resolution reinforce the parameters but add no new semantic detail 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?

The description states a specific measurable outcome ('Cold app-launch time (ms)'), names the exact command mechanism ('am start -W -S'), and distinguishes itself from sibling performance tools by focusing on launch latency rather than FPS, traffic, or general snapshots.

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 clearly implies when to use it: whenever cold app-launch duration is needed. It does not explicitly name alternatives or exclusions (e.g., warm launch or rendering FPS), but the cold-launch qualifier and measurement description provide enough context to select it.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool reads from DropBoxManager and provides aggregate analytics, but it does not mention any side effects (likely none), whether it requires special permissions, or what the output structure looks like. Since it's an analytics/read operation, the description implicitly indicates no destructive behavior, but it doesn't explicitly state that. A more explicit note about being non-mutating would be better, but the current level is adequate.

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

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

The description is two sentences, front-loaded with the core purpose and scope, and ends with a routing hint to the sibling. Every word earns its place; no fluff or repetition. It is concise and structured effectively for quick scanning.

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

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

Given that this is a simple analytics tool with one parameter and no output schema, the description is nearly complete. It tells the agent what data it returns (aggregate stats across multiple dimensions) and when to use the sibling for detail. Missing is the exact return format or whether it returns a JSON object or table, but the tool's complexity is low, so the description is sufficient for correct invocation and basic understanding.

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% for the only parameter (serial), which is described as 'Android device serial (from `device_list`)'. The description does not add more parameter detail beyond the schema, but the schema is already explicit. Given the single parameter and complete schema coverage, the description adds little but the schema handles it well. A baseline of 3 would apply; however, the description's mention of DropBoxManager as a data source provides a bit of context not in the schema, slightly elevating it.

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

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

The description clearly states the tool's purpose: 'Crash / ANR / native-crash analytics from DropBoxManager', listing the dimensions of analysis (total, per-process, per-type, per-day timeline). It also specifies the data source (DropBoxManager), which distinguishes it from other crash-related tools like android_crash_detail. The verb 'analytics' is somewhat weak but the resource and scope are explicit, making it clear what the tool provides.

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 direct pointer to the sibling tool: 'Use android_crash_detail for one entry.' This clearly tells the agent when to use this tool (aggregate analytics) vs when to use the alternative (single entry detail). However, it does not explicitly state when to use this tool over other analytics tools like ios_crash_analytics (but that's platform-specific) or when not to use it (e.g., for real-time crashes). The context is clear enough for typical use.

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

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

No annotations are provided, so the description carries the burden. It states it returns 'full raw content,' implying a read operation, but does not explicitly say it is side-effect-free or describe any potential performance or payload size implications. It is not contradictory, but the absence of an explicit read-only declaration and any behavioral caveats keeps this at a mid-range score.

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 wasted words. It immediately states what the tool returns and how to obtain the required id, making it highly scannable for an agent.

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

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

For a simple retrieval tool, the description is sufficient: it explains the output ('full raw content') and the input source (id from android_crash_analytics). It does not describe pagination or size, but that is not critical for a detail fetch. The absence of an output schema is acceptable since the description clearly indicates the return type. It could explicitly mention it is a read-only operation, but that is implied by the nature of the tool.

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

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

The input schema already fully documents both parameters (id and serial) with descriptions that match the tool's purpose. The description reinforces that the id comes from android_crash_analytics, but adds no new semantic detail beyond the schema. With 100% schema coverage, the baseline 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 states a clear verb ('get') and specific resource ('full raw content of one crash/ANR/tombstone entry'), and identifies how to reference it ('by id from android_crash_analytics'). It differentiates itself from the sibling listing tool android_crash_analytics, making its purpose unambiguous.

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

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

The description explicitly tells the agent that the id comes from android_crash_analytics, implying a prerequisite workflow: first list crashes, then fetch detail. This provides clear guidance on when to use this tool versus the sibling listing tool, and the android-specific context differentiates it from the ios_crash_detail 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 provided, the description carries the full behavioral burden and does so thoroughly. It discloses the live-window limitation, cleanup of throttle/blockUrls/extraHeaders in finally blocks, body truncation caps (10k/200k chars), bodyError handling, dropped-record reporting, and output shape — all details the agent needs to predict side effects and return 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 dense but every sentence carries operational value; there is no filler or repetition of structured facts. It front-loads the core purpose and return contract, then organizes modifiers (bodies, throttle, blocking, limits, defaults) in a logical flow suited to a 13-parameter tool with no output 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?

Given the tool's complexity and the absence of both annotations and an output schema, the description is remarkably complete: it defines the record shape, failure modes, caps, cleanup behavior, defaults, maximums, and page selection. An agent has nearly everything needed to invoke it correctly and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful behavioral nuance beyond the schema: triggerJs must fire inside the window, blockUrls patterns can use wildcards, throttle is only active for the capture window, and limit/dropped-record behavior protects token budget. This lifts it above baseline.

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

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

The description opens with a specific verb+resource: "Capture network requests made by a page running on the device over a time window via CDP." It also clarifies scope distinctly from device-level or iOS traffic capture by emphasizing page-level CDP collection, which distinguishes it from siblings like android_traffic_start and ios_safari_capture_network.

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 extensive operational guidance: use triggerJs for race-free navigation/reload, set includeBodies=false for lighter payloads, filter via urlSubstring/onlyErrors, and omit pageId to auto-select the active page. It does not explicitly name alternative tools or state when to prefer a sibling, so it stops short of full alternative-based 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, so the description carries the burden, and it does disclose key behavioral traits: it states the return shape ({ closed, pageId }), what 'closed:false' means when no such page exists, and that it targets a device via CDP. It doesn't mention permission/auth needs or side effects, but for a simple close operation the disclosure is reasonably complete.

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 sentences are dense and purposeful: action and mechanism, use-case rationale, and return semantics. It is front-loaded with the core capability and includes no filler or redundant material.

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 close operation with 100% schema coverage and no output schema, the description covers the return contract and the key nuance (closed:false). It doesn't enumerate edge cases or error scenarios, but the core information needed to invoke it correctly is present and complete enough for this tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (udid, pageId, socket) with meaning. The description adds that pageId comes from android_devtools_list_pages, which is helpful, and mentions the CDP mechanism, but doesn't add significant semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Close') and resource ('a debuggable tab/page on the device by pageId'), explicitly references the CDP /json/close mechanism, and distinguishes itself from siblings like android_devtools_list_pages. An agent can tell exactly what this tool does without guessing.

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 says to use it 'to clean up stale tabs that accumulate across sessions and clutter android_devtools_list_pages', and tells the agent to get pageId from android_devtools_list_pages. This provides clear context, a use case, and an explicit source for the required 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 full burden and delivers richly: it discloses that the tool enables Runtime and Log domains, listens for three specific events, returns a normalized array, is a live-window collector that only captures post-attach events, has a ~1-3s attach latency race condition, and supports pageId auto-selection. This is exemplary behavioral disclosure.

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

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

The description is dense (~130 words) but every element is load-bearing: the live-window warning and triggerJs guidance are critical for correct use. It is front-loaded with the core purpose. Minor redundancy exists between the main race warning and the triggerJs parameter description, so it is not maximally tight, but it is 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?

For a 5-parameter tool with 100% schema coverage and no output schema, the description is complete: it documents the return shape ({ level, text, url?, lineNumber? }), the live-window semantics, defaults, maximum, and page auto-selection. There is no output schema and no annotations, yet the description covers everything an agent needs to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining that triggerJs runs INSIDE the collection window and is race-free, gives concrete examples ('location.reload()', 'console.log('probe')'), and cross-references the default/max window values that the schema also encodes. This meaningfully enriches parameter understanding, warranting a 4.

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: 'Collect console logs, exceptions, and log entries from a page running on the device for a time window.' It further distinguishes itself by naming the exact CDP domains and events (Runtime.consoleAPICalled, Runtime.exceptionThrown, Log.entryAdded) and the normalized return shape, which clearly separates it from siblings like android_devtools_capture_network, session_console_logs, and web_console_messages.

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 when-not guidance: triggering logging from a SEPARATE tool call 'races the ~1-3s attach latency and is silently missed,' and provides the corrective alternative: 'pass triggerJs (runs inside the window).' It also states the default (3000 ms), maximum (15000 ms), and page auto-selection behavior, leaving no ambiguity about how to invoke it correctly.

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

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

With no annotations to fall back on, the description carries the full burden and does it well. It discloses the CDP-based read path, the fallback to document.cookie with its httpOnly limitation, and the auto-selection behavior for pageId. These are non-obvious behavioral details that an agent needs before invoking the tool.

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

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

The description is three focused sentences with no filler. The core purpose and mechanism come first, followed by the fallback behavior and then the most important parameter guidance. Every sentence earns its place.

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

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

For a moderately complex DevTools utility with no output schema, the description covers the mechanism, the returned cookie attributes, the fallback limitation, and pageId selection. A small gap is that it does not point to how to obtain a pageId if auto-selection is not desired, but the schema's 'auto-picked' note partially mitigates this.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it repeats the auto-pick behavior already in the pageId schema description and does not elaborate on udid or socket. No compensatory parameter detail is needed because the schema is already complete.

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 ('Get cookies for a page on the device'), the mechanism (CDP Network.getCookies), and the precise data returned (httpOnly, secure, sameSite, domain, path, expiry). This clearly distinguishes it from related DevTools siblings like console logs, captured network traffic, DOM inspection, and the iOS Safari cookies counterpart.

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

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

It gives clear usage context ('useful for debugging auth/session state') and practical guidance on omitting pageId to auto-select the visible page. It does not explicitly say when not to use it or name alternatives, so it falls short of a 5 but is clearly more than minimal.

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 so thoroughly. It explains filtering defaults (interactive/meaningful elements), the selector scoping, the uniqueness verification of suggested locators, the diagnostic nature of css/xpath, the null-suggested fallback behavior, the optional computed styles, and page auto-selection. This goes well beyond a simple one-liner and leaves an agent well-informed about the tool's 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 dense but every sentence earns its place. It front-loads the core purpose and return structure, then logically flows into locator recommendations, fallback behavior, and optional parameters. Despite its length, 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?

There is no output schema, so the description must fully explain the return format, and it does: fields, locator recommendations, fallbacks, and null handling. It also covers parameter defaults and edge cases (suggested null, pageId omission). For a read-only extraction tool with no annotations, this is a complete picture for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, giving a baseline of 3. The description adds meaningful semantics for several parameters: selector scoping, includeStyles returning a curated style set, and pageId auto-selection when omitted. While udid, limit, and socket are not elaborated beyond the schema, the added context for key parameters raises the score above baseline.

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

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

The description opens with a specific verb+resource+scope: 'Extract locator-friendly element data from a page on the device for building Playwright/Selenium locators.' It also enumerates the exact return fields (tag, text, attributes, bounding box, visibility), which leaves no ambiguity about the tool's job. The focus on locator generation distinguishes it from siblings like android_devtools_get_dom or device_find_element.

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 strong contextual guidance on how to use the output (prefer `suggested`, treat `css`/`xpath` as diagnostic fallbacks, handle `suggested` null as a real finding). However, it does not explicitly name alternative tools or state when NOT to use this tool versus a sibling such as android_devtools_get_dom or device_locators_for. This is a minor gap given that the use case is clearly implied.

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

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

No annotations are provided, so the description carries the burden. It reveals behavioral traits: enables Runtime, auto-selects the active tab, and returns pageId/pageUrl for verification. It does not mention permissions or side effects, but for a CDP evaluation, these are reasonable to expect.

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 sentences, each conveying essential information: what it does, how it works, and a caveat about page identity. No filler; front-loaded with the core action.

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

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

Given the tool's moderate complexity acceptably complete. It covers the main purpose, the key behavioral nuance (pageId), and the return fields. It doesn't document the output schema (none provided), but for an evaluation tool, specifying result value and exception details is sufficient.

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

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

Schema description coverage is 100%, so parameters are well-documented. The description adds context for pageId (auto-picked when omitted) and the return fields, but does not elaborate on expression syntax or awaitPromise behavior beyond schema 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 clearly states the tool evaluates a JavaScript expression in a page context via CDP, specifying the mechanism (enabling Runtime, calling Runtime.evaluate). It is distinct from siblings like android_devtools_get_dom or android_devtools_elements and identifies the tab context 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 explains when to use it (after a navigate, auto-selects the active tab) and gives a hint on when to check results (if they seem from the wrong page). It doesn't explicitly name alternatives like web_evaluate or ios_safari_evaluate, but the context (android_devtools_ prefix) implies device-specific usage.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals the output cap of 100,000 characters and the appended truncation notice, and explains the auto-selection of pageId when omitted. This adds meaningful behavioral context beyond the schema, though it does not cover potential errors or prerequisites like CDP connectivity.

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 concise sentences, with the main purpose stated first, followed by output limit and auto-selection guidance. No fluff or redundancy; every sentence contributes essential 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 a straightforward read operation, and the description covers the primary purpose, output constraints, and a key parameter behavior. The schema fully documents all parameters. Missing details like error handling or explicit read-only status are minor given the tool's simplicity, but it could still benefit from noting that it returns the page's HTML without modifying anything.

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

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

Schema description coverage is 100%, so the description need not repeat parameter details. It adds value by explicitly stating that omitting pageId auto-selects the visible/active page, reinforcing the schema's note. It also clarifies the selector's behavior via the schema, but the description's truncation notice is output-focused. Overall, the description complements the schema effectively.

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 it retrieves the outer HTML of the page or a CSS-selector-matched element via CDP, which is specific and distinct from sibling tools like android_devtools_elements or webpage_get_dom by its explicit scope and CDP mechanism. It directly answers what the tool does.

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

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

The description gives guidance on omitting pageId to auto-select the active page, which is useful context for parameter usage. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to use android_devtools_elements or other DOM-related tools), leaving the agent to infer usage from the name and description 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 provided, the description carries the full disclosure burden and meets it thoroughly. It discloses the returned fields, newest-active-first ordering, the special meaning of 'active: true', the WebView-only nature of 'visible', and the caveat that stale tabs accumulate across sessions.

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

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

Every sentence earns its place: each adds behavioral or usage guidance rather than repeating structured data. The main action is front-loaded, and the longer explanatory notes about 'active', 'visible', and stale tabs are placed after the core purpose, making the description dense but well-organized.

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 list-only tool with no output schema and no annotations, this description is complete. It specifies returned fields, ordering, default-target semantics, and a cleanup path, while the two parameters are fully covered by the schema. An agent has everything needed to call 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 100%, so the baseline is 3. The description does not add extra meaning about 'udid' or 'socket' beyond the schema, but the schema already documents both parameters, so no critical semantic information is missing.

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

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

Description begins with a specific verb and object: 'List debuggable pages/targets available on the device.' It enumerates returned fields and clearly frames the tool as an enumeration action, distinguishing it from sibling DevTools commands like android_devtools_close_page. The purpose is unmistakable and immediately actionable.

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

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

The description explicitly tells agents when listing is unnecessary: 'you do NOT need to list tabs and pass an id just to act on the current tab, only to act on a DIFFERENT one.' It also names android_devtools_close_page as the tool for cleaning stale tabs, providing an actionable alternative and clear usage boundary.

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 so thoroughly. It discloses mode effects (mock serves without leaving device, abort fails request), scope (web only, native untouched), that nothing device-wide changes and no certificate is installed, and that routes apply immediately and survive navigation. It also flags an iOS-specific charset caveat. This is exemplary 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 well-structured and front-loaded: it opens with the core action and mode semantics, then scoping, then alternatives. Every sentence adds necessary context (e.g., immediate application, persistence, iOS note). Despite its length, there is no fluff; it reads efficiently and covers the essential points 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?

Given the tool's complexity (14 parameters, no output schema) and rich schema descriptions, the description covers all key aspects: purpose, modes, scope, persistence, and routing to alternatives. It also includes edge-case warnings (iOS charset) that are not in the schema. Nothing an agent needs to decide whether and how to call it is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the behavioral impact of the 'mode' parameter (e.g., 'without the request leaving the device') and the scoping implications of 'pageId'. It also clarifies the difference between mock and abort in practical terms, which aids parameter understanding. However, it doesn't elaborate on all parameters individually, so a 4 is appropriate.

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

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

The description states a specific action ('Add (or update in place) a mock/abort rule') with a clear resource ('Chrome/WebView requests on this device'). It distinguishes itself from the sibling android_traffic_mock_add by explicitly limiting scope to web content. The purpose is unambiguous and separates it from similar 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?

Explicitly states when to use this tool (web content) and when not (native app code), and names the alternative (android_traffic_mock_add). It also clarifies that routes apply immediately and survive navigation, giving clear context on expected behavior. No ambiguity about selection criteria.

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

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

With no annotations, the description carries the full burden and it does disclose the behavioral effect: it removes all routes, un-arms interception, and restores normal networking. It goes beyond the tool name by explaining the post-condition, though it omits details like idempotency or behavior when no mocks 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?

Two concise sentences with no wasted words. The first sentence states the primary action, the second provides usage guidance and the resulting network state. The structure is front-loaded and each 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?

For a one-parameter tool with no output schema, the description sufficiently covers what the tool does and when to use it. It lacks only minor details like no-op behavior or error handling, which are not critical for this simple cleanup operation. Overall, an agent can 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add any information about the 'udid' parameter beyond what the schema already provides, so it earns exactly the baseline with no extra value.

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 ('Remove ALL Chrome/WebView routes') and a secondary behavior ('un-arm interception'), identifying the resource and scope clearly. It implicitly distinguishes from sibling tools like android_devtools_mock_remove by emphasizing 'ALL' and the teardown role, and from add/list/status by naming the cleanup operation.

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 an explicit temporal cue ('Call this when finished') and explains the outcome ('restores completely normal networking'), which tells an agent when to invoke it. However, it does not explicitly name alternatives (e.g., mock_remove for selective cleanup) or state when not to use it, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it states that nothing device-wide is changed, no certificate is installed, and effects are scoped to the page. It also discloses the first-match-wins ordering. It does not describe the output format, but that is a minor gap for a list tool.

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

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

Three concise, purposeful sentences. The primary action and ordering behavior are front-loaded, followed by essential scope caveats. There is no filler or redundant restating of the tool name.

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

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

For a one-parameter, no-output-schema list tool, the description gives everything needed to invoke it correctly: what is listed, the ordering, the web-only scope, and the non-destructive behavior. It is complete enough for an agent to select and use it safely.

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% for the single required parameter, and the schema already describes udid clearly. The tool description adds no additional parameter-specific meaning, so the baseline score 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 a specific verb ('List'), a specific resource ('Chrome/WebView mock/abort routes'), and the current per-device scope. The 'WEB CONTENT ONLY' qualifier clearly separates this from native-traffic mock 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?

The description explicitly excludes native app code, making it clear when this tool should not be used. It does not name the alternative native-traffic tool (e.g., android_traffic_mock_list), but the exclusion is unambiguous.

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

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

With no annotations, the description carries the full behavioral burden. It goes beyond the verb 'remove' by disclosing an important side effect: when the last route is removed, the device is automatically un-armed so traffic is no longer paused. It does not cover error behavior for nonexistent ids, but for a simple removal operation this is a minor gap.

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

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

Two short sentences with no filler. The first sentence front-loads the core operation, and the second sentence earns its place by disclosing a meaningful behavioral side effect.

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 2-parameter tool with no output schema, the definition is complete. It specifies what is removed, how the id is obtained, which device to target, and what happens on the last removal. Nothing essential is missing 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 100%, so the baseline applies. The description adds domain context by calling the id a 'Chrome/WebView route', but the schema already documents both parameters adequately. No additional parameter detail is needed.

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

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

The description states a specific action ('Remove'), a specific resource ('one Chrome/WebView route'), and the identification method ('by id'). The word 'one' helps distinguish it from the sibling mock_clear tool, making the tool's scope immediately 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?

Usage is implied: an agent should obtain a route id from a mock-list tool and remove a single route. The id parameter description reinforces this by saying 'from *_mock_list'. However, there is no explicit guidance about when not to use this tool or that mock_clear is the alternative for removing all routes.

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

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

With no annotations, the description carries the full burden and does well: it frames the tool as a read-only report ('Report whether...'), lists the exact data returned, and even explains a behavioral nuance—a route that never matches shows mocked: 0. It does not explicitly state 'no side effects', but the reporting language makes the non-mutating nature clear.

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 dense sentences with no filler. The core status fields are front-loaded, and the counter-confirmation tip earns its place by teaching the user how to interpret the output.

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 status tool with a single parameter and no output schema, the description is complete: it explains what is reported, enumerates the counter categories, and provides concrete interpretation guidance. An agent has enough to invoke it correctly and interpret the result.

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

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

The only parameter, udid, is already fully described in the input schema with 100% coverage. The description adds no additional parameter-level guidance, which is acceptable because the schema already provides the necessary 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 uses a specific verb ('Report') and names a concrete resource: Chrome/WebView interception state on the device, including page target, active routes, and hit counters. This clearly distinguishes it from mock management siblings like android_devtools_mock_add/mock_list/mock_remove, which configure rather than report status.

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 guidance to 'Check the counters to confirm a mock is actually firing' implies a clear diagnostic use case: verify that an armed mock is being hit. However, it does not explicitly state when to prefer this over android_devtools_mock_list or other status tools, nor does it name alternatives 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 fully carries the behavioral burden and does so thoroughly. It discloses waiting semantics for Page.frameStoppedLoading, the exact return shape including finalUrl being non-null only when waiting, and the side effect of changing the device's current page.

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

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

The description is front-loaded with the core action, then flows logically through wait behavior, return fields, and stateful usage. Despite its length, every sentence carries useful information and none are redundant with 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?

For a tool with no output schema, the description compensates by specifying the returned fields and their meaning, including nullability. It also covers the stateful page-selection behavior needed to correctly chain calls, making it complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, but the description adds important meaning beyond field names: waitMs controls whether Page.frameStoppedLoading is awaited, pageId may be omitted for auto-selection, and finalUrl reveals redirects only when waiting. This exceeds the baseline expected from schema-only 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?

States a specific verb and resource: 'Navigate a page running on the device to a URL via CDP (Page.navigate)'. The android_devtools_* namespace and CDP framing clearly distinguish it from generic device or web navigation tools even without naming a sibling.

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

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

Provides clear workflow context: how to omit pageId for auto-selection, and that after success the landing page becomes the current page so subsequent android_devtools_* calls need no pageId or list_pages round trip. It does not explicitly list exclusions or alternate tools to prefer instead, but the operational guidance is strong.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the underlying mechanism (`dumpsys gfxinfo`) and the exact metrics collected, which implies a read-only query and helps an agent understand what will happen. It does not mention prerequisites like app foreground state or whether any state is reset, but for a stat-retrieval tool the disclosed details are 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?

A single, front-loaded sentence that packs in the tool's purpose, implementation method, and metric list without any filler. Every phrase adds value.

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 read-only tool with two straightforward parameters and no output schema, the description gives a complete enough picture: an agent knows the target package, the serial source is in the schema, and the expected output metrics are enumerated. It doesn't specify the exact return structure, but that is a minor omission for a stats tool.

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

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

Schema description coverage is 100%, so the parameters `serial` and `pkg` are already fully documented in the input schema. The description adds meaning only for `pkg` by showing the metric scope, which is useful but not necessary. The baseline of 3 applies because 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?

The description clearly identifies the resource (a package) and the specific metrics (FPS/jank stats, total frames, jank %, percentiles, missed vsyncs), making the tool's function obvious. It doesn't use an explicit verb like 'retrieve' but is specific enough to distinguish from siblings like android_app_launch_time and ios_fps.

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 android_performance_snapshot, android_app_launch_time, or ios_fps. The description implies a performance measurement use case but provides no exclusions or sibling comparisons.

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 key traits: it decodes a frame from an already-running stream, spawns no fresh full-resolution grab, captures at physical resolution without downscaling, and matches device_tap coordinates 1:1. It also notes the image-only nature and speed trade-off, but it does not mention what happens if the shared stream isn't running, 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?

Every sentence in the description earns its place, covering purpose, performance, usage recommendation, resolution invariant, alternative guidance, and output format. The key facts are front-loaded ('PREFERRED fast screenshot'), and the section is dense with useful information but contains zero fluff 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 one-parameter tool with no annotations and no output schema, the description is remarkably complete. It states the return type ('single JPEG frame'), the resolution behavior, coordinate alignment with device_tap, and explicitly explains when to use the sibling tool instead. Nothing an agent would need to call it correctly is missing.

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

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

The only parameter, 'udid', is fully described in the schema as 'Device serial number (UDID)' with 100% schema coverage. The description does not add any additional meaning to the parameter beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states a specific verb+resource: 'PREFERRED fast screenshot of an Android device via the ALREADY-RUNNING shared video stream.' It also explicitly distinguishes itself from sibling device_screenshot and ios_mjpeg_screenshot by naming the alternative and the use case, making the purpose unambiguous.

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

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

The description gives explicit when-to-use guidance: 'Use this for routine per-action screen checks' and states it should be the 'default for iterating on a flow.' It also provides when-not-to-use guidance, directing the agent to 'Reserve device_screenshot for when you need the bundled labeled-elements list or a full-fidelity image,' which is a clear alternative and exclusion.

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 burden. It discloses that recording is ongoing ('over time') and that it must be stopped, which is useful. However, it does not mention what happens on repeated starts, whether recording is exclusive per device, or how data is retrieved after stopping.

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 filler. The core action is front-loaded, and the stop instruction is a useful second sentence. The analogy 'like screen recording, for metrics' is brief and aids understanding without bloating the 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?

The description is adequate for a simple start tool but lacks some context an agent may need: there is no mention of how results are obtained (presumably from the stop tool), whether only one recording can be active, or any caveats about starting multiple recordings. With no annotations and no output schema, this is a notable gap.

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

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

Schema description coverage is 100%, so the parameters are already documented in the input schema. The description adds only high-level context ('per-process CPU/memory') that loosely maps to the pkg parameter, but provides no additional semantics 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?

The description states a specific verb ('Start') and resource ('recording per-process CPU/memory over time'), which makes the tool's function immediately understandable. It also explicitly names the companion stop tool, helping distinguish it from the lifecycle sibling.

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

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

The description clearly indicates the pairing with android_performance_record_stop, giving basic lifecycle guidance. However, it does not mention when to use this tool instead of android_performance_snapshot or other performance tools, so alternative selection is left to inference.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return format (time-series + summary) and implies statefulness via sessionId. It does not mention side effects like whether the recording is deleted or if errors occur when no active session exists. With zero annotation coverage, this is a moderate disclosure.

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, well-structured sentence that front-loads the action and includes key return details. 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?

With no output schema, the description explains what the tool returns, which is essential. For a one-parameter stop tool, this is largely complete. Minor omissions like prerequisites (an active recording) are implied by the sessionId reference.

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

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

The schema provides 100% coverage for sessionId, explicitly stating it comes from android_performance_record_start. The description adds no additional meaning beyond the schema, so a baseline 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 states a specific verb ('Stop'), the resource ('performance recording'), and the return value (full time-series and per-process summary). This clearly differentiates it from siblings like android_performance_record_start (which starts) and android_performance_snapshot (which likely takes an instant snapshot).

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 it is the counterpart to android_performance_record_start, and the schema parameter sessionId references the start tool. However, it does not explicitly mention alternatives like android_performance_snapshot or state when not to use it. The pairing with start makes usage clear enough.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It mentions the mechanism ('via top') and the outputs (CPU %% and MB), but doesn't state whether the operation is read-only, how the results are structured, or whether any device state is affected. For a monitoring tool this is minimally informative, but it leaves important behavioral questions unanswered.

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 efficient sentence that front-loads the core action and resource, then adds the two usage modes. There is no filler or redundancy; every word earns its place.

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

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

For a simple 3-parameter snapshot tool with full schema coverage, the description covers the core function well. However, there is no output schema and no mention of the return format (e.g., a table or list), nor any edge cases like what happens when both topN and pkg are provided. It's adequate for an experienced agent but leaves some 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 schema already describes all three parameters at 100% coverage, giving a baseline of 3. The description adds meaningful interaction semantics: 'Top-N by CPU, or one app via pkg' clarifies that pkg overrides the top-N mode. This goes beyond the individual property descriptions and helps an agent reason about parameter combinations.

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

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

The description states a specific verb ('Snapshot') and resource ('per-process CPU and memory for an Android device via top'), making the core function immediately clear. It also names the two operating modes (Top-N by CPU or single app via pkg). It doesn't explicitly compare against siblings, but the word 'Snapshot' naturally distinguishes it from android_performance_record_start/stop.

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 prefer this tool over alternatives like android_performance_record_start/stop or ios_performance_snapshot. It only explains the two in-tool modes (top-N vs pkg), not the selection criteria or contexts where this tool should be used or avoided. An agent must infer usage entirely 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.

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

With no annotations, the description carries full burden and does substantial work: 'Snapshot' signals a read-only one-time view, 'DECRYPTED HTTPS' reveals coverage, 'captured since android_traffic_start' indicates a prerequisite session, and 'truncated' bodies are disclosed. It stops short of discussing failure modes or capture lifecycle, but the key non-obvious behaviors are stated.

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

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

Four dense sentences with no filler; the core resource and dependency are front-loaded, and each sentence covers a distinct aspect (what it returns, body option, filters/limits).

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 supplies return-field details (needed because no output schema exists), the prerequisite, and filtering options, while the required serial is documented in the schema. It is slightly brief about edge cases such as missing capture sessions, but is complete enough for normal 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 coverage is 100%, so the baseline is 3; description adds some behavior around includeBodies ('also return headers + bodies') and describes filter effects, but largely restates schema details rather than adding substantially new 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?

Description names a specific verb, resource, and scope: 'Snapshot recent DECRYPTED HTTPS flows (request/response) captured since android_traffic_start.' It also lists the principal fields returned, and the explicit dependency on android_traffic_start differentiates it from traffic mock/start/status and iOS counterparts.

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

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

Clearly implies the tool is for reading traffic after android_traffic_start, and explains parameter use: includeBodies for bodies, urlSubstring/onlyErrors for filtering, limit for recency. It does not explicitly name when-not-to-use alternatives, but the context is strong and no other Android tool provides this exact view.

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

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

With no annotations provided, the description carries the full burden and does it thoroughly: mutation happens in place, requests never reach the real server, abort causes a network failure, routes are per-device and take effect live, and certificate-pinned traffic will never match. These are exactly the side effects and limits an agent needs.

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

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

Four dense sentences, each earning its place: definition/effect, modal behavior, prerequisite/live behavior, and a critical limitation. The most important fact (add/update a rule) 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?

Given 12 parameters, no output schema, and no annotations, this is complete: it covers prerequisites, live application, per-device storage, and the pinned-certificate boundary. Nothing critical to deciding whether or how to call the tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a useful behavioral layer on top: how `mode` changes behavior, how `id` enables updating in place, and how `serial` scopes routes per-device. It doesn't restate all 12 parameters, which is appropriate given the schema already documents them.

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

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

The description gives a specific verb and resource: add or update a mock/abort rule in the TLS-inspecting proxy. It also clarifies scope (device-level HTTPS traffic, not a browser context) and mentions `android_traffic_start`, so an agent can tell it apart from web/devtools mock 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?

It gives a clear precondition (TLS capture must already be running) and a hard limitation (certificate-pinned apps won't match). It doesn't explicitly name alternatives like `android_traffic_mock_remove` for deletion or `android_devtools_mock_add` for browser-level mocking, so when-to-use-vs-siblings is mostly inferred from names.

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 disclosing behavior. The verb 'List' and phrase 'currently configured' imply a read-only operation that reflects the present state without modifications. However, it does not explicitly state safety traits (e.g., 'does not modify routes') or address potential side effects, permissions, or error conditions. This is adequate 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 description is a single, front-loaded sentence that begins with the verb 'List' and directly states the resource. It avoids redundancy and adds a useful cross-reference to android_traffic_mock_add for context. Every word earns its place.

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

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

For a simple list tool with one parameter and no output schema, the description provides enough context to call it correctly: it names the resource, the scope (this device), and clarifies terminology via cross-reference. It doesn't mention return format or error cases, but these are less critical for a straightforward read-only list 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 description coverage is 100% for the single 'serial' parameter, and the schema already documents it as 'Android device serial (adb serial)'. The description adds no parameter-specific detail beyond the implicit 'for this device' mapping. Since the schema carries the full parameter meaning, a baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'List the mock/abort routes currently configured for this device.' It clearly identifies the operation as a listing action within the android_traffic_mock family, distinguishing it from sibling tools like android_traffic_mock_add and android_traffic_mock_remove. The cross-reference to android_traffic_mock_add further clarifies what the routes are.

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 does not provide explicit guidance on when to use this tool versus alternatives. It only references android_traffic_mock_add for conceptual context, but does not state conditions like 'use this when you need to review current mocks' or contrast with add/remove tools. The absence of exclusions or alternative routing leaves the agent to infer usage from the name and sibling 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 full burden of behavioral disclosure. It does state the mutating action and the return value ('Returns the resulting route list'), which is useful. However, it does not disclose side effects such as irreversibility, what happens if the id does not exist, or the behavior when both id and all are supplied. The description is adequate but not deeply 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?

One sentence conveys the action, both modes of operation, and the return value with no filler or repetition. The most important information ('Remove') is front-loaded, and every phrase contributes to the agent's understanding of how to use the tool.

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

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

The description includes the return value, which is important given the lack of an output schema. However, it leaves open a critical edge case: the schema allows both id and all to be provided simultaneously, but the description doesn't state what happens in that case or what occurs when neither is provided. For a mutation tool with no annotations and no output schema, this gap prevents the description from being fully complete.

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

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

The schema already documents all three parameters with descriptions, so the baseline is 3. The description's references to 'by id' and 'when all is true' essentially mirror the schema's own descriptions without adding further semantics. It does not clarify the relationship between id and all (e.g., whether they are mutually exclusive), so there is no added 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?

The description opens with a specific action, 'Remove', and names the resource as a 'mock/abort route', immediately distinguishing this tool from the sibling android_traffic_mock_add and android_traffic_mock_list tools. It clearly covers both modes of operation (by id and by all), leaving no ambiguity about what the tool does.

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

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

The description provides clear context for when to use each parameter: 'by id' for a single route and 'when all is true' for every route on the device. It does not explicitly route the agent away from alternative tools such as android_devtools_mock_remove or ios_traffic_mock_remove, but the tool name and the phrase 'on this device' make the intended context evident. This earns a 4 rather than a 5 because alternatives are not explicitly 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?

With no annotations provided, the description carries the full behavioral burden, and it delivers: it discloses the proxy setup, silent DPC mode versus manual adb mode, CA/proxy installation behavior, fallback conditions, and the certificate-pinning limitation. This gives an agent an accurate model of side effects and failure modes.

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

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

The description is dense but every sentence earns its place: what it does, how it behaves, what to do next, and when it will fail. The most important action is front-loaded, and technical mode details are packed efficiently 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 one-parameter, no-output-schema tool, this description is complete: it explains the outcome, the two operational modes, prerequisites, limitations, and the next recommended step. An agent has enough context to decide whether to invoke it and what to expect when it does.

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

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

The schema already documents the single required parameter 'serial' at 100% coverage, so the description does not need to add much. It reinforces the per-device nature of the operation but does not add new parameter-level meaning beyond the schema baseline.

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

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

The description states a specific verb and resource ('Start TLS inspection on an Android device') and explains the concrete mechanism: a per-device TLS-inspecting proxy that decrypts and captures HTTPS traffic. It also distinguishes itself from Chrome DevTools by noting it works for native apps, making it easy to separate from related network-capture 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 gives explicit when-to-use context: use this when you need decrypted HTTPS traffic from native apps, unlike Chrome DevTools. It also names the follow-up tool (android_traffic_flows), explains the two install modes, and states the prerequisite that apps must trust user certificates, with pinned apps called out as not decryptable.

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. The verb 'Report' implies a read-only operation with no side effects, but it does not explicitly state that it does not modify the device or disclose any prerequisites (e.g., whether traffic monitoring must be active).

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

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

The description is a single sentence that front-loads the action and immediately enumerates the key output values. Every word is functional with no filler.

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

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

For a one-parameter status tool, the description fully conveys what the agent needs to know to invoke it and interpret the result conceptually. It could mention return value structure or prerequisites, but the lack of an output schema and the simplicity of the tool make the description adequate.

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 parameter 'serial' is documented as 'Android device serial (adb serial)'. The tool description adds no additional meaning about the parameter, so the baseline of 3 applies.

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

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

The description uses the specific verb 'Report' with a clear resource: TLS inspection status for an Android device. It names the concrete data points returned (whether TLS inspection is running, proxy mode, buffered flow count), which clearly distinguishes it from sibling tools like android_traffic_start/stop and android_traffic_flows.

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 this is the status-check tool within the android_traffic_* family, but it does not explicitly state when to prefer it over alternatives or mention any exclusions. An agent must infer from context that this is the read-only status counterpart to the start/stop/mock 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 so well. It explains the scope ('THIS consumer only'), the conditional retention of the TLS-inspecting proxy, device proxy, and DPC CA when other consumers are active, the response's stillRunning field, and the final cleanup actions (killing the proxy, clearing device proxy/CA, discarding buffered flows). This is rich, honest behavioral context.

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 sentences: the first delivers the primary action and scope, the second explains the conditional state with another consumer, and the third clarifies the final cleanup. Every sentence earns its place and the structure is front-loaded with the core purpose, followed by necessary edge-case detail with no fluff.

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

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

For a one-parameter tool with no output schema, the description covers the key behavior, side effects, and the important stillRunning response scenario. It does not explicitly describe error cases (e.g., if no capture is active), but given the simplicity of the parameter and the detailed behavioral coverage, it is nearly complete 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?

The input schema already covers the single parameter 'serial' with 100% description coverage ('Android device serial (adb serial)'), so the schema does the heavy lifting. The tool description does not add any additional meaning about the parameter itself, which matches the baseline for full schema coverage.

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

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

The description names a specific verb ('Stop TLS inspection') and a specific resource ('Android device'), and immediately scopes it with 'from THIS (AI) consumer only,' which distinguishes it from any global stop or from sibling tools like android_traffic_start or android_traffic_status. The conditional behavior and response field are also stated, leaving no ambiguity about what the tool accomplishes.

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 implies the tool is used to stop a previously started TLS inspection for this specific consumer, and it explains the multi-consumer nuance, guiding the agent on when the underlying proxy is actually torn down. However, it does not explicitly state when to prefer this over android_traffic_status or mention alternatives, though the name and context make the primary use case obvious.

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 and does well: it discloses the short-lived nature, single-device constraint, direct openability in a browser, and on-the-fly MJPEG transcoding. It could additionally clarify URL expiration duration or any stream lifecycle/cleanup expectations, but the core behavior is clear.

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 well-structured and front-loads the primary purpose. The four sentences each provide distinct value, though the 'live/real time/on the fly' phrasing is slightly redundant.

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 explains the return type (a short-lived viewer URL), the mechanism (MJPEG transcoding), and the intended use. With no output schema, it provides enough for an agent to select and invoke the tool, though exact URL expiration or auth requirements are not specified.

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?

There is only one parameter (udid), and the input schema already describes it as 'Device serial number (UDID)' with 100% coverage. The description does not add meaning beyond the schema, but none is really needed for such a simple 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 clearly states the tool fetches a live video-stream link for an Android device, for real-time human viewing in a browser. It explicitly contrasts with device_screenshot (single frame), which disambiguates from the most similar sibling.

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

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

The description gives a clear use case: 'let a person supervise what the agent is doing on the device.' It also names device_screenshot as a non-live alternative. However, it does not explicitly mention when to prefer or avoid other related tools such as android_mjpeg_screenshot or ios_video_stream.

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 clearly discloses that the action is destructive and identifies what is destroyed ('uploaded app file' on 'the server'). However, it does not state whether deletion is permanent, whether there are side effects, or what a successful/unsuccessful call returns.

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

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

Two short sentences, both useful: the first states the operation and target, the second tells the agent how to obtain the required parameter. 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 one-parameter, no-output-schema delete operation, the description plus schema provide enough for an agent to call it correctly. It could mention irreversibility or success/error behavior, but the low complexity keeps the gap minor.

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

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

Schema description coverage is 100%: the schema already says 'File ID from app_list'. The description's 'Use app_list to get the file ID' reinforces that source but adds no new semantic information 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?

The description uses a specific verb ('Delete') with a clear resource ('uploaded app file') and location ('from the server'), and it points to app_list for IDs. This distinguishes it from sibling operations like app_upload, app_install, or device_uninstall_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?

It provides one guideline: use app_list to obtain the file ID before calling. It does not explicitly state when to choose this over other app-related tools nor mention exclusions (e.g., this is not for uninstalling an installed app from a device). The context is implied rather than fully specified.

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 discloses the transport mechanisms (APK via Android transport, IPA for iOS) and the prerequisite of an uploaded app. However, it does not mention potential side effects, required device states (e.g., unlocked, connected), or whether the installation overwrites existing apps. It gives some useful behavioral detail but falls short of full transparency for a mutating operation.

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

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

The description is two sentences with no wasted words. The main action is front-loaded, followed by platform-specific details and a workflow hint. Every sentence earns its place, making it appropriately 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?

For a two-parameter tool with no output schema and no annotations, the description covers the essential context: what the tool does, platform variations, and the prerequisite to fetch the file ID. It is complete enough for an agent to call the tool correctly. Minor gaps like return values or failure handling are not critical for this simple operation, making it slightly above the minimum viable completeness.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('Device UDID to install on' and 'File ID from app_list'). The description adds minimal parameter-specific value—only reinforcing the appId prerequisite by referencing app_list. Since the schema carries the full semantic load, a baseline score of 3 is appropriate; the description does not go 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?

The description states a specific verb and resource: 'Install an uploaded app on a device.' It further distinguishes itself by platform ('For Android: installs APK via the Android transport. For iOS: installs IPA.'), which separates it from siblings like app_upload (uploading) and device_launch_app (launching). The prerequisite 'Use app_list to get the file ID first' also reinforces its role in the app workflow.

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

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

The description provides clear context for when to use the tool: after uploading an app, and it names the prerequisite of obtaining the file ID via app_list. It doesn't explicitly mention alternatives or exclusions, but the platform-specific behavior implies the scope is generic installation across Android and iOS, distinguishing it from platform-specific install tools like ios_install_app. This qualifies as clear context without explicit 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 present, so the description carries the burden. It correctly implies a read-only listing operation but does not mention whether results are paginated, sorted, or what fields are returned (e.g., file name, size, upload date). This is acceptable for a simple list tool but leaves some behavior implicit.

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. It states the action, resource, and scope 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?

For a zero-parameter list tool with no output schema, the description is complete. The agent knows exactly what will happen and does not need additional invocation guidance.

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

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

The tool has zero parameters and the schema is empty, so there is no parameter burden. The description still adds a useful semantic detail—'belonging to the current user'—that helps the agent understand the implicit filtering.

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 ('List') plus resource ('uploaded app files') and scope ('belonging to the current user'). It clearly distinguishes this from siblings like app_upload, app_delete, and device_list_apps (which lists installed on-device apps).

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 'uploaded app files belonging to the current user' gives a clear context of when to use this tool. It does not explicitly name alternatives or exclusion criteria, but the scoping makes the intended use obvious enough.

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

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

With no annotations, the description carries the full burden, and it delivers: it explains that the build is only registered when the last chunk arrives, that .ipa files are re-signed unless skipResign is true, and that the tool returns an id used downstream. These are non-obvious behavioral details beyond a simple 'upload' statement.

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

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

Five sentences, each carrying essential information: purpose, chunking protocol, single-call shortcut, re-signing behavior, and return value. The most important information is front-loaded, and there is no filler or repetition.

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

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

This is a moderately complex tool with 6 parameters and no output schema. The description covers the chunked upload mechanics, the boundary condition for single-call uploads, the .ipa transformation behavior, and the return value with its downstream consumers. The agent has enough to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real semantic value by explaining the chunkIndex/totalChunks protocol, the 50MB per-call limit, the single-call shortcut, and the skipResign behavior for .ipa files, which goes beyond the schema's field-level 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 opens with a specific verb and resource: 'Upload an app build (.apk/.ipa) to your App Library.' It clearly distinguishes this from related sibling tools like app_install by defining this as the upload step and noting that the returned id is consumed by app_install.

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

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

The description provides clear contextual guidance: it explains the chunking workflow, when chunking can be skipped (files up to 50MB), and how the response id feeds into app_install/appium:app. It does not explicitly state when-not-to-use this tool or name alternatives, but the usage context is unambiguous.

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

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

With no annotations, the description carries the full burden and does well: it states the output format (markdown link), the relative path and internal routing behavior, and explicitly discloses the tool's limitation: 'This only formats a URL — it does not check that the run exists.' It also surfaces the prerequisite, making side effects and non-effects 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 front-loaded with the core action and includes useful example, usage context, and limitation. It is somewhat longer than strictly necessary, but each sentence contributes meaningful guidance rather than 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 simple one-parameter formatting tool with no output schema, the description is complete: it specifies exact output form, when to use it, what it does not do, and the prerequisite call. An agent has enough information to invoke and present the result correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a concrete example ('session_id=abc123') and explains the parameter as a run's session id, but this largely mirrors the schema's 'The run's session id.' The added value is modest.

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: 'Build a clickable link to a run's detail page.' It also differentiates itself from similar automation tools by clarifying it only formats a URL and does not fetch run data, which distinguishes it from automation_session_get and automation_report.

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 when-to-use guidance: 'Offer it after explaining a run so they can see the video, screenshots and full command list for themselves.' It also names the prerequisite alternative: 'call automation_session_get first if you have not already.' This is clear routing between tools.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that counts are computed server-side over the full period, making results authoritative where client-side tallying would be incomplete, and it reveals that breakdowns map directly to chart components. It does not discuss errors, permissions, or response shape, but the most important behavioral caveat is clearly surfaced.

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

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

The description is dense but efficient: it enumerates outputs, states the primary use case, explains the correctness advantage over the sibling tool, maps results to chart components, and gives a default-behavior tip in three sentences. Every sentence contributes new information and the most important directive is front-loaded in caps.

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?

Even without an output schema, the description names the concrete aggregates and breakdowns the agent should expect, covers all four optional parameters through the schema, and adds usage and defaulting context. For a read-oriented reporting tool, this is sufficient for a correctly targeted call.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value by explaining that omitting startDate and endDate selects the default period. It also frames platform and testSuite as optional restrictions in a way consistent with the schema. This goes slightly beyond the schema's field-level 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 identifies this as a pre-aggregated automation statistics tool, enumerates the exact data it returns (pass/fail counts, pass rate, per-platform/per-device breakdowns, slowest/most-failed commands), and explicitly frames it as the tool for charts and totals. It distinguishes itself from automation_sessions_list by calling out that manual tallying would only cover the recent window.

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 direct usage direction: 'USE THIS FOR ANY CHART OR TOTAL' and explains why it is the correct choice over automation_sessions_list for aggregate accuracy. It also names the alternative explicitly and provides the practical default-period hint, so an agent can decide when to select this tool without opening either 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 provided, the description carries full burden and does so thoroughly: it discloses output cap/summarisation, failuresOnly returning empty plus a whyNoFailedSteps block, per-step error messages, element locators and find indices, behavior for still-running sessions, and the need to use the same session id for follow-up logs. This goes well beyond what the schema exposes.

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

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

The description is long, but appropriately so for a debugging tool with subtle behaviors. It is front-loaded with the core purpose and then covers edge cases and follow-up actions in a logical order. Every sentence adds operational value; there is no filler or redundancy that would justify a lower score.

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 there is no output schema and no annotations, the description compensates exceptionally well: it explains output shape highlights, edge cases, progress behavior, and downstream tooling. An agent has enough context to call this correctly, interpret empty results, and know when to escalate to automation_session_step or browser log tools.

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

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

Schema description coverage is 100%, so the baseline is 3. The schema already documents sessionId, limit, and failuresOnly, including the 'last n steps' behavior and the ceiling. The description reinforces failuresOnly=true and the idea of requesting filtered views, but adds no genuinely new parameter-level semantics beyond what the schema provides.

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

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

The description opens with a specific verb and resource ('Read the step-by-step command history of a run') and immediately frames the tool as the debugging tool, distinguishing it from sibling tools like automation_session_step and session_console_logs. It clearly communicates both what the tool does and how it stands apart.

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

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

The description gives explicit when-to-use guidance: debugging failed runs, using failuresOnly=true first, checking assertion-failure cases, tracking in-progress runs, and following up with session_console_logs / session_network_logs. It also names the alternative for detailed step inspection (automation_session_step), leaving no ambiguity about workflow.

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

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

With no annotations provided, the description carries the full burden and delivers rich behavioral detail: the meaning of 'reported' versus 'inferred' verdicts, the warning not to state inferred results as fact, the 'stillRunning: true' in-progress interpretation, and the privacy caveat that other users' sessions appear nonexistent. This goes well beyond the minimal safety profile.

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

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

The description is somewhat long but every sentence earns its place: field list, triggering scenario, verdict confidence semantics, in-progress handling, and access restriction. It is front-loaded with the core purpose and practical entry condition, with 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 one-parameter read tool with no output schema, the description is unusually complete. It covers what return values mean, how to interpret ambiguous outcomes, how to handle unfinished runs, and an access caveat. An agent has everything needed to call it correctly and interpret the result accurately.

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 required parameter sessionId is already described accurately in the schema. The description adds minor context about where the id comes from (the link or the run display) and how it relates to the tool's purpose, but this is not a significant semantic addition 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?

The description opens with a specific verb and resource: 'Read one finished automation run' and enumerates the exact fields returned (verdict, test, device/browser, capabilities, duration, video/snapshot existence). It clearly distinguishes this get-by-id tool from sibling tools like automation_sessions_list by tying it to a pasted session id or /automation?session_id=... link.

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

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

The description explicitly tells the agent when to start here: when the user pastes a session id and asks what happened, why it failed, or how it went. It also gives important context about only reading one's own runs. However, it does not name alternative tools or explicitly state when not to use this tool, so it falls just short of full sibling 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?

With no annotations provided, the description fully carries the behavioral burden. It discloses that filters are applied server-side across the entire history, explains the pagination contract (`total` vs `runs`), and reveals that both short and full session IDs are accepted. These are non-obvious behaviors that materially affect how an agent should use the tool.

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

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

The description is compact but dense—every sentence carries distinct information: purpose, example intents, server-side behavior, pagination semantics, search syntax, and an explicit alternative. It is well-structured with the core purpose front-loaded and no repetition of schema details.

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 no output schema, the description covers the key return semantics (`total` and `runs`, with `offset` pagination), which is the most critical information for correct invocation. It also addresses the main use cases and provides the alternative for aggregate data. It doesn't enumerate every possible nuance of each parameter, but the schema already covers those, and no missing piece would prevent an agent from calling the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value by explaining the `search` parameter's acceptance of the short 8-character UI form and clarifying the `offset` parameter's relationship to `total` for pagination. This goes beyond the schema's basic documentation without duplicating it.

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

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

The description opens with a specific verb and resource ('Find and list your automation runs') and immediately connects to concrete user intents ('how did my tests go', 'what failed recently'). It also distinguishes itself from the sibling automation_report, which covers pass rates, making the tool's scope 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 explicitly states when to use this tool (locating runs by description, filtering by suite/status) and names the alternative for aggregate reports. It also explains the search parameter's role for finding sessions by ID, guiding correct selection among similar 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?

Given no annotations, the description fully discloses behavior: it resolves opaque element IDs to locators, handles empty bodies for click/sendKeys steps, and clarifies that networkDuring may be absent or explicitly say no traffic was captured. It also explains the empty-vs-explict handling to avoid misinterpretation.

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 several sentences long, but every sentence adds value. The primary purpose is front-loaded, then the 'which element' use case, then network behavior. Slightly verbose but justified by the need for clarity on non-obvious behavior.

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, full schema coverage, but no output schema and no annotations, the description compensates by explaining what to expect (request/response, status, timing, locator) and nuances like empty network representation. No critical missing information.

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 covers all parameters with descriptions, but the description adds context for index (positions in full history) and includeNetwork (default true, skip extra lookup). This adds a bit of value beyond schema, but the schema already covers the basics, so baseline 3 is appropriate.

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

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

The description clearly states the tool opens one step of a run in detail, listing specific data (request/response body, status, timing, locator). It distinguishes itself from the sibling automation_session_commands by explicitly stating that it should be used after that tool to get the index.

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

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

Explicitly instructs to use automation_session_commands first to get the step index, then use this tool. Also clearly identifies the primary use case (answering 'which element?') and when network data is available (browser runs only), implicitly guiding 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, the description carries the full burden. It discloses the mutating nature, the need for confirmation, the default workItemType, and the formatting of description into <p> tags. It does not cover error handling or permissions, but the disclosed behaviors are substantial and accurate.

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 sentences with no redundancy. It front-loads the primary action and return value, then includes the confirmation warning, defaults, and parameter clarifications in a logical order. 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?

Given no output schema, the description explains the return (id + browse URL). It covers defaults, project meaning, and description formatting. For a 5-parameter creation tool with 2 required, it is reasonably complete, though it could mention error scenarios or tag behavior, which are already 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%, providing a baseline of 3. The description adds value beyond the schema by explaining the project arg (URL segment), description formatting, and the default workItemType, enhancing agent understanding of parameter usage.

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: 'Create a new AzDO work item.' It also mentions the return of id and browse URL. While it doesn't explicitly differentiate from sibling tools (azdo_get_work_item, azdo_search_work_items), the verb 'Create' makes the purpose unambiguous among the three AzDO tools.

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

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

The description provides clear context: it is a mutating operation requiring user confirmation, and it explains the default workItemType and the meaning of the project argument. However, it does not explicitly state when to use this tool versus the read-oriented siblings, though the create verb implies this distinction.

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 it uses the calling user's stored credential, rejects inline credentials, returns an actionable error if AzDO is unconfigured, and returns HTML-stripped description text. Missing explicit read-only statement and not-found behavior, but generally 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?

Four dense sentences, each with a distinct purpose: action, return fields, auth model, and error behavior. No filler or repetition; the most important identifying info 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?

With no output schema, the description usefully enumerates the returned fields and covers auth and error behavior. It does not mention what happens when the ID does not exist (e.g., null vs error), which is a minor gap for a simple get-by-ID 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 100%, and the schema already fully documents the id parameter as a positive integer. The description merely repeats 'integer ID' without adding new semantic meaning, so baseline 3 is appropriate.

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

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

Description states a specific verb and resource ('Fetch a single Azure DevOps work item by integer ID') and clearly distinguishes from sibling search/create by emphasizing 'single' and 'by integer ID'. It does not explicitly name the sibling alternatives, so it falls short of the top score.

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 explicit guidance about when to choose this tool over azdo_search_work_items or azdo_create_work_item. There is no mention of alternatives, prerequisites, or scenarios; usage context is only implied by the fetch-by-ID semantics.

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 disclosure burden. It adds meaningful non-obvious traits: only the SELECTed IDs are honored, the tool batch-fetches full fields, and it returns up to 50 items. It does not discuss authentication or errors, but the read-only search nature and return behavior are well 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 compact and front-loaded with the core purpose. Every sentence adds value: the search intent, the projection alignment with azdo_get_work_item, the WIQL examples, and the behavioral caveat about SELECT clauses are all useful with no filler.

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

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

The description is sufficient for correct invocation: it explains the query language, the required SELECT clause, the return projection, and the result cap. It does not detail error handling or authentication, but for a moderate-complexity read/search tool with no output schema, it covers the key operational facts well.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by providing concrete WIQL examples and the guidance to 'Narrow WIQL for wider sweeps.' This adds practical parameter-construction value 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?

The description states a specific verb and resource: 'Search AzDO work items with WIQL.' It also differentiates itself from related tools by referencing azdo_get_work_item's projection and by clarifying AzDO context versus Jira, so an agent can distinguish it from azdo_get_work_item, azdo_create_work_item, and jira_search.

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 implies when to use the tool: when searching work items by query rather than fetching a single item. It gives WIQL examples and notes the same projection as azdo_get_work_item, which provides useful context, but it does not explicitly state an exclusion such as 'for a single item by ID, use azdo_get_work_item instead.'

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

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

With no annotations, the description carries the transparency burden and does well: it discloses the implementation (`pm path`), the output composition (base plus split APKs), per-entry fields (path, sizeBytes, role), and the exact return envelope (`{ ok, packageName, apks }`). It omits failure-mode details for missing packages, but the `ok` field implies error handling.

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

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

The description is front-loaded with the primary action and uses compact, information-dense sentences. The cross-reference to device_file_pull and the inline output shape replace a missing output schema without bloat.

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

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

For a simple two-parameter list tool with 100% schema coverage and no output schema, the description provides everything an agent needs: required inputs come from the schema, output shape is stated, and the follow-up pull workflow is explained. No critical information is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no parameter semantics beyond the schema, since all it says about packageName is implied by 'installed app' and udid is already defined 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 opens with a specific verb and resource: 'List APK file paths for an installed app' via `pm path`. It clearly distinguishes this from generic file tools like device_file_list and from pulling tools like device_file_pull by naming the exact artifact type and split APK categories.

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

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

The description establishes the correct workflow by explicitly instructing the agent to use device_file_pull on each path to fetch bytes, including size caps. It does not explicitly state when not to use this tool, but the use case is narrowly defined enough that this is a minor omission.

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. 'Get' implies a read-only operation, and the listed outputs (level, charging state, temperature) hint at behavior, but the description does not disclose edge cases such as device availability, units of temperature, or whether the device must be powered on. It does not contradict anything, but it 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 front-loaded sentence with no filler. It names the action, target, platform, and core output fields in one compact statement.

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

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

For a simple one-parameter read-only device query, the description is mostly complete: it identifies the target, platform, parameter, and return information. It would be more complete if it specified units or exact output shape, but the lack of an output schema makes its current level adequate.

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 parameter udid already has a clear description ('Device serial number (UDID)'). The tool description adds no extra parameter-level meaning, so it does not exceed the schema baseline.

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

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

The description states a specific verb ('Get'), a specific resource ('battery status'), and a platform scope ('Android device'), then enumerates the returned data: level, charging state, temperature. It clearly distinguishes this from iOS sibling tools like ios_battery by naming the Android platform.

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

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

The description makes clear this tool is for Android devices, which effectively routes the agent away from ios_battery and other non-device tools. It does not explicitly name an alternative or state when not to use it, but the platform constraint is clear and sufficient for basic selection.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that all data and cache are cleared and uses the 'Clear Storage' analogy, making the irreversible, reset-like behavior evident. It does not mention side effects like logging the user out, but the core destructive action 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 concise sentences with no filler. The core action is stated upfront, and the Settings equivalence provides useful context without bloating the 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?

For a destructive tool with no output schema and two well-described parameters, the description covers the essential behavior: it specifies the Android platform and that data/cache are cleared. Minor gaps like explicit irreversibility are not critical given the clear wording.

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 already describes both parameters (udid, packageName) at 100% coverage, so the description does not need to add parameter detail. It adds no parameter-specific semantic value beyond the schema, which is acceptable at the baseline.

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

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

The description explicitly states the action (clear all data and cache), the resource (an app on an Android device), and provides a real-world equivalent ('Clear Storage'). This unambiguously identifies the tool's purpose and sets it apart from sibling tools like app_delete or device_clear_app_locale.

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 app_delete, device_uninstall_app, or device_clear_app_locale. No conditions, exclusions, or preferential use cases are mentioned, 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 provided, the description carries the burden of behavioral disclosure. It states the effect (drops override, falls back to system language) and the platform requirement (Android 13+). It doesn't cover edge cases like missing override or app uninstalled, but for a simple operation this is adequate.

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

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

Two sentences, front-loaded with the core action, then the counterpart and requirement. Every word earns its place; no fluff 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?

For a two-parameter tool with no output schema, the description covers purpose, effect, counterpart, and a key prerequisite. It doesn't mention what happens if the override isn't set, but that's a minor edge case. Overall, an agent has enough to call it correctly.

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

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

The input schema already provides 100% coverage for both parameters (udid and packageName) with clear descriptions. The tool description adds no extra parameter details, so the baseline of 3 applies as 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?

The description uses a specific verb ('drop') and identifies the exact resource ('per-app locale override on an Android app') plus the resulting behavior (falls back to device system language). It also names the direct counterpart (device_launch_app_in_language), making it distinct from 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?

It explicitly mentions the counterpart tool and a hard prerequisite (Android 13+), which implies when to use it (to revert an override set by the counterpart). It stops short of spelling out 'use this when you want to undo a locale override' or excluding other alternatives, but the guidance is clear enough.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It goes beyond the name by explaining that the helper service stops pushing mocked fixes and that apps fall back to the real GPS/network provider. It does not cover edge cases like no-op behavior when mocking is already off, but this is meaningful transparency for a simple stop operation.

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

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

The description is two sentences with no filler. The first sentence delivers the core definition, and the second adds useful pairing and behavioral context. It is front-loaded and every clause contributes.

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-required-parameter tool with no output schema, the description gives enough to invoke it correctly: what it does, on which platform, and what effect it has. It omits only minor details like idempotence or what happens if no mock is active, which are not critical for this tool's simplicity.

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

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

The input schema already documents the only parameter, udid, as 'Device serial number (UDID)', giving 100% schema description coverage. The description adds no parameter-specific detail, but the high coverage means this is acceptable under the baseline.

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

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

The description names a specific verb ('Stop'), a specific resource ('mock GPS'), and the platform ('Android device'), so an agent immediately knows what the tool does. It also explicitly identifies itself as the counterpart to device_set_location, distinguishing it from the setter and from sibling tools like ios_clear_location.

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: use this tool when you want to stop mocked GPS and return to real GPS/network provider, and it explicitly frames the tool as the counterpart to device_set_location. It does not enumerate exclusions such as iOS or edge cases when no mock is active, but the Android qualifier and counterpart framing provide sufficient 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 behavioral burden and does so well: it discloses that the tool reads the current text length, moves the cursor to the end, and sends exactly that many DELETE keycodes. It does not state what happens if no text field is focused, but the prerequisite mitigates 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?

Three sentences, each earning its place: the mechanics, the prerequisite, and the alternative tool. Information is front-loaded and there is no filler or repetition of schema content.

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

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

For a one-parameter tool with no output schema, the description is complete: it explains the behavior, the required precondition, and the relevant alternative. Nothing an agent needs to invoke it correctly is missing.

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

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

The only parameter, udid, is already fully described in the schema ('Device serial number (UDID)') with 100% coverage. The description adds no new parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description clearly specifies a verb ('Clear'), a resource ('focused text field on Android'), and the exact mechanism. It distinguishes itself from device_type and implicitly from ios_clear_text by stating 'on Android'.

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

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

It explicitly states the prerequisite: 'Tap the field to focus it first.' It also names the alternative tool and condition: 'use device_type with clearFirst:true instead' when the agent needs to clear and re-type in one call. This is concrete routing 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 to carry the safety/behavior burden, the description discloses important behavioral traits: OS-version-dependent reliability, the OS block reason, and the fact that it returns an empty-clipboard sentinel instead of a raw error. This is far beyond a generic 'read clipboard' statement.

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 main action is front-loaded, and every subsequent sentence earns its place by explaining platform constraints, failure behavior, and the recommended workaround. It is detailed without being 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?

The description is very complete for a one-parameter tool with no annotations or output schema: it covers behavior, failure modes, and workflow. It falls just short of full completeness by not spelling out the exact successful return format or the precise sentinel value an agent should detect.

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 parameter udid is already described as 'Device serial number (UDID)'. The description adds no additional parameter-level detail, 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 opens with a specific verb and resource: 'Read the current clipboard content from an Android device.' It also distinguishes itself from the sibling device_clipboard_set by positioning this as the read counterpart and even references the set tool for an alternative workflow.

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 when-to-use guidance ('Reliable on Android 12 and earlier'), when-not-to-use guidance for Android 13+, and names the exact alternative path via device_clipboard_set. No inference is required.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool writes to the clipboard, that paste:true triggers KEYCODE_PASTE, and that an empty string clears the clipboard. This exceeds basic operation description and gives the agent actionable behavioral expectations.

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 sentences with no filler: the purpose is stated first, then the key option is explained, then the edge case is covered. Every sentence contributes essential information 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 simple three-parameter tool with no output schema and no annotations, the description covers the main behaviors: setting, pasting, and clearing. It could slightly improve by mentioning the default of paste when omitted, but the schema already documents that. Overall, it is sufficiently complete for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the practical effect of paste:true, confirming the empty-string clearing behavior for content, and clarifying that no separate Ctrl+V is needed. This adds genuine semantic value.

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 ('Set') with a clear resource ('Android device clipboard') and distinguishes it from sibling tools like device_clipboard_get by the write operation and the Android platform. It also adds the unique protocol detail about paste injection, making the tool's purpose unambiguous.

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

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

The description clearly implies when to use this tool—when setting the Android clipboard—and adds useful context about not needing a separate Ctrl+V. However, it does not explicitly name alternatives such as device_clipboard_get or the iOS clipboard tools, nor does it state when this tool should not be used.

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 states the read-only nature ('Get') and the return fields, which is useful, but it does not disclose potential caveats such as permission requirements, behavior on unknown launchers, or how 'foreground' is defined. This is adequate 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 description is a single, clear sentence that front-loads the core action and result. Every word earns its place with no fluff 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 one-parameter query with no output schema, the description adequately covers what is returned (package name and activity). It is complete enough for an agent to invoke it correctly, though it could optionally mention where to get the UDID (e.g., device_list).

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 parameter (udid) is already fully documented in the schema. The description adds no extra meaning about the parameter, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get') and names the exact resource ('currently active (foreground) app on an Android device'), plus the return content ('package name and activity'). It clearly distinguishes from iOS and other app-related tools.

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

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

The phrase 'on an Android device' tells the agent when to use this tool (Android foreground query) and implicitly that it is not for iOS. However, it does not explicitly list alternative tools or exclusions, so a small gap remains.

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 behavior disclosure burden. It discloses the mechanism (APP_SWITCH keycode, shell, policy-gated), the wait for UI settle, and the swipe action. It also mentions the return shape. It does not detail failure cases or the exact effect of the 'all' flag on navigation, but the core 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?

Three crisp, information-dense sentences with no filler. The primary action is stated first, followed by use cases, implementation details, and return value. Each sentence adds value and nothing is redundant.

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

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

For a tool with no output schema and no annotations, the description is quite complete: it covers what happens, how, and what is returned. It doesn't address edge cases (e.g., package not in Recents, screen lock), but for the given complexity, it is sufficient. A slightly more detailed return contract or error behavior would improve it.

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

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

The schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds little beyond the schema: it mentions 'Close all' and 'first/frontmost card' behavior, but these are also in the schema. It does not clarify interactions like what happens if 'all' is true and 'packageName' is set, so it does not exceed the baseline.

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

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

The description clearly states the tool's purpose: opening the Recents screen and dismissing an app card, with an optional 'Close all' action. It distinguishes this from generic swipe/terminate tools by specifying the exact UI context and action ('dismiss an app card on Recents'). The mechanism (keycode 187) further clarifies its scope.

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 use case: 'Useful for clearing background apps or verifying an app was killed.' This provides context for when to invoke it. However, it does not explicitly name alternatives (e.g., device_terminate_app for force-stop, device_swipe for generic swipes) or state when not to use it, leaving some room for inference.

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

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

With no annotations, the description carries the full burden. It discloses the gesture sequence, coordinate system (physical pixels from page_source bounds), and the fallback vs. strict input behavior. It explains that 'auto' falls back silently while 'hid' fails loudly. It does not mention return values or error handling beyond that, but for a gesture tool it is sufficiently 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 well-structured and front-loaded with the core action. Each sentence adds value: action, distinctions, use cases, coordinate note, and input behavior. It avoids redundancy and is appropriately sized for the complexity of the tool.

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

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

The description covers the gesture mechanics, usage scenarios, coordinate origin, and the special input mode. It does not describe return values (no output schema) or detailed failure modes beyond the input choice, but for a drag-and-drop gesture tool this is adequate. It also mentions the legacy name device_uhid_drag_drop, which is helpful for migration.

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

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

The schema already documents all 8 parameters (100% coverage), but the description adds meaning beyond that: it clarifies that coordinates are physical pixels sourced from page_source bounds, and explains the timing semantics of holdMs and durationMs. It also elaborates on the input parameter's enum values and their consequences, which is valuable context.

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

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

The description clearly states the tool's purpose: 'Drag-and-drop on an Android device: hold at (x1,y1) for holdMs to grab, then move to (x2,y2) over durationMs.' It names specific resources and actions, and explicitly differentiates from device_swipe and device_long_press, making it unambiguous which tool to select.

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

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

Provides explicit usage guidance: 'Use for app-icon reorder, drag-into-folder, slide gestures that need a deliberate grab.' It also contrasts with swipe and long press, and explains when to use input='hid' versus the default auto mode, covering both when-to-use and when-not-to-use.

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

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

With no annotations, the description fully discloses key behaviors: it only returns elements whose bounding box intersects the rectangle, it returns attributes, bounds, center coords, and ranked locator strategies, and it sorts smallest-first so the most specific element appears first. This goes well beyond the schema and provides realistic expectations for output ordering and content.

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 sentences deliver all essential information without padding: the operation, output contents, ordering behavior, and a concrete use case. Every sentence earns its place, and the most actionable information appears first.

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 lacking an output schema and annotations, the description explains what is returned, how results are sorted, what qualifies as addressable, and when to use the tool. The optional limit parameter's default is documented in the schema, so nothing critical is missing for an agent to invoke this correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description reinforces that the rectangle is in physical pixels and that elements are selected by bounding-box intersection, but it does not add new per-parameter detail beyond the schema's clear 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?

Description uses a specific verb 'List' and a clearly defined resource: addressable UI elements in a given physical-pixel rectangle. It defines 'addressable' precisely (has resource-id, text, or content-desc) and states the intersection criterion, so an agent knows exactly what the tool returns and can distinguish it from page-source or find-element 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 final sentence gives an explicit use case: 'Use to enumerate the contents of a region (bottom nav, dialog, list section) without parsing the full XML.' This tells an agent when to invoke it, though it does not explicitly name alternatives like device_page_source or ios_elements_in_region.

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 discloses key behaviors: recursive copying and the within-device constraint. It does not mention overwrite semantics, permissions, or error conditions, but for a straightforward copy operation these are secondary and the most important behavioral traits are 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 three sentences with zero wasted words. It front-loads the core action, then clarifies the scope (within device) and directs to the correct alternatives for host transfers. Highly efficient and 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?

For a simple 3-parameter tool with no output schema, the description covers the essential context: what it does, where it operates, and how to differentiate it from related tools. It omits details like overwrite behavior, but that is not critical for correct invocation. The description is sufficiently complete for an agent to use it appropriately.

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% (each parameter has a clear description: 'Absolute destination path', 'Device serial number (UDID)', 'Absolute path of the source file or directory'). The description adds the recursive behavior but does not clarify parameter meanings beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Copy a file or directory on the device'), clarifies recursive behavior, and distinguishes it from the iOS counterpart (ios_file_copy) and from host-transfer tools (device_file_pull/push). An agent can immediately understand what this tool does and how it differs from its siblings.

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

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

The description explicitly directs users to device_file_pull/push for host transfers, and names ios_file_copy as the counterpart, which clarifies when to use this tool. However, it does not mention other device file operations like move or delete as alternatives, so the guidance is strong but not exhaustive.

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 so excellently. It discloses recursive behavior, irreversibility with no trash, refusal of storage roots, and error-on-missing-path semantics. This is exactly the safety-critical context an agent needs.

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

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

Three well-structured sentences, each earning its place: operation and counterpart, irreversibility, and safety/error behavior. There is no filler, and the most important information is front-loaded.

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

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

For an unannotated, destructive tool with no output schema, the description covers operation scope, irreversibility, protected paths, and failure behavior. It is complete enough for an agent to invoke the tool correctly and avoid common mistakes.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful context around path safety (root refusal, empty-variable mistakes) but does not add direct parameter-level meaning beyond what the schema already provides for udid and remotePath.

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