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

With no annotations, the description carries the full burden. It discloses only the auto-selection behavior when the device parameter is omitted and only one device is connected. It does not mention whether the tool is read-only, what happens with multiple devices or no devices, or any side effects. There is no statement about permissions or the nature of the returned 'detailed information.'

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 concise and front-loaded: a single clear sentence stating the purpose, followed by a brief parameter explanation. No extraneous words or redundant details. It earns its place and is easy to parse quickly.

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

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

For a simple one-parameter tool, the description covers the core purpose and parameter behavior. The presence of an output schema likely covers return values. However, it omits edge cases like multiple devices or device-not-found errors, and it doesn't mention prerequisites (e.g., ADB server running). It is adequate but not exhaustive.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'device' is a 'Device serial number' and describes the fallback behavior when omitted. This adds meaningful semantics beyond the bare schema, though it doesn't specify the exact format of the serial number or error conditions.

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: 'Get detailed information about a connected Android device.' It uses a specific verb and resource, distinguishing it from sibling tools like adb_devices (which lists devices) and adb_screenshot. However, it does not explicitly name any sibling or contrast itself with alternatives, so it stops short of full differentiation.

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

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

There is no guidance on when to use this tool versus other adb_* tools. It only explains the device parameter, not the conditions under which this tool should be chosen. For instance, it doesn't mention that adb_devices is for listing devices or that this tool is for inspecting a single device. No exclusions or alternatives are given.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states that it 'Returns a formatted table of connected devices', which gives a sense of the output. However, it doesn't mention prerequisites (e.g., adb server running), potential side effects (unlikely), or error conditions. The description is adequate but minimal for a read-only listing 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 two sentences, front-loaded with the core purpose and followed by a usage hint. Every sentence earns its place; 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?

Given the tool's simplicity (no parameters, output schema available), the description covers the essential information: what it lists and why to use it. It lacks explicit prerequisites or notes about the adb environment, but these are likely implied by the sibling tools. The description is adequate for the agent to select and 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?

The tool has no parameters, so per the rubric the baseline is 4. The description adds value by explaining the output format, which is useful even though there are no inputs.

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

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

The description states a specific action ('List all connected Android devices') with a clear resource and details (model, Android version, screen size). It's distinguishable from sibling tools like adb_device_info, though it doesn't explicitly name alternatives. The verb 'list' is specific and the scope 'all connected' is clear.

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

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

The description provides a concrete use case ('Use this to find device serial numbers for targeting specific devices'), which tells the agent when to invoke it. It doesn't explicitly mention when not to use it or name alternative tools, but the context is clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the -r flag (replacement behavior) and device auto-selection, which adds useful context. However, it omits prerequisites (e.g., adb server running, device permissions) and failure modes, so it is not fully 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 two concise sentences plus a clear argument list. The purpose is front-loaded, and every sentence adds value—no redundancy or 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 simple two-parameter install tool, the description covers the action, parameter meanings, and key behavior. An output schema exists, so return values need not be described. Missing are prerequisites and error handling, but these are minor for a straightforward operation.

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

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

Schema coverage is 0%, and the description fully compensates by explaining apk_path (absolute local path) and device (serial number, optional, auto-selection when only one device). This gives the agent complete semantic understanding beyond the raw schema.

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

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

The description clearly states the tool's verb and resource: 'Install an APK file on the Android device.' This is specific and distinct from siblings like adb_push (file transfer) or sim_install (iOS simulator), so an agent can immediately identify the correct 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?

The description states the primary use case (installing an APK) but does not explicitly contrast with alternatives such as adb_push or sim_install. There is no direct when-to-use/when-not-to-use guidance, though the name and scope make it implicitly clear.

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

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

With no annotations, the description carries the burden. It discloses that it sends a key event, accepts aliases, full key names, numeric codes, and explains device auto-selection. It does not describe side effects, failure modes, or whether the key event is verified, leaving some behavioral ambiguity.

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, front-loaded with the core purpose, then lists accepted input formats, then documents arguments. Every sentence adds useful information with no filler or redundancy.

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

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

For a simple two-parameter tool, the description covers input formats and device selection sufficiently. Since an output schema is reported to exist, return-value documentation is not required. Minor gaps around error handling and multi-device behavior when device is omitted do not prevent correct usage.

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

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

Schema coverage is 0%, so the description must compensate. It thoroughly explains the key parameter with examples of aliases and numeric codes, and describes the device parameter's default behavior when omitted. This adds significant meaning beyond the bare schema.

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

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

Description states a specific action: send a key event to the Android device, and distinguishes the tool's scope by listing accepted aliases and full KEYCODE names. This clearly separates it from sibling tools like adb_tap, adb_swipe, and adb_type_text.

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 explains accepted key formats and device selection behavior, including auto-selection when only one device is connected. However, it does not explicitly say when to prefer this over similar siblings such as app_key or adb_tap, or mention prerequisites like requiring a connected device.

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

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

With no annotations, the description must carry behavioral disclosure, and it does add value: default activity is launched if activity is omitted, and device selection defaults when only one device is connected. However, it does not disclose behavior with multiple connected devices, what happens if the package is missing, or how errors are 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 main behavior is stated in the opening sentence, followed by a short fallback clarification and a clean Args block. Every sentence adds useful information and the length is appropriate for a simple launch 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 definition is largely complete: all parameters, optional defaults, and the fallback launch behavior are described, and an output schema exists so return values do not need explanation. Minor gaps remain around error handling when the app/package is absent and the exact consequence of multiple connected devices without a specified serial.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining all three parameters with examples, optionality, and defaulting behavior. Each argument's purpose and format are covered in plain language.

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

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

The description uses a specific verb and resource: 'Launch an app on the Android device.' It also clarifies the default behavior when no activity is given, and the adb_ prefix plus Android mention distinguishes it from siblings like launch_app and sim_launch.

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 invocation context (Android device, optional device serial, activity fallback) but does not explicitly state when to choose this tool over alternatives such as launch_app, sim_launch, or adb_install. No alternative or exclusion is mentioned, so the guidance is implied rather than direct.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose the read-only nature, case-insensitive filtering, and auto-selection behavior when only one device is connected. However, it does not describe behavior when multiple devices are connected without a serial or define the scope of the returned package list.

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, using one clear purpose line followed by concise parameter explanations. Every sentence adds useful 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?

The tool is simple, has no required parameters, and an output schema exists, so the description does not need to detail return values. It covers the core operation and parameter semantics well, leaving only minor gaps such as multi-device behavior.

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

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

Schema coverage is 0%, but the description fully explains both parameters: filter_text is an optional case-insensitive filter, and device is the serial number with auto-selection behavior. This adds meaningful semantics beyond the schema's type and default information.

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 'List installed packages on the Android device', a specific verb and resource that clearly states the tool's function. It is easily distinguished from sibling adb_* tools such as adb_device_info or adb_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?

No guidance is given about when to use this tool versus alternatives like adb_device_info or adb_install. The description covers parameter behavior but lacks explicit when-to-use or when-not-to-use context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the basic operation but does not disclose what happens if the remote path does not exist, whether the local path is overwritten, whether directories are created, or what the command returns on success/failure. For a file-transfer tool with no annotation coverage, this is a significant gap.

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

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

The description is compact and front-loaded with the core action in the first sentence. The Args section is structured and readable. It earns its place with no filler, though the device explanation could be slightly more concise.

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

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

The tool is a simple file-pull operation with 3 parameters and an output schema, so the description covers the essential invocation details. However, it lacks behavioral details like overwrite behavior, error handling, and return value semantics, which an agent would need to handle failures gracefully. The output schema exists but the description does not reference it, leaving the agent to infer what the tool returns.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning for remote_path and local_path with an example path, and explains the device parameter's auto-select behavior. However, it does not clarify path format nuances (e.g., whether local_path can be a directory, whether remote_path must be absolute) beyond the example. The description adds some value but does not fully compensate for the 0% schema coverage.

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

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

