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

Annotations already flag destructive=true and readOnly=false, and the description goes beyond them: it discloses that the dump runs as a background job, that results are verified via cryptid=0/UUID/SHA-256, and that binary_path is the handoff artifact for objc_dump/ida_open_binary. Missing is any sense of cost/duration, failure modes, or permission requirements for a destructive long-running 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?

One dense paragraph, front-loaded with the core action and defaults before the caveats and handoff target. Every clause carries information, though the compressed hyphenated jargon (cryptid=0, frida-ios-dump, bounded loaded candidates) makes it heavier to parse than necessary.

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, yet the description still names the key return fields, which is helpful rather than redundant. For a destructive, background, session-dependent tool it covers prerequisites, scope, and next steps well; only timing/expectations around the background job and the undocumented pagination params are absent.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does explain the non-obvious ones: module_name/module_path select a framework, action=modules lists instead of dumping, and background is the default. It says nothing about device_id, bundle_id, limit, or offset, leaving half the surface undocumented in both places.

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

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

States a specific verb and resource — decrypt one loaded app Mach-O — plus the implementation basis (maintained frida-ios-dump code over an existing Frida/SSH session) and defaults (main executable, background job). It also names the downstream consumers (objc_dump, ida_open_binary) and the sibling-style action=modules mode, so it is clearly separable from its neighbors.

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 operating context: the app must already be loaded, an existing Frida/SSH session is required, module_name/path switches to a framework, and action=modules is the non-dumping listing path. It also carves out explicit negative scope (no IPA packaging, no forced framework loading). What it lacks is an explicit statement of when to prefer this over direct objc_dump/ida_open_binary entry points.

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?

Adds real behavioral context beyond the annotations: 'Stop removes hooks' explains the destructiveHint=true side effect, and 'an active log stream keeps the session alive' discloses a session-lifetime constraint the annotations do not. It also clarifies the format-string vs rendered-text distinction between os_log/NSLog and NSLogv/stdio. No contradiction with readOnlyHint=false or destructiveHint=true.

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?

Telegraphic and front-loaded: the core read path (action + after + limit) appears in the first sentence, and action-specific notes follow. Dense but nearly every clause carries information; only the 'filtered page' phrasing is too compressed to be actionable.

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 presence of an output schema relieves it of explaining return values, and it covers the lifecycle and stream-format traits well. However, for an 11-parameter tool with 0% schema descriptions, key filtering parameters (`level`, `contains`) and `max_message_length` are never explained, leaving real gaps.

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

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

Schema coverage is 0% across 11 parameters, so the description must compensate. It clarifies `after` (next_cursor), `limit` (default 20), `sources`/`capacity` (start-time only), and `wait_ms` implicitly ('no waiting'), but leaves `level`, `contains`, and `max_message_length` entirely undocumented and only vaguely gestures at filtering ('filtered page').

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

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

States a specific verb and resource: start/reuse log hooks and read one filtered page from a bounded on-device ring. The scope (on-device ring buffer, one page) is precise enough that no sibling could be confused with it. Slightly obscured by jargon ('ring', 'hooks') that an agent must infer from context.

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 concrete operational guidance: 'Pass after=next_cursor; default 20 entries, no waiting' and 'Sources/buffer options apply when starting.' Action semantics (start vs read vs stop) are sketched out, though there is no explicit when-to-use-this-over-X routing, which is acceptable since no sibling offers logging.

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?

Goes well beyond the readOnly/non-destructive annotations by disclosing that the lldb backend stops the process and resumes it, that frida only samples running threads, and that no arbitrary debugger commands or expression evaluation are permitted. These are exactly the operational side effects an agent needs before invoking.

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

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

Four dense sentences with no filler, front-loaded with the core purpose and backed up by the key behavioral caveats. Efficient, though the backend/mode explanation could be structured slightly more crisply.

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

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

An output schema exists, so return values need no explanation, and the description covers the critical backend selection and safety caveats. With 11 parameters and 0% schema coverage, some per-parameter detail is still missing, but the essentials for correct invocation are present.

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 while the description adds meaning for the two most important parameters (mode and backend), it says nothing about thread_id, max_frames, frame_index, max_threads, max_variables, or register_names. The added semantics are valuable but only partially compensate for the undocumented 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?

States a specific verb and resources ('Inspect app threads, bounded backtraces or registers in one call') and ties them to the mode enum, so an agent immediately understands the tool's scope. It is clearly distinct from siblings like device_list or frida_trace_method.

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

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

Explicitly contrasts backend=frida ('immediate and samples running threads') with backend=lldb ('temporarily stops the process, supports locals, then detaches/resumes') and explains mode=capabilities for probing debugserver availability. This gives strong selection guidance for the two backends, though it doesn't name siblings to prefer over this tool.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description adds useful context: install pulls from a matching Xcode image or workspace path, repair reapplies an existing signing profile, and installation only checks execution rather than verifying attach. It does not detail permissions or destructive side effects, but it adds meaningful behavioral context beyond the annotations.

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

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

Three dense sentences with the core purpose front-loaded, followed by action-specific behavior and a useful verification caveat. No sentence is wasted.

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

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

The output schema exists, so return values need not be described, and annotations cover the mutation risk. The description covers setup, install, repair, and attach-verification boundaries, though it could say more about how device_id and bundle_id are used.

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 carry parameter meaning. It explains the action modes (check/install/repair) and the local_debugserver_path source, but it does not explain device_id or bundle_id semantics beyond their required status.

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: check required Frida/LLDB/debugserver components and return missing-component instructions. It also clarifies the install and repair modes, and explicitly separates attach verification from this setup tool by naming debug_inspect(backend=lldb).

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

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

It clearly explains when to use action=install and action=repair, and it routes attach verification to debug_inspect. It does not explicitly state when-not to use the tool, but the setup/check 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?

Annotations already establish read-only, non-destructive, closed-world behavior. The description adds useful behavioral context: results are TTL-cached, SSH discovery is used, and force_refresh requests fresh architecture/iOS/jailbreak evidence. It stops short of covering auth requirements, latency, or 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?

One front-loaded sentence with no wasted text, efficiently conveying the cached-discovery purpose and the force_refresh option.

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

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

The output schema covers return values and annotations cover safety, reducing the description's burden. However, the required device_id parameter is not explained and there is no routing guidance against sibling tools such as device_list, leaving meaningful gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It explains force_refresh reasonably well but provides no meaning for the required device_id parameter, leaving half the parameters undocumented beyond the schema's structural 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?

States a specific verb and resource: get TTL-cached SSH discovery for this connection, returning architecture, iOS, and jailbreak evidence. This is clear, though it does not explicitly distinguish itself from sibling tools such as device_list.

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?

Explains the force_refresh behavior, indicating when to request fresh evidence instead of cached data. It does not say when to use this tool versus device_list or other debugging/discovery siblings, nor does it state any exclusions.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only one piece of context — that results are restricted to allowlisted/configured devices — and says nothing about ordering or where that configuration lives.

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

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

A single front-loaded sentence with no filler. Nothing could be trimmed without losing meaning.

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

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

For a simple read-only list tool with an output schema and full annotations, the description is close to sufficient. However, it doesn't clarify whether the allowlist comes from server configuration or the target device, which affects how an agent interprets an empty result.

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

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

The tool takes zero parameters (empty object schema), so there is nothing for the description to disambiguate; baseline applies. The description correctly implies a no-argument call.

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

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

States a specific verb (list) and resource (allowlisted device IDs and applications), so the operation is unambiguous. It doesn't distinguish itself from the sibling device_info, which presumably returns details for a single device, so it falls short of 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?

Usage is only implied: an agent can infer this is the discovery call to find valid device IDs before calling device_info, but the description never says that or names any alternative. No when-to-use or exclusion is stated.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds what is actually destroyed (the injected agent and installed hooks), which is useful. It omits post-conditions such as the session becoming invalid or events stopping, which matter for a destructive teardown.

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

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

One short sentence, front-loaded with the action and its effect. No filler. It is arguably too terse for a destructive tool, but nothing is wasted.

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

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