The description states a specific verb ('Pull') and resource ('file from the Android device to the local machine'), which clearly distinguishes it from the sibling adb_push. The direction of transfer is explicit, so an agent can tell this tool from adb_push without opening the schema.

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

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

The description gives clear context for the device parameter (auto-selects when only one device is connected), which is useful usage guidance. However, it does not explicitly state when to use this tool versus alternatives like adb_push or paserver_get, nor does it mention any prerequisites such as device connection or adb availability. The usage context is implied but not fully elaborated.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It mentions device auto-selection but omits important behaviors such as overwrite semantics, permission requirements, error handling (e.g., what happens if the local file does not exist), and whether directories are created automatically. For a write operation like push, this is a significant gap.

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

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

The description is concise and front-loaded with the action. The parameter list is clean and easy to scan, with no redundant information. It does not waste words and is appropriately sized for a simple 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?

For a basic file push, the description covers the essential parameters and core behavior, but it lacks details about return values or error conditions. The output schema exists but is not referenced, so the agent cannot predict the response format. It also omits prerequisites like ADB server status. Given the tool's simplicity, this is acceptable but not complete.

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

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

The schema has 0% description coverage, and the description compensates well by explaining each parameter: local_path, remote_path with an example, and device with auto-selection logic. This adds meaningful context beyond the schema's type-only definitions, though the explanations are brief.

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 action: 'Push a file from the local machine to the Android device.' This specifies the verb, resource, and direction, distinguishing it from siblings like adb_pull (pull) and adb_install (install). It does not explicitly name alternatives, but the purpose is unambiguous.

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

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

The description provides basic usage and explains the device parameter's auto-selection behavior, which is useful. However, it does not state when to use this tool versus alternatives (e.g., 'use this for transferring files to the device'), nor does it give any exclusion criteria. The intended use is implied but not explicit.

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

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

With no annotations provided, the description must disclose behavioral traits itself. It explains the optional device parameter and auto-selection behavior, and states that it returns the screen image. However, it does not clarify the output format (e.g., binary data, file path) or potential error cases (e.g., multiple devices without specifying one). This leaves some ambiguity about side effects and return semantics.

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 concise and well-structured, leading with the core action and then providing purpose and parameter details. The Args section is clearly labeled. It avoids unnecessary verbosity, though the purpose line could be integrated more tightly with the action line. Overall, it is efficient and easy to scan.

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

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

For a tool with a single optional parameter and no output schema, the description covers the primary functionality and usage. However, it lacks details about the return value's representation (e.g., is it a base64 string, a file path?) and does not mention failure modes (e.g., no devices connected, multiple devices without a specified device). These gaps could leave an agent unsure how to consume the result or handle edge cases.

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

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

The single parameter 'device' is fully explained: it is the serial number, and the description covers the default behavior when omitted (auto-selects if only one device). This adds significant meaning beyond the schema, which only provides type information. Since schema description coverage is 0%, the description fully compensates for the parameter.

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

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

The description clearly states the action: 'Capture the Android device screen as a screenshot.' It specifies the resource (Android device) and the outcome (screen image for visual inspection). The mention of 'Android' distinguishes it from sibling tools like sim_screenshot (iOS simulator) and screenshot_app, providing implicit differentiation.

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

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

The description provides explicit guidance on when to use the tool: 'Use this to see what's currently displayed on the device.' It does not explicitly mention alternatives or when not to use it, but the 'Android device' qualifier implicitly differentiates from similar screenshot tools. It could be improved by naming alternative tools for other platforms, but the current 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 must fully disclose behavioral implications. It only states the action ('force-stop') and the device auto-selection rule. It fails to mention side effects like data loss, app state reset, or that force-stop is more aggressive than a normal stop. It also doesn't explain error behavior (e.g., if app not running or multiple devices connected).

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 concise and well-structured: a one-sentence purpose followed by a compact Args list. It front-loads the core action and uses minimal words. Every sentence contributes value, and there is 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 simple force-stop tool, the description covers the main behavior and parameters. However, it omits important context like side effects, error conditions, and what happens with multiple devices when 'device' is not specified. Since there is no annotation coverage, these gaps reduce completeness. The presence of an output schema might cover return values, but we don't see its content.

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?

Although schema description coverage is 0%, the description's Args section compensates well. It explains the 'package' parameter with an example and clarifies the 'device' parameter's behavior when omitted (auto-selects when only one device). This adds meaning beyond the schema's bare type/default information.

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: 'Force-stop an app on the Android device.' It uses a specific verb ('force-stop') and resource ('app'), making it distinct from sibling adb tools like adb_launch_app or adb_install. No ambiguity remains about what action this tool performs.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for terminating a running app, nor does it contrast with adb_launch_app or adb_install. There is no mention of prerequisites (e.g., device connected) or exclusions (e.g., not for stopping system apps).

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful context like swipe duration defaulting to 300ms and device auto-selection, but does not disclose coordinate-space/pixel units, whether the gesture waits for completion, or potential side effects from triggering touch handlers.

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 purpose sentence is followed by a clean argument list with no filler. Every line adds information and the core behavior is front-loaded.

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

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

For a simple gesture tool, the description covers the purpose, every parameter, default behavior, and device selection. Since an output schema exists, return-value explanation is unnecessary; only minor caveats like screen-pixel units are 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 description coverage is 0%, so the description fully compensates by documenting all six parameters: start coordinates, duration, and optional device serial with auto-selection nuance. This is essential because the input schema only provides names and types only.

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 ('Swipe') and resource ('Android device screen') with direction from one point to another. This clearly differentiates it from sibling tools like adb_tap, adb_key, and adb_type_text.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as adb_tap, nor mention of prerequisites like a connected Android device. The description only notes auto-selection behavior when a single device is connected, which is parameter context rather than usage 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, the description must carry the full behavioral burden. It does state the core side effect (tapping a point), coordinate semantics, and device auto-selection when a single device is connected. However, it does not disclose failure behavior when multiple devices are present and no device is specified, or any other details about the tap lifecycle.

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 well-structured, front-loading the action and then listing parameters in a readable Args block. Every sentence contributes useful information 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 simple coordinate-tap tool, this is nearly complete: all parameters are semantically explained Becker, output schema exists to cover return values, and device handling is stated. It could be slightly stronger by noting the coordinate origin or multi-device failure mode, but 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?

The schema provides only types and defaults, while the description adds real meaning: x and y are pixel coordinatesasi, and device is an optional serial number with auto-selection behavior. This fully compensates for the 0% schema description coverage.

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

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

The description states a specific action ('Tap') on a specific resource ('Android device screen') and grounds it in pixel coordinates. This immediately differentiates it from siblings like adb_swipe, adb_key, and adb_type_text.

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

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

The intended use is implied: tap at a pixel coordinate on the screen. However, there is no explicit guidance on when to use this instead of alternatives like adb_swipe or app_click, nor any when-not-to-use or exclusionary conditions beyond the device auto-selection note.

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

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

With no annotations present, the description carries the behavioral burden. It discloses that text is escaped for the adb shell, that special characters are handled automatically, and that device auto-selection occurs when only one device is connected—valuable context beyond the schema.

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

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

The description is compact, front-loaded with the core action, and uses a short Args block for parameter details. Every sentence adds useful information without unnecessary elaboration.

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

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

For a 2-parameter tool with one required simple parameter and an output schema, the description covers the main behavior, prerequisites, and device-selection nuance. Nothing essential for calling the tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It adds useful meaning for 'device' by explaining serial number use and auto-selection behavior. The description of 'text' is minimal, but the parameter is self-explanatory and the escaping note adds practical 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 action and resource: 'Type text on the Android device.' This is specific and understandable, though it does not explicitly distinguish itself from the similarly named sibling 'app_type'.

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

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