An output schema exists, so return values need no explanation. However, a destructive teardown with two undocumented required parameters leaves gaps around session identification and post-detach state.

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% for two required parameters (device_id, session_id), and the description says nothing about them. With low coverage, the description should compensate by explaining what identifies the session; it does not.

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

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

Specific verbs and resources: 'Unload the inspection agent and hooks, then detach.' An agent can tell this tears down a Frida session. It doesn't explicitly distinguish itself from the close sibling frida_unhook, which also removes hooks, so the boundary is left to inference.

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

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

No statement of when to call this versus frida_unhook or how to handle an active session. 'Then detach' weakly implies end-of-session teardown, but no preconditions, ordering, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: results are redacted, retrieval is bounded, and a loss count is reported, which tells the agent that data may be sampled or dropped. It stops short of explaining cursor semantics (whether 'after' is inclusive), event ordering, or retention, which matter when paging.

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

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

A single sentence with no wasted words, front-loading the verb and resource plus key traits. It is efficient, though the brevity contributes to the parameter and usage gaps noted elsewhere rather than being purely a strength.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. However, for a five-parameter tool with zero schema descriptions and two required scoping parameters, the description leaves out which parameters scope the call, how to filter by hook, and paging behavior, so an agent could easily call it incorrectly.

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% across five parameters, so the description must carry the load, and it mostly doesn't. Only 'sequence cursor' (after) and 'bounded' (limit) are implied; the required device_id and session_id scoping, the optional hook_id filter, and the limit maximum of 500 are never mentioned.

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 ('Read') and resource ('trace events') plus distinguishing traits: bounded, redacted, cursor-based, and carrying a loss count. No sibling tool retrieves trace events, so no explicit differentiation is needed, but it is clear enough to select 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 phrase 'by sequence cursor' hints at incremental polling, but there is no explicit guidance on when to call this versus other frida tools, no advice on paging until the loss count or empty result, and no mention of prerequisites like needing an active session from frida_trace_method.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds that tracing is bounded and capture is optional, but it omits operational details such as hook installation side effects, required cleanup via frida_unhook, or performance impact.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately concise, though somewhat terse given the tool's nine parameters and destructive behavior.

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

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

For a destructive tracing tool with nine parameters and no schema descriptions, the definition omits prerequisites, workflow context, and parameter meanings. The presence of an output schema reduces the need to explain return values, but the overall context is still inadequate.

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

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

Schema description coverage is 0%, so the description must compensate but only loosely maps to capture_arguments, capture_return, and backtrace. It leaves required identifiers (device_id, session_id, class_name, selector) and settings like max_events and class_method unexplained.

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 ('Register') and resource ('call tracing'), making the core operation identifiable. However, it does not explicitly say it hooks a class method/selector, nor does it distinguish itself from siblings like frida_get_events or frida_unhook.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites such as an existing session or device, and no indication of how it relates to frida_get_events or frida_unhook.

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds the scoping detail that the removal targets one interceptor in the current process session, but says nothing about side effects (does the original method behavior resume?) or 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?

A single front-loaded sentence with no filler. It is efficient, though the brevity contributes to the missing guidance elsewhere.

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

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

An output schema exists so return values need no explanation, but for a destructive three-parameter tool with zero schema descriptions and no sibling differentiation, the description leaves too much for the agent to infer.

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% for all three required parameters. The description only indirectly gestures at hook_id ('a specific interceptor') and session_id ('this process session'), and says nothing about device_id or the ID formats/constraints encoded in the schema.

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

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

States a specific verb and resource: 'Remove a specific interceptor from this process session.' That is clearly distinct from read-style siblings like frida_get_events, though it does not explicitly contrast with frida_detach, which plausibly tears down hooks/sessions too.

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 versus frida_detach or frida_trace_method, no preconditions, and no note about erroring on an invalid or already-removed hook_id. The agent must infer selection from the name alone.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description contributes 'clean up its active operation', hinting at side effects beyond cancellation, but never says what is destroyed, whether the call is idempotent, or what happens to in-flight work. With annotations carrying the risk signal, this is adequate but thin.

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

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

One front-loaded sentence with no filler. Nothing wasted, though the brevity comes partly from under-specification rather than economy.

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 shape needn't be explained. However, for a destructive single-target mutation with zero annotation-independent detail, the description leaves out the practical consequences of the cleanup and the state the job must be in.

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% for the single parameter, and the description never mentions job_id or its expected source. The schema's pattern and length constraints do the documentation work; the description adds nothing about the identifier, but only one param exists so the burden is small.

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 ('Cancel a job') and adds scope via 'clean up its active operation', which meaningfully separates it from the read-only sibling job_status. It does not explicitly name sibling 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?

No guidance on when to cancel versus checking job_status first, no preconditions, and no note on what happens if the job is already complete or already cancelled. The agent must infer the workflow entirely.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. However, the critical behavioral question for a long-running job tool — whether the call blocks until completion, errors while pending, or returns partial state, and how long results are retained — is entirely unaddressed, and the annotations cannot cover that.

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

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

One short, front-loaded sentence with zero waste. It is arguably under-specified rather than bloated, but structurally it is efficient.

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

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

An output schema exists, so return values needn't be described, but the job lifecycle semantics (polling, blocking, expiration, error states) are missing for a tool whose whole purpose is asynchronous job retrieval. Given the presence of job_cancel as a sibling, the absence of any lifecycle framing leaves the definition incomplete.

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

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

With a single self-explanatory parameter (job_id) whose format is enforced by a regex pattern and length bounds, the schema carries most of the load. The description adds nothing about the origin of the ID or whether it must come from a prior submission call, so it neither compensates for the 0% schema description coverage nor harms it.

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

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

The description gives a specific verb and resource ("Retrieve a ... job result"), but it does not distinguish this tool from the sibling job_cancel, nor does it reconcile its name (job_status implies checking progress) with the stated behavior of returning a result. An agent can guess the intent but must open the schema to confirm whether this polls status or fetches final 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?

There is no guidance on when to call this versus job_cancel, or whether it should be polled repeatedly until completion. Nothing states where a valid job_id originates or what happens if the job is still running.

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?

Annotations already declare a safe read-only, closed-world operation, and the description adds real value on top: it discloses that a local header file is returned, that the runtime backend reuses its existing session, that preview is opt-in and bounded, and it publishes concrete static-cache limits (5 minutes, 4 files, 16 MiB). It omits any notion of failure modes or what happens when both parameter sets are supplied.

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

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

Three dense sentences, zero filler, front-loaded with the core action and backend routing before the secondary facts about return value, preview bounds, and cache limits. Nothing repeats the annotations.

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

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

For a 9-parameter tool with an output schema and safety annotations, the description covers the decisive behavioral facts: backend routing, session reuse, preview bounding, and cache constraints. The gap is coverage of arch, limit, and class_filter, which leaves an agent guessing on three of nine inputs.

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 carry parameter meaning and it only partly does: it explains binary_path, device_id, bundle_id, class_name, and backend selection, plus the opt-in nature of preview_chars. Three parameters (arch, limit, class_filter) receive no mention at all and are undocumented anywhere else.

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

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

States a specific verb and resource ("Dump headers") and immediately disambiguates its two operating modes: local binary_path via classdumpc, and live runtime via device_id/bundle_id/class_name. An agent can distinguish it from objc_query_instances purely from this 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?

Gives explicit condition-based routing (which parameter set selects which backend) and names the sibling to use for live values instead. It stops short of stating when the tool is inappropriate (e.g., non-ObjC targets, ambiguous parameter combinations), so it is clear 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?

Annotations already declare a safe read, yet the description still adds substantial behavior: sensitive fields are redacted, snapshot_id pages never rescan the heap, Foundation strings/numbers/collections are bounded while other objects return leased references, and only ObjC-visible classes are reachable. That is exactly the extra context annotations cannot convey.

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 action is front-loaded and nearly every clause carries payload (redaction, defaults, paging, bounding). It is compressed to the point of being telegraphic — 'reuse/attach' and the run-on first sentence require re-reading — but there is little dead weight.

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

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