The description gives an important prerequisite ('The device must have a text field focused') and explains device selection behavior, but it does not explain when to prefer this tool over alternatives like app_type or adb_key.

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 discloses the mechanism ('Uses PostMessage with automatic child window targeting'), the coordinate system ('screenshot pixels'), and case-insensitive window matching. It does not cover side effects like focus changes or failure modes, but the primary behavior is well explained.

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 structured with a clear intro, a usage hint, a mechanism note, and an Args list. It front-loads the purpose and each section earns its place. Slightly verbose but still focused – the workflow sentence is necessary for correct use.

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 moderate parameter count (5) and presence of output schema, the description covers the essential call context: coordinate acquisition via screenshot, window targeting, and each argument's meaning. It does not describe error behavior or prerequisites like visible windows, but for a click tool this 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 0%, so the description must fully document parameters. It does: window_title (full or partial, case-insensitive), x/y (screenshot pixels), button (left/right with default), double_click (boolean meaning). This adds meaningful semantics that the schema fails to convey.

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

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

The description states a specific action ('Click') on a specific resource ('Windows application window at the given coordinates'), and distinguishes it from related tools like screenshot_app (captures the screen for coordinate reference) and adb_tap (Android-specific). The verb+resource+method is explicit and 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?

Provides explicit workflow guidance: 'take a screenshot_app first to identify where to click, then use those pixel coordinates here.' This tells the agent when and how to use the tool. It does not list explicit 'when not to use' or alternatives, but 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?

With no annotations, the description carries the full behavioral burden. It discloses the action, supported special keys, modifier combinations, and case-insensitive partial title matching. It does not mention focus requirements, window-not-found behavior, or whether the window is activated first, which are meaningful for a window automation 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 well-structured and front-loaded: purpose first, then supported inputs, then parameter details. Every line adds useful information, with no filler or repetition of schema fields.

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 tool with an output schema, the description covers the platform, key formats, modifier syntax, and window title matching semantics. It is largely complete, though it could improve by noting what happens if no matching window is found or if multiple windows match.

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

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

Schema coverage is 0%, but the description fully compensates by explaining both parameters: window_title supports full or partial case-insensitive titles, and key accepts named keys or modifier combinations with concrete examples like 'enter', 'ctrl+a', and 'f5'. This adds substantial meaning beyond the bare string schema.

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

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

The description clearly states the tool sends a key or keyboard shortcut to a Windows application window, using a specific verb and resource. It distinguishes itself from Android-targeted siblings like adb_key by specifying Windows, but does not explicitly differentiate from app_type or app_click.

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 useful context that this targets Windows application windows and lists supported special keys and modifier combinations. However, it does not explicitly state when to use this tool instead of related siblings such as app_type or adb_key, so usage guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that typing targets the currently focused control and supports Unicode characters, which is meaningful. It does not, however, mention what happens if the window is not found, whether the window is activated, or any waiting/error behavior.

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

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

The description is compact and front-loaded with the primary action, followed by a brief mechanism, a prerequisite, and parameter definitions. Every sentence earns its place and no unnecessary filler is present.

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, the description covers the core action, mechanism, prerequisite, and parameter semantics. Because an output schema exists, the agent does not need the description to explain return values. It could still note error conditions, but the current information is sufficient for correct invocation in most cases.

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

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