For a 14-parameter tool with strong annotations and an output schema (so return values need no explanation), the description covers the important behavioral contours: redaction, bounding, snapshot paging, and per-call caps. The remaining gap is the discovery-vs-object_ids mode switch and the subclass/depth knobs, which an agent would have to guess at.

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% across 14 parameters, so the description must compensate and it only partly does: it explains field_names token trade-offs, snapshot_id paging, and the defaults behind max_fields (8 ivars), max_instances (20), and limit (10 per page). It leaves include_subclasses, max_depth, max_items, max_string_length, offset, and the object_ids/class_name mode interaction unexplained.

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

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

The description names a specific resource (allowlisted app ObjC instances) and the concrete actions: discover class instances, read mixed-class object_ids, then read bounded ivars. It distinguishes itself from getter/description-based approaches, though it never names a sibling tool such as objc_dump or debug_inspect, so an agent must infer the boundary itself.

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

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

Usage is implied rather than stated: the 'discover class instances or read mixed-class object_ids' phrasing hints at two entry modes, and 'select field_names to minimize tokens' is practical guidance. But there is no explicit when-to-use-this-vs-objc_dump/debug_inspect rule and no exclusion conditions, leaving the agent to infer 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?

The annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable action-level behavior: schema only retrieves an input schema, while call validates and executes arguments, and existing operation checks apply. It still leaves the nature of destructive side effects vague, but it does not contradict the annotations.

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

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

The description is compact and front-loaded, covering the core mechanism, action modes, name examples, and skill pointer in four sentences. The primitive-name list is useful but slightly catalog-like.

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?

It covers the essential dispatch workflow and references an external skill for workflows, and an output schema exists so return values need not be described. Still, for a destructive open-ended gateway with many primitives, it lacks routing guidance versus direct siblings and fuller argument-shape guidance.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the action values and gives examples for name, but it does not fully describe how arguments must match the schema returned by action=schema or what constraints apply to the open-ended arguments object.

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 mechanism: invoking advanced Vesper primitives by name, with action=schema and action=call modes. It gives concrete primitive-name examples, but it does not explicitly distinguish this dispatcher from direct sibling tools such as objc_query_instances or ui_snapshot.

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

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

It implies this tool is for advanced primitives not loaded in the full catalog and points to the vesper-ios skill for workflows. However, it gives no explicit when-to-use / when-not-to-use guidance versus the many direct sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — it operates without a device connection — but says nothing about server-connection prerequisites, failure modes, or whether the data is live versus cached.

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

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

A single front-loaded sentence with no wasted clauses. The one weak spot is that 'process-session lifecycle' is abstract phrasing that costs words without adding much precision.

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 zero parameters and an output schema present, the description does not need to explain return values, and annotations cover safety. However, it does not state whether a server/agent connection is required for the call to succeed, which is the main operational question an agent has before invoking it.

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

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

The tool takes zero parameters, so the 4 baseline applies; there is nothing for the description to disambiguate. It includes no stray parameter claims, which is correct.

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 (Inspect) and two resources (server configuration, process-session lifecycle), and the clause 'without touching a device' implicitly distinguishes it from the device_*, frida_*, and ui_* siblings that require an attached target. The phrase 'process-session lifecycle' is somewhat jargon-heavy, but an agent can still tell it is a server-side introspection tool rather than a device tool.

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

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

Usage is only implied: 'without touching a device' suggests it is the right call when no device/session is attached, but no sibling is named and no explicit when-not or prerequisite (e.g., whether a server connection must already exist) is given. The agent must infer the selection rule against job_status, device_info, and similar 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?

Annotations already mark this as destructive, non-read-only, and non-open-world. The description adds meaningful behavior beyond them: UIKit control/accessibility actions rather than touch injection, no implicit waits/screenshots/text, after_capture reuse, first-failure stopping, and no automatic retry of mutations. It does not state what state can be destroyed or any auth/precondition requirements, keeping it below a 5.

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

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

The description is compact and front-loaded: it opens with the core batch operation and then layers in mechanism, targeting, and failure semantics. Each sentence adds a constraint or capability, with no filler.

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

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

For a complex 14-parameter automation tool with no schema descriptions, the description covers the main runtime model but not enough of the parameter surface to call it confidently without inspecting the schema. Output schema handles return values and annotations cover safety, but the missing parameter guidance leaves the definition incomplete.

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

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

With 0% schema description coverage across 14 parameters, the description must carry parameter meaning. It explains target selection (leased view_id, identifier/class/text, window x+y) and mentions after_capture, but leaves required device_id/bundle_id, the steps array, and most tuning/capture parameters (depth, limit, fields, format, max_nodes, settle_ms, include_text, root_view_id, visible_only, controls_only) unexplained.

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

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

The description names a specific verb and resource: 'Run an app-scoped batch,' then enumerates the supported steps (tap, back/dismiss, input_text, scroll, assert, wait_for). It also clarifies the mechanism is UIKit control/accessibility actions rather than physical touch injection, though it does not explicitly name sibling tools like ui_snapshot or ui_capture as alternatives.

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

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

It implies the tool is for app-scoped UI action batches and gives operational constraints (stops on first failure, no automatic retry, no implicit wait/screenshots/text, optional after_capture). However, it never states an explicit 'use this when' rule or names when to prefer a sibling tool such as ui_capture for screenshots, so guidance remains implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: automatic session reuse/attach, allowlist restriction, explicit selection requirements for screenshots/text, and snapshot_id paging. It still does not mention permissions or rate limits, so a 4 rather than 5.

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

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

The description is three front-loaded sentences with no filler, and key constraints are stated early. However, it is extremely terse for a 14-parameter tool, which makes the structure feel under-developed rather than maximally efficient.

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

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

The tool is complex: 14 parameters, 0% schema description coverage, and an output schema. The output schema covers return values, but the description only addresses mode, explicit selection, and paging, leaving most input parameters without any explanation. That is not complete enough for reliable 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% across 14 parameters, so the description must compensate heavily. It explains the mode enum, implies include_text selection, and mentions paging via snapshot_id, but leaves most parameters (depth, limit, fields, format, offset, max_nodes, window_id, root_view_id, visible_only, controls_only) undocumented in both description and schema.

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

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

The description states a specific verb ('capture') and resource ('allowlisted app'), and names the three modes, so an agent can tell this is a UI capture tool. It does not explicitly distinguish itself from siblings like ui_snapshot or ui_automate, so it falls short of a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling is mentioned. The statement that mode is required is a parameter constraint, not guidance on choosing this tool over ui_snapshot or ui_automate.

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?

Annotations already declare readOnly, non-destructive, closed-world, so the safety profile is covered. The description adds real value by disclosing that pages are immutable and can be re-read without touching the device — a non-obvious caching semantic — but it omits that visible_only and controls_only default to true and will silently filter the tree, and says nothing about node/page caps or 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?

Three compact sentences, each carrying distinct information — capture semantics, paging semantics, and output shaping — with no filler. It is front-loaded with the core action rather than burying it.

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 needed. But for a 13-parameter tool with 0% schema coverage, the description leaves the default filtering behavior (visible_only/controls_only=true) and the bounding knobs unexplained — an agent could easily misread a filtered snapshot as complete.

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

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

Schema coverage is 0%, so the description carries the burden and does explain the most consequential params: snapshot_id + offset for immutable paging, include_text as opt-in, and format=detail/fields for extra metadata. That leaves eight parameters (depth, limit, max_nodes, visible_only, controls_only, root_view_id, device_id, session_id) with no semantic help beyond their bare titles, so compensation is partial.

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

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

States a specific verb and resource: 'Capture a fresh bounded UIKit summary.' The word 'bounded' and the pagination note distinguish it from a raw dump, though it never names how it differs from sibling ui_capture or ui_automate.

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 one concrete usage pattern (reuse snapshot_id + offset to page without device access) and notes text is opt-in, which implies when to set include_text. But it offers no explicit when-to-use vs. ui_capture/ui_automate guidance and no prerequisites for device_id/session_id.

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