Schema description coverage is 0%, so the description must define the parameters itself. It does this for window_title by adding 'Full or partial window title (case-insensitive)' and for text by stating 'The text to type.' This adds value beyond the bare schema property names, though the text description is largely tautological.

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: 'Type text into a Windows application window.' It further clarifies the mechanism ('Sends Unicode characters to the window's currently focused control') and distinguishes itself from sibling tools like adb_type_text by explicitly scoping to Windows applications. This makes 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 gives a clear prerequisite for correct use: 'Click on a text field first with app_click to focus it.' This tells an agent the required preceding action. It does not explicitly enumerate exclusions or alternatives, but the Windows-focused context makes the intended use clear.

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

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

With no annotations, the description fully carries behavioral disclosure. It reveals side effects like deep-cleaning staging directories, modifying the .dproj file during synthesize_ios_manifest with a timestamped backup, PAServer reliance, path-resolution behavior, and a safe-guard that prevents cleaning outside the project tree.

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 with clear sections and front-loaded purpose, following with usage distinction, then detailed parameter-specific behavior. Given the tool's high complexity and many conditional paths, each sentence earns its place and supports correct invocation.

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 prerequisites, supported platforms, output path resolution, cleanup semantics, remote build behavior, deployment chaining, and iOS manifest caveats. Since output schema exists, the description does not need to explain return values, and no critical selection or invocation 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 description coverage is 0%, and the description compensates thoroughly by documenting all 10 parameters beyond their schema types/defaults. Each parameter's meaning, auto-default behavior, valid contexts, and ignored contexts are explained (e.g., remote_profile required for PAServer, ignored for Win32/Android, deploy auto-enable rules).

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: building an existing Delphi .dproj project via MSBuild + rsvars.bat, honoring the full RAD Studio configuration. It also explicitly contrasts itself with the sibling compile_delphi_project, making the distinction clear without opening schemas.

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

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

Usage guidance is explicit and prominent: use this for real projects already on disk, not for generated templates, with a NOTE naming the sibling tool to use instead. It also gives when-to-use conditions for platform, deploy, deep_clean, remote_profile, and iOS manifest synthesis.

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 clearly states the tool is read-only ('only INSPECTS; never mutates') and explains the consequence of missing entries. However, it does not describe the exact return value or any potential errors beyond the missing-entry scenario, though the output schema likely covers the return structure.

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: it opens with the primary purpose, provides necessary context (PAServer behavior and failure mode), states the read-only nature and the alternative, then lists args. Every sentence earns its place, and it is front-loaded with the key 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 narrow scope (checking a dproj for specific entries) and the presence of an output schema, the description is complete. It explains why the check matters, what entries are expected, how to fix if missing, and covers all parameters. No critical information is omitted.

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 only provides titles and defaults with no descriptions, so the description must compensate. It does so thoroughly: dproj_path is 'Absolute path to the .dproj', config is 'Build configuration to check (Debug, Release, etc.)', and platform is 'iOSDevice64 or iOSSimARM64'. This adds meaning beyond the schema and fully documents each 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's function: it checks whether a .dproj has the iOS DeployFile entries required for Deploy. It names the specific entries (ProjectiOSEntitlements, ProjectiOSInfoPList, etc.) and contrasts with the sibling build_dproj, which is the repair path. This fully distinguishes it from the many simulator/deploy 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 explicitly says when to use it (to verify required entries) and what to do when entries are missing (use synthesize_ios_manifest=True on build_dproj). It also explains the common cause (renamed project or never IDE-deployed) and the failure mode, leaving no ambiguity about the appropriate context.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the operation is syntax-only, skips linking, produces no executable, and auto-selects a compiler when none is provided. It does not explicitly describe side effects or output behavior, but the output schema is present and the main 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 summary line is front-loaded and immediately states the core behavior, followed by a one-sentence rationale and a compact parameter list. No sentence is wasted; even the note about compiler auto-selection earns its place.

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

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

The tool has only two parameters, both well-documented, and an output schema that presumably covers return values. The description is sufficient for safe invocation; it could additionally clarify that no runtime execution occurs, but 'syntax-only' and 'without producing an executable' already imply that.

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

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

Schema description coverage is 0%, so parameter documentation is entirely the description's responsibility. It fully compensates: source_code is identified as the Pascal code to check, and compiler is explained with valid values ('fpc', 'dcc32', 'dcc64'), paths, and the auto-selection default behavior.

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

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

The first sentence names a specific verb and resource ('Check Pascal syntax') and explicitly states the tool produces no executable, which distinguishes it from sibling compile_pascal and run_pascal. The second sentence reinforces the distinction by contrasting it with a full compile.

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 frames when to use the tool: it is faster than a full compile and intended for quickly validating code structure. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to route simple validation tasks here.

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

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

There are no annotations, so the text must carry the safety/behavioral burden. It discloses that the tool generates project structure, invokes dcc32/dcc64 or Free Pascal, defaults to a temp output directory, and emits a populated .dproj for fmx. It does not address overwrite behavior or compiler prerequisites, but the core side effects are 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 front-loaded with the critical prohibition and tool purpose, then organized by Args with each parameter earning its place. Examples for components and events are compact but make an otherwise ambiguous JSON-string parameter concrete.

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, unannotated, 8-parameter tool with 0% schema coverage, the description provides enough to select and invoke it correctly, including enum-like project types and conditional program_body usage. It does not explain what happens when compiler is null or when output_dir is omitted beyond the temp-directory note, but an output schema exists to cover return behavior.

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

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

With 0% schema description coverage, the Args section is the only documentation for all 8 parameters. It explains project_type variants, gives JSON shapes and supported types for components/events, describes compiler choices and output_dir fallback, and ties program_body to console/fpc projects, far exceeding the bare schema.

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

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

The first sentence names a precise action and resource: compile a Delphi project using DPR/PAS/DFM templates. It further claims to be the ONLY correct way to build Delphi applications, and the fmx note distinguishes it from build_dproj by generating a .dproj rather than building from one.

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 direction: do NOT use MSBuild, shell commands, or other build systems, and it tells the agent to use project_type='fmx' when a mobile-ready or Android/iOS/macOS app is desired, with build_dproj as the follow-up. It does not explicitly compare against compile_pascal or run_pascal, but for Delphi project builds this tool is clearly positioned as the intended choice.

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 does not run the code and returns compiler messages including errors/warnings. However, it does not mention potential side effects like creating executable files or intermediate artifacts, which could be relevant for a compile tool. This is a minor gap but not misleading.

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 appropriately sized, with a clear main purpose, a usage note, and a structured Args section. It is front-loaded with the core action and avoids redundancy. While it could be slightly more compact, it is efficient and easy to parse.

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

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

Given that there is an output schema (though not shown), the description doesn't need to detail return values beyond stating it returns compiler messages. It covers the two parameters thoroughly and the main use case. It could mention what happens on successful compilation (e.g., no output or a success message), but the existing text is adequate for an agent 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 schema has no descriptions for the parameters (0% coverage), so the description fully compensates. It explains that source_code must include the program/unit header, and it details the compiler parameter, including allowed values (type names or full paths) and default auto-selection behavior. This adds significant meaning beyond the schema's type definitions.

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 'Compile Pascal source code and return compiler output,' which is a specific verb and resource. It distinguishes itself from siblings like run_pascal (which executes code) and check_syntax (which likely only checks syntax). The mention of 'without running it' 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 explicitly says 'Use this to check if code compiles without running it,' providing a clear when-to-use directive. It doesn't explicitly name alternatives like run_pascal or check_syntax, but the context of sibling tools makes it clear. It lacks an explicit exclusion for when not to use it, but the purpose 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states exactly what happens: ShowWindow(SW_RESTORE) and SetForegroundWindow are called, and it returns a confirmation or an error if no IDE is running. It does not mention potential side effects like focus stealing or permission requirements, but for this simple utility, the transparency is adequate and goes beyond a bare 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 description is compact and front-loaded: the primary purpose is in the first sentence, followed by a brief step-by-step breakdown, the rationale, and the return behavior. Every sentence contributes meaning without redundancy. It is well-structured for an agent to quickly parse the 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?

For a zero-parameter tool with an output schema (confirmed) and no annotations, the description covers all necessary aspects: what it does, why it is needed, when to call it, and what it returns. The tool is simple, and the description provides sufficient context for correct invocation. Nothing critical 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 tool has zero parameters, and the input schema is empty with 100% coverage. Per the rubric, 0 parameters warrants a baseline of 4. The description adds no parameter-specific details because there are none to document. It does not need to compensate for any schema gaps since there are no parameters.

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

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

The description opens with a precise action: 'Restore the Delphi/Lazarus IDE window and bring it to the foreground.' It clearly names the resource (the IDE window) and the two concrete operations (ShowWindow/SW_RESTORE and SetForegroundWindow). It also distinguishes itself from siblings by positioning itself as a precondition for other IDE-driven workflows, which implies it is not the tool that observes or interacts, but the one that makes them possible.

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

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

The description gives explicit usage direction: 'Call this first whenever you're about to interact with the IDE.' It explains why by noting that observe_ide's screenshot is more reliable on a foreground window and that UI automation requires the window to be visible. This tells the agent exactly when to invoke it relative to other tools, though it does not name alternatives explicitly, the guidance 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 provided, the description carries the full burden and does so thoroughly. It discloses a non-obvious side effect (emitting notifications/tools/list_changed), explains why it happens, and reassures that failure to honor it is non-breaking. It also describes the search scope: PATH and common installation directories.

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 structure is effective: purpose first, then detection scope, then return value, then side effect. The side-effect explanation is slightly long, but it earns its place because no annotations provide that safety context.

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

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

A parameterless tool with an output schema needs little more; the description covers which compilers are checked, where they are searched, what is returned, and the side effect. An agent can decide when to call it and understand the consequences 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 tool has zero parameters and the schema covers 100% of them, so the description does not need to add parameter details. The baseline of 4 for zero-parameter tools applies; nothing 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?

The description opens with a specific verb and resource: detect available Pascal compilers. It names exact compilers checked (fpc, dcc32, dcc64) and clearly distinguishes itself from sibling tools that compile, run, or launch applications.

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

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

The description conveys that this is a discovery tool for checking compiler availability and notes it is cheap to call, but it never explicitly states when to choose it over siblings like compile_pascal or setup_fpc. Usage is implied rather than explicitly contrasted with alternatives.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It reveals that the tool uses the Mac's keychain certificate, that ad-hoc signing is development-only and won't install on real devices, and that notarization requires Apple Developer Program membership plus notarytool setup. This is good transparency. It could be more explicit about side effects (e.g., modifying the .app bundle's signature), but the constraints and requirements 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 well-structured: a lead sentence stating purpose, a paragraph of context and requirements, and a bulleted Args list. It is somewhat long but every sentence adds value. The structure is front-loaded with the core purpose and prerequisites, making it easy to scan.

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

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

Given the tool's complexity (7 parameters, 0% schema coverage, no annotations), the description is remarkably complete. It covers prerequisites, certificate selection, notarization constraints, and all parameters. The existence of an output schema reduces the need to describe return values. No critical information is missing 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 0%, so the description must explain all parameters. The 'Args:' section does exactly that, covering profile, app_path, certificate, entitlement, notarize, timeout, and studio_root, with meaningful details like certificate format and ad-hoc usage. This fully compensates for the missing schema descriptions.

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

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

The description clearly states the verb and resource: 'Codesign an iOS/macOS .app bundle on the remote Mac (paclient -c).' This is specific and distinguishes it from sibling tools like ios_create_ipa or ios_install_ipa, which handle different steps of the iOS deployment pipeline. The purpose is unambiguous.

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

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

The description provides context on when to use the tool: 'The .app must already exist on the Mac (typically in PAServer's scratch dir after build_dproj + Deploy ran).' It also explains the certificate options and notarization prerequisites. While it doesn't explicitly name alternatives, the context makes it clear this is the code-signing step. It lacks explicit 'use this instead of X' guidance, but the prerequisites and caveats are sufficient for most agents.

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 responsibility for behavioral disclosure. It explains that IPA assembly runs entirely on the Mac via xcrun, states the prerequisite codesigning step, specifies ipa_type semantics, and notes the timeout behavior. This is meaningful behavioral context beyond the bare tool name.

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 well organized, with the core purpose stated first and a clean Args list afterward. Every sentence earns its place, covering prerequisites, execution context, and all parameters without 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?

Given the tool's complexity, eight parameters, zero annotations, and an output schema, the description is largely complete: it provides prerequisites, remote-execution context, parameter semantics, and defaults. It does not describe output details, but the output schema covers that responsibility. Minor edge cases like whether out_path directory creation or certificate matching validation are not discussed, but not essential for basic correct use.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: every parameter is explained, including defaults for ipa_type and timeout and the optional studio_root. Each argument's role in the packaging workflow is clear enough for correct invocation.

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: 'Package a signed .app into an .ipa on the remote Mac (paclient -i).' It states the exact artifact transformation and platform, and clearly distinguishes this tool from related siblings like ios_codesign and ios_install_ipa. An agent can understand what the tool does and why it exists without reading the schema.

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

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

The description gives concrete when-to-use guidance: the .app must be codesigned first via ios_codesign, and the provisioning profile must exist and match the certificate and bundle ID. It clearly implies the correct sequencing among siblings, though it does not explicitly call out alternatives for installing or signing specifically.

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 discloses prerequisites and constraints: the device must be physically connected, trusted, and listed by xcrun devicectl; it wraps a specific command (paclient -ii); and it includes a timeout after which the process is killed. It does not describe overwrite behavior or signing requirements, but for an install command the main 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 front-loaded with the core action and resource, followed by prerequisites aids and an arg list. It is concise overall, but the reference to 'tracked under issue #5 (sim_* tools)' adds internal project noise that is not useful for an AI agent selecting 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?

For this moderately complex 5-parameter tool with no annotationscoal, the description is complete: it explains the command wrapper, prerequisites, how to find a UDID, the parameter semantics, the simulator exclusion, and the timeout behavior. Since an output schema exists, the description does not need to document return values.

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

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

Schema description coverage is 0%, and the description compensates by listing all five parameters with meanings: profile as a connection profile name, ipa_path as a remote Mac path, device_udid as the target UDID, timeout as seconds before being killed, and studio_root as optional. Some entries, especially 'profile', are somewhat terse, but the list meaningfully adds beyond the bare property names.

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

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

The description states a specific verb ('Install'), a specific resource ('.ipa'), and a specific target ('iOS device attached to the Mac'), along with the underlying command 'paclient -ii'. It also explicitly distinguishes itself from simulator installation, so an agent can clearly tell it apart from sim_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 explicitly says this is for device installation, not simulator installation, and notes that simulator installation requires 'xcrun simctl install', which 'paclient does NOT wrap'. It also gives preconditions (device physically connected, trusted, listed by devicectl), giving the agent concrete when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden and does so well by disclosing that the app launches in the background, returns immediately, does not wait for completion, and auto-selects a compiler when none is specified. This goes beyond the minimal mutation description and gives the agent an accurate behavioral model.

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 organized with a clear first sentence, a usage paragraph, follow-up action guidance, and an Args section. Every part earns its place, and the key distinguishing behavior is front-loaded at the top.

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 complete for this tool's complexity: it explains the tool's purpose, when to use it, how it differs from siblings, what parameters mean, and what to do after launching. The presence of an output schema reduces the need to explain return values in prose.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining source_code meaning a complete Pascal GUI program with VCL/FMX forms and by detailing compiler as a type name ('fpc', 'dcc32', 'dcc64') or a compiler path with auto-selection behavior. This adds substantial meaning beyond the bare schema titles.

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: 'Compile Pascal source and launch the GUI application in background.' It clearly targets GUI applications, mentions VCL/FMX, and directly distinguishes itself from run_pascal by noting it does not wait for the program to finish.

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: for GUI applications that need to stay running so the agent can interact with them. It names the alternative run_pascal and explains the key difference, and also suggests follow-up tools like preview_start and screenshot_app, giving clear next steps.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It states the tool lists 'visible' windows, implies case-insensitive filtering, and clarifies the empty-filter behavior. However, it does not disclose output format, ordering, potential latency, or any side effects. Since the operation is read-only, that is likely safe, but the description lacks explicit transparency about what happens after invocation. Some behavior is disclosed, so a 3 is appropriate.

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

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

The description is extremely concise, with the purpose and usage stated in the first two sentences. The Args section is minimal and directly explains the parameter. No unnecessary words or redundancy. Every sentence serves a purpose, making it efficient for an agent to parse.

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

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

The tool is simple with one optional parameter, and the description covers the main use case (finding window titles for screenshots) and the filter behavior. An output schema exists, so return values are not required in the description. It does not mention edge cases like minimized windows, but 'visible' is defined. Overall, it is complete enough for an agent to call correctly without further investigation.

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

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

The schema provides only a type and default for filter_text with 0% description coverage. The description compensates by explaining the parameter's purpose: 'Optional text to filter window titles (case-insensitive). Leave empty to list all visible windows.' This adds meaning beyond the schema, clarifying the filtering behavior and the default action. It does not specify whether filtering is substring or exact match, but it is sufficient for most agents.

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 verb 'List' and the resource 'visible application windows on the desktop', and provides a specific use case (finding a window title before a screenshot). It distinguishes itself from sibling screenshot_app by explicitly referencing it as the follow-up action. The filter parameter is also mentioned, 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 guidance on when to use the tool: 'Use this to find the exact title of a window before taking a screenshot with screenshot_app.' It also explains the filter usage and default behavior. It does not explicitly mention when not to use it or alternatives, but the primary alternative (screenshot_app) is referenced, providing clear context for the typical 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, the description carries the behavioral burden. It goes beyond the bare 'list project files' name by disclosing that it scans specific Pascal, form, and project extensions and that it parses .dproj files for units, search paths, and build configuration. It does not discuss edge cases or side effects, but 'List' and the scanning detail provide solid 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 compact and front-loaded with the core purpose, followed by two precise sentences detailing file categories and dproj parsing. The Args section is minimal and useful. There is no redundant text.

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

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

For a read-only listing tool with an output schema present, the description covers the key inputs and behavioral scope. It does not discuss recursion, missing-directory behavior, or return structure, but the output schema and the straightforward nature of the operation make this a minor 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?

The schema only names 'Project Dir', while the description adds that it is a path to the project directory on disk. For a single, obvious parameter this is sufficient semantic grounding even though deeper details like relative vs. absolute paths are omitted.

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

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

The description uses a specific verb ('list') and a clear resource ('source files in a Delphi/Lazarus project directory'), then enumerates exactly which file types are included. This differentiates it from siblings like parse_form, compile_pascal, and run_pascal, even though those alternatives are not named.

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

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

The intended use is implied: call this to discover project files before compiling or running. However, the description does not explicitly state when to use this tool instead of siblings such as parse_form or compile_pascal, nor does it mention any exclusions or prerequisites.

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

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

With no annotations available, the description carries full behavioral disclosure. It details the output profile fields (Name, Platform tag, Host:port, sidecar existence), explains platform filtering semantics, warns that the sidecar .profile file is REQUIRED, explains the default studio_root behavior, and notes profile reuse across Apple targets.

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 longer than average but well-structured with a clear opening statement, useful behavioral bullets, and an explicit Args section. Every section earns its place, though some details could be tightened without loss.

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-optional-parameter read-only listing tool with no annotations, the description is complete: purpose, usage context, parameter semantics, and behavioral quirks are all covered. The presence of an output schema means return-format details are not required in the description.

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

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

Schema coverage is 0%, but the description fully compensates by explaining the only parameter: studio_root with an example path, optionality, and default behavior (highest-version install detected). This gives an agent everything needed to populate or omit the parameter correctly.

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

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

The description opens with the exact function: 'List PAServer Connection Profiles registered in this RAD Studio install.' It names a specific resource (PAServer connection profiles) and a clear action (list), and distinguishes it from related tools like build_dproj and paserver_info by explaining its scoped 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?

It gives concrete usage context: profiles drive remote builds, build_dproj uses them automatically, and listing is useful when troubleshooting specific MSBuild Deploy errors like 'Missing profile name or 'No remote profile.' It does not explicitly state when NOT to use it or name alternatives, so it stops short of a perfect 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 provided, the description carries the full burden of behavioral disclosure. It does this well: it discloses that the tool runs `whoami` over SSH with BatchMode, that it verifies landing on the expected account, and that it returns a fix-up command when key auth isn't set up. This meaningfully adds beyond the tool name. It doesn't cover edge behaviors like timeouts or unreachable hosts, but for a read-only check tool 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?

The description is well structured: a one-line headline, a concise behavioral explanation, then an Args list. The most important information is front-loaded, every sentence contributes necessary context, and the Args section compensates for the schema lacking descriptions. 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?

Given the tool's low complexity, the presence of an output schema, and the absence of annotations, the description is nearly complete. It tells the agent what the tool does, how it behaves, and how to fill each parameter. Minor gaps remain, such as not stating whether a specific SSH port is assumed or what the exact 'expected account' check entails, but these are unlikely to prevent correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate and it does. The Args section explains all three parameters: host with a cross-reference to the PAServer profile's Host field, user as the Mac user account, and key_path as an optional explicit private key path. This adds real meaning beyond the bare schema titles, though it stops short of providing examples or format constraints.

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: 'Test SSH connectivity + key auth to the remote Mac.' It then details the exact mechanics (runs `whoami` with BatchMode, verifies the expected account, returns an ssh-copy-id command on failure). This clearly distinguishes it from sibling tools like mac_ssh_run, which would run arbitrary commands, and paserver_check_connection, which checks PAServer connectivity rather than SSH key auth.

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 clear context for when to use the tool: to verify SSH connectivity and key-based authentication to a target Mac, and to get a concrete remediation command if key auth is missing. It also cross-references paserver_info for obtaining the correct host address. However, it does not explicitly name alternatives or state when not to use it (e.g., 'use mac_ssh_run to execute arbitrary commands'), so it stops short of the explicit-when/when-not level.

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

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

No annotations are provided, so the description carries full burden. It states it runs arbitrary commands but does not disclose that this can have destructive side effects, does not describe what is returned (though output schema exists), and does not mention authentication behavior beyond optional key_path. The timeout behavior is noted, but overall the safety and outcome profile is underspecified for a remote execution tool.

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

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

The description is well-organized: a one-line purpose, a short usage context, and a compact args list. It is front-loaded with the core purpose and avoids redundancy. The 'Quote internal spaces yourself' tip is a valuable, non-obvious addition that 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 generic remote command runner, it covers the essential aspects: purpose, usage, and parameter details. It does not mention checking connectivity with mac_ssh_check or other prerequisites, but the output schema likely covers return values. Given its role as a low-level building block, it is reasonably complete, though it could benefit from a warning about potential side effects.

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

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

Schema description coverage is 0%, so the description must explain each parameter. It does so concisely: host (hostname or IP), user (account), command (single line, quote internal spaces yourself), key_path (optional explicit key), timeout (seconds before killed). This adds practical meaning beyond the raw 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 precise verb and resource: 'Run an arbitrary command on the remote Mac via SSH.' It explicitly positions itself as the generic building block and contrasts with sim_* wrappers, making its unique role clear and distinguishing it 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 gives direct routing guidance: 'Most callers should prefer the sim_* tools that wrap simctl directly; use this when you need something specific that doesn't have a wrapper.' This explicitly tells when to use it and when not, naming the alternative category.

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 disclosing behavior. It explains the non-destructive flow: find a running IDE window, capture a screenshot, optionally scan the project directory. It does not cover failure behavior when no IDE is found, prerequisites, or permission requirements.

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-loads the purpose, then explains behavior, then gives parameter semantics in a clean Args section. There is minor redundancy between 'Delphi/Lazarus IDE' and 'RAD Studio, Delphi, or Lazarus,' but no material 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 tool with one optional parameter and no output schema, the description covers purpose, behavior, parameter semantics, and expected outputs adequately. Missing details about return structure and error cases like 'no IDE window not found' keep it 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 only says project_dir is a string or null with zero description coverage, but the description adds real meaning: it is an optional path to the project directory and, if provided, the tool also returns a list of source files. It lacks path format guidance or examples, so not a 5.

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

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

States a specific action (observe/capture screenshot of the Delphi/Lazarus IDE) and describes the combined output of screenshot plus project info. It is clear what the tool does, though it does not explicitly contrast itself with sibling tools like screenshot_app, focus_ide, or read_ide_errors.

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

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

Gives clear context for when to use it: the agent should call this when Claude needs to spot compiler errors, warnings, or messages in the IDE's Messages pane. It stops short of a 5 because it does not explicitly state when not to use it or name alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses what files it reads and what it returns (components, properties, positions, sizes, event handlers) and documents the three output formats. However, it does not disclose error behavior for invalid paths or malformed files, nor does it explicitly state that parsing is non-destructive. Decent coverage but gaps remain.

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

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

The purpose is front-loaded in the first line, followed by a detail paragraph and a structured Args section. The Args documentation is genuinely useful and not redundant. Slightly longer than necessary but every sentence earns its place given the three output formats to explain.

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

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

An output schema exists, so return-value explanation is not required. The description covers supported input formats, output structure, and all parameters. The main gap is error-handling behavior for invalid files, which is relevant for a file-parsing tool but not critical to correct invocation.

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

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

Schema description coverage is 0%, so the description must fully compensate. It documents both parameters: file_path (absolute path requirement) and output_format (with all three enum values and the default 'tree'). This adds meaning well beyond the bare schema, which only provides types and a default.

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

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

States a specific verb (parse) + resource (Delphi/Lazarus form files) + result (component structure). Explicitly enumerates the three supported formats (.dfm/.fmx/.lfm). None of the 50+ siblings are form-parsing tools, so it is clearly distinguishable.

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

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

The description specifies which file types it handles (.dfm/.fmx/.lfm), which implicitly tells an agent when to call it. However, it gives no explicit when-not-to-use guidance, no exclusions, and no alternative tools to route to. The sibling set contains no other parsing tools, so this is acceptable but not explicit.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It explains the operation is a read-only reachability probe, specifically listing the two stages and clarifying that no password-based handshake happens. This fully informs the agent of what behavior 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 longer than average but every sentence earns its place: what it does, the fallback guidance, the practical use case, then a compact Args block. The core behavior is front-loaded, and the structure makes it easy to scan.

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

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

The tool has a moderate parameter count and no annotations, but the description covers behavior, limitations, use case, and parameters thoroughly. An output schema exists, so not describing return values is acceptable. It is complete enough for an agent 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 0%, so the description must compensate. It does: profile gets a concrete example ('MACBOOK'), timeout gets meaning ('TCP connect timeout in seconds. Default 3.'), and studio_root is marked optional with its purpose as Studio install root. This adds meaningful meaning beyond the raw 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: 'Two-stage reachability check for a PAServer Connection Profile.' It enumerates exactly the two stages, names what it does not do (full protocol handshake), and distinguishes itself from file-transfer tools by positioning this as the pre-flight check.

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

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

It explicitly tells the agent when to use this tool: 'Use this as the first pre-flight step before iOS/macOS/Linux builds or before paserver_get/paserver_put.' It also gives the alternative path: for full validation, run a file-transfer tool. This is clear, actionable guidance for selection.

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

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

With no annotations present, the description carries the full behavioral disclosure burden, and it delivers: it reveals that paclient --get silently writes nothing on Windows, that SSH preserves directory bundles like .app/.dSYM, that relative paths resolve against the scratch root, that local_dir is created if missing, and that SSH requires one-time ssh-copy-id setup. These are the exact behavioral traits an agent needs to predict 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 long but every sentence earns its place: transport rationale, failure warnings, path resolution semantics, and per-parameter details are all load-bearing. The Args block is cleanly structured and front-loads the most critical guidance (prefer ssh_user) before the parameter list. 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 7-parameter transfer tool with zero annotations and no schema descriptions, the description covers all necessary invocation context: transport selection, failure expectations, path resolution, directory creation, authentication prerequisite, timeout guidance, and optional parameters. The output schema exists, so return-value documentation is not required. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must fully compensate for the bare schema properties. It explains every parameter meaningfully: profile resolves the Mac host, remote_path can be absolute or relative with concrete examples, local_dir is created if missing, ssh_user enables the SSH transport and is not stored in profiles, ssh_key_path is the explicit key, timeout defaults to 300 seconds and should be bumped for large bundles, and studio_root is optional. This far exceeds what the schema alone 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: 'Pull a file or directory from the PAServer remote host to this box.' It clearly differentiates the tool's direction and scope from siblings like paserver_put, and adds detail about the transport mechanism (SSH vs paclient). An agent can immediately understand what this tool does and how it relates to the surrounding PAServer tool family.

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 instructs the agent to prefer ssh_user because it routes over the reliable SSH tar-stream path, and warns that the fallback paclient --get is broken on Windows 37.1. It states exactly when the fallback is acceptable ('kept only for hosts where SSH isn't set up') and even flags expected failure. This is exemplary when-to-use guidance that directly steers tool 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 full disclosure. It states the operation is a pure local read with no network touch, enumerates the returned data, and explains that it validates against the registry to produce a clear error on typos, which is a notable behavioral trait. This fully informs the agent 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 concise and well-structured: it opens with the core purpose, then clarifies scope and output, then gives usage context and error behavior, and finally lists parameters with precise details. Every sentence adds value, and the structure is front-loaded with the most important information.

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

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

For a simple read tool, the description covers all necessary context: purpose, output fields, prerequisites, error handling, and parameter semantics. The presence of an output schema reduces the need to explain return structure in detail, and nothing essential is missing for an agent 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 0%, so the description must compensate. It explains the profile parameter as case-sensitive with an example, and describes studio_root as optional with a default behavior. This adds meaningful context beyond the bare schema definitions, making parameter usage clear.

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 ('Read') and identifies the exact resource ('local info about a PAServer Connection Profile') with an explicit method reference (paclient -l). It clearly differentiates from siblings by stating it is a pure local read that does not touch the network, making its purpose unmistakable.

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

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

It provides clear usage context by stating the prerequisite that the profile must already exist in the HKCU registry and explicitly points to list_remote_profiles for enumeration. It also explains error behavior for unknown names. It does not explicitly say when NOT to use it beyond implying local vs. network, but the guidance is sufficient for correct selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the operation (file transfer) and mentions timeout and wildcard behavior. However, it doesn't disclose potential side effects such as overwriting existing remote files, permission requirements, failure modes, or whether the remote directory must exist. For a transfer tool with zero annotation coverage, this is a moderate gap, justifying a 3.

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: an opening sentence that states the purpose, a line about the wrapper, a sentence listing use cases, and a clean 'Args' section. It is front-loaded with the primary action. It is not overly verbose, though the use-case sentence could be considered slightly redundant. Overall, it is concise and easy to scan, earning a 4.

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

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

Given the tool has 5 parameters, no annotations, and an output schema (though not shown), the description covers the essentials: what it does, when to use it, and what each parameter means. It doesn't describe the return value, but since an output schema exists, that is presumably handled separately. It also doesn't discuss prerequisites like an active PAServer connection, but that may be implied by the profile parameter. Overall, it is complete enough for an agent to call it correctly, though a bit more on prerequisites would push it to a 5.

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

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

The schema description coverage is 0%, so the description must explain every parameter, and it does. The 'Args' section provides a clear one-line explanation for each parameter: 'profile: Connection Profile name.', 'local_path: File or directory on this Windows box. May contain wildcards.', 'remote_dir: Destination directory on the PAServer host.', 'timeout: Seconds before the transfer is killed (default 300).', and 'studio_root: Optional Studio install root.' This fully compensates for the missing schema descriptions and adds value by clarifying defaults and optionality.

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

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

The first sentence clearly states the action ('Push a file or directory') and the resource ('to the PAServer remote host'). It also mentions the wrapped command, which adds specificity. However, it doesn't explicitly differentiate from the sibling tool 'paserver_get' (which pulls), though the verb 'push' implies the direction. Sibling differentiation is not explicit, so it earns a 4 rather than a 5.

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

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

The description provides concrete use cases: 'staging files for a manual remote build, replacing assets the IDE didn't deploy, or seeding the PAServer scratch directory.' These are clear contexts for when to use this tool. However, it doesn't explicitly state when not to use it or mention alternatives like 'paserver_get' for the reverse direction. The guidance is present but not exhaustive, earning a 4.

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 remote deletion behavior and warns about wildcard dangers, but does not explicitly state that deletion is permanent and irreversible. This is a meaningful gap for a destructive 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 tight and well-structured: purpose first, then a clarifying note, usage guidance, a warning, and a formatted argument list. Every 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?

The description covers purpose, usage, warnings, and parameter semantics. Since an output schema exists (per context signals), return value details are not required. The only omission is an explicit note on irreversibility, but the wildcard warning partially covers safety. Overall, it is complete for a delete 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 0%, so the description must explain each parameter. It does so concisely: profile, remote_path (with wildcard note), timeout (with default), and studio_root (optional). This fully compensates for the lack of schema descriptions.

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

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

The description clearly states the verb 'Delete' and the resource 'a file or directory on the PAServer remote host', distinguishing it from sibling tools like paserver_get and paserver_put. It also clarifies that the `-R` flag targets the remote host, not the local cache, making the intent 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?

It provides explicit use cases ('clean up scratch dirs or old deployments') and a caution about wildcards. It clarifies remote vs. local operation, but does not explicitly name alternative tools for local deletion or other actions, though none are obvious siblings.

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

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

There are no annotations, so the description carries the full burden. It adds meaningful behavioral context: PAServer's restricted-mode path layout, the default restricted mode, and how to discover remote_user. 'Return' implies a read-only helper, and the path formula is disclosed clearly.

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: purpose first, then path context, then usage, then args. Every sentence adds useful information and the Args section is clean and readable.

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 an output schema available and only two required parameters, this description is complete. It covers purpose, path construction, when to use it, and how to obtain the parameter values. No critical context 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 description coverage is 0%, but the description fully compensates. It explains profile with a concrete example ('MACBOOK') and explains remote_user as the Unix username running paserver, including how to find it via SSH or PAServer terminal output.

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: 'Return PAServer's per-profile scratch directory path on the remote host.' This clearly distinguishes it from transfer tools like paserver_put/paserver_get and from generic server info tools like paserver_info.

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 says to use this helper before paserver_put/paserver_get or to clean up after a build. It doesn't spell out when-not-to-use scenarios or name direct alternatives, but the intended usage 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 burden of behavioral disclosure. It clearly frames the tool as a read operation and explains that it returns source code around the given lines, but it does not state side-effect guarantees, file-resolution rules, or context limits. For a simple read tool, the core behavior is disclosed but not deeply.

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 well-structured: purpose, trigger, then parameter documentation with an embedded example. 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 low-complexity, two-parameter read tool with an output schema, the description covers why, when, and how to call it. It does not describe error behavior or how much source context is returned, but those are not essential 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?

Both parameters are documented with practical meanings and a concrete example, which strongly compensates for the 0% schema description coverage. The only weakness is that the schema declares errors as a string while the description presents it as a JSON array, leaving serialization format implicit.

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 names a specific operation and resource: reading source code around compiler error locations. The workflow sentence ties it to parsed IDE-screenshot error locations, making its role distinct from compile, run, and screenshot 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 gives explicit invocation context—after spotting errors in an IDE screenshot, pass parsed error locations—and even includes an example payload. It does not explicitly say when not to use it or name alternatives, so it stops 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?

No annotations are provided, so the description carries the burden of behavior disclosure. It states it compiles, runs the resulting executable, returns both compilation messages and program output (stdout/stderr), and auto-selects the best compiler. It could mention side effects like generated executables or environment dependencies, but the core behavior is clearly disclosed.

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

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

The description is well-structured: a two-sentence top-level summary followed by a compact Args list. Every sentence adds useful information, and the key purpose is front-loaded ahead of parameter 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?

Given the tool's execution complexity and zero annotation coverage, the description covers the main behavioral and parameter aspects well. Minor gaps remain around execution environment, timeouts, and what happens to generated executables, but the presence of an output schema reduces the need to describe return shape.

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

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

Schema description coverage is 0%, but the description's Args section fully documents all three parameters: source_code must be a program with a begin..end block; compiler accepts type names or full paths with auto-selection behavior; stdin_input provides optional input to the program. This adds essential meaning beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'Compile and execute Pascal source code, returning the program output.' This clearly differentiates run_pascal from sibling compile_pascal by including execution, not just compilation, and by returning program output.

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 usage context: source_code should be a complete program with a begin..end block, not a unit; stdin_input is for programs that read input; compiler can be a type name or path with auto-selection. It does not explicitly name alternatives like compile_pascal or check_syntax, but the guidance is sufficient for correct invocation.

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

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

There are no annotations, so the description carries the full burden. It discloses valuable behavioral traits: partial and case-insensitive title matching, capturing only the target window, PNG output, and not stealing focus or disrupting the desktop. It does not mention behavior when no window matches or how the PNG is delivered (file path vs. inline image), which 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?

The description is compact, front-loaded with the core purpose, and organized with an Args section. Every sentence adds value, including the case-insensitive matching detail and the concrete example. There is no wasted or redundant 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 single-parameter, low-complexity tool, the description covers the purpose, parameter semantics, and a useful prerequisite. Without an output schema, it stops just short of specifying the exact return format or where the PNG is written, and it does not cover error behavior. Still, an agent can invoke the tool correctly based on this description alone.

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

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

The schema only defines window_title as a type string with no description, so the description fully compensates. It explains that the title can be full or partial, is matched case-insensitively, and provides a concrete example. This gives an agent everything needed to populate the parameter correctly.

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

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

The description clearly states a specific action and resource: taking a screenshot of a running application window by matching its title. It adds useful detail about capturing only that window as PNG, but it does not explicitly differentiate this from sibling screenshot tools like adb_screenshot or sim_screenshot. The purpose is clear, but sibling differentiation is only implicit.

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 includes an explicit usage hint: use list_app_windows first to find the exact window title. This gives clear context for an important prerequisitecars. Missing are explicit exclusions such as 'for device screenshots use adb_screenshot' or 'for simulator screenshots use sim_screenshot', so the guidance is good but not fully 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It specifies the exact version (3.2.2), the source (official SourceForge mirror), the installation mode (silent), and the potential need for administrator privileges. These details give the agent a realistic picture of the tool's side effects beyond the one-sentence summary.

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. It opens with the core action, follows with the usage condition and behavioral specifics, and closes with the parameter explanation. Every sentence contributes needed information 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?

The tool has one optional parameter, an output schema, and a well-documented installation behavior. The description covers the invocation condition, download source, version, silent-install behavior, privilege requirement, and install directory semantics. Nothing essential for correctly calling 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 description coverage is 0%, but the description thoroughly documents the only parameter: 'Where to install FPC. Defaults to C:\FPC\3.2.2. Avoid paths with spaces.' This meaningfully adds guidance beyond the schema's bare property name and default, including a practical constraint.

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

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

The first sentence states a specific verb and resource: 'Download and install Free Pascal Compiler (FPC).' This clearly identifies the tool's function and distinguishes it from sibling tools like compile_pascal and run_pascal, which operate on source code rather than installing the compiler.

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 the tool: 'Only use this when no Pascal compiler is available on the system.' It provides a clear condition for invocation but does not name alternative tools or explain what to do when a compiler already exists, so it stops short of a full when/when-not/alternatives treatment.

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

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

There are no annotations, so the description must carry the burden of behavioral disclosure. It reveals that this is a boot operation via simctl, but it does not disclose side effects, whether it fails on already-booted simulators, whether it requires network access to a remote host, or what the output indicates.

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 states the core action and targeting mechanism immediately evoke the underlying command, giving the agent maximum signal in minimal space.

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?

Although an output schema may exist, the description is insufficient for a tool with 4 parameters and several closely related siblings. It omits the meaning of host/user/key_path, the conditions under which booting is appropriate, and how this differs from sim_launch, leaving the agent to guess or inspect sibling schemas.

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

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

The schema has 0% description coverageings and 4 parameters, yet the description only clarifies the meaning of 'udid' by saying the boot is 'by UDID'. The required 'host' and 'user' parameters, and optional 'key_path', are not explained at all, leaving important remote-execution semantics ambiguous.

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

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

The description clearly states the action ('Boot'), the target resource ('a simulator'), and the selection criterion ('by UDID'). It also names the underlying command ('xcrun simctl boot'), which unambiguously identifies the tool and distinguishes it from sibling tools like sim_launch or sim_shutdown.

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 tells the agent what the tool does but gives no guidance on when to choose it over alternatives such as sim_launch or sim_shutdown. It does not mention prerequisites like whether the simulator must be installed or whether it should already be shut down before booting.

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 adds genuinely useful behavioral context — that app_path is a Mac-side path and where the .app actually lives after a build — which goes beyond the schema. However, it omits what happens on failure, whether installation is reversible, and what the response contains. For an un-annotated mutation tool, this is partial but not complete 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?

Two short, front-loaded sentences: the core purpose leads, and the path-composition guidance follows as a practical note. Every sentence earns its place; there is minimal waste, though the second sentence could arguably be folded more tightly.

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?

Has an output schema, so return values need not be described. For a 5-parameter tool with 0% schema coverage and no annotations, the description covers purpose and the critical app_path, but leaves host, user, udid, and key_path semantically unexplained. An agent would need to infer their roles from titles alone, which is a meaningful 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 0%, so the description must compensate, and it does only for app_path (explaining its Mac-side origin and how to compose it). The remaining parameters — host, user, udid, key_path — receive no explanation beyond their titles, so the description only partially offsets the coverage gap.

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

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

States a specific verb-resource pair ('Install a .app bundle on a simulator') and names the underlying command (xcrun simctl install), which distinguishes it cleanly from the sibling sim_uninstall, sim_launch, and sim_terminate tools. The purpose is unambiguous even without opening the schema.

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

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

Provides concrete contextual guidance: the tool is meant to be used after a build_dproj for iOSSimARM64 with deploy chained, and tells the agent exactly how to compose app_path (paserver_scratch_dir + project name). It does not state exclusions or when to prefer an alternative, but the usage context is clear and actionable.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not mention what happens if the app is not installed, if the simulator is not booted, or any side effects. It also doesn't mention the default udid='booted' or error behavior. For a mutating tool, this is a significant gap.

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

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

The description is a single sentence and efficient in wording, but it is under-specified. It does not front-load critical usage constraints or parameter context. While concise, it sacrifices necessary information for brevity.

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

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

The tool has 5 parameters (3 required) and no schema descriptions, yet the description provides no context on host, user, key_path, or the return value. It is minimally sufficient to understand the tool's core action but woefully incomplete for correct invocation, especially given the absence of annotations.

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

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

Schema description coverage is 0% and the description only references 'bundle identifier' without explaining the other four parameters (host, user, udid, key_path). The description fails to compensate for the missing schema descriptions, leaving the agent to guess the meaning of required parameters like host and user.

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

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

The description clearly states the action (launch) and the resource (installed app) with the specific identifier (bundle identifier), and mentions the underlying command for context. It distinguishes from obvious siblings like sim_install and sim_terminate, though it doesn't explicitly name any alternative. This is clear but not as strong as explicitly differentiating from similar launch tools.

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

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

No guidance on when to use this tool versus alternatives, prerequisites (e.g., app must be installed, simulator booted), or conditions where another tool like sim_open_url would be appropriate. The description only states what it does, not when to choose it.

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