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

Annotations already declare readOnly=false, destructive=false and idempotent=true, so the safety profile is covered. The description adds real value beyond that by bounding the blast radius: only the owned FFmpeg verification child is affected, exports and media survive. It stops short of saying what the job's resulting status is or what happens if no verification is running.

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

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

Two short sentences, no filler. The affirmative scope comes first and the exclusions second, which is the right order for an agent that has already chosen this 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?

No output schema exists, so the description would need to convey the post-cancellation outcome, and it doesn't — an agent cannot tell whether the call returns a status, throws when nothing is running, or leaves the job in a terminal state. For a one-parameter mutation with annotation coverage the bar is lower, but the gap on job_id meaning and result state keeps this at minimum-viable.

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

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

There is one required parameter (job_id) with 0% schema description coverage, so the description must carry the semantics. It says 'this session's' which hints at scoping but never clarifies that job_id is the verification job identifier rather than an export or window id — a meaningful ambiguity given the uuid format 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?

States a specific verb (cancel) and a precisely scoped resource (this session's owned FFmpeg verification child only), and immediately names what it does not touch (Studio exports, media). The phrase 'verification child' is slightly jargon-dependent, but combined with the title 'Cancel full decode' an agent can distinguish it from studio_verify_export and studio_export_checkpoint.

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 negative scoping ('does not cancel Studio exports or delete media') implicitly tells the agent this is not the tool for stopping exports, which is useful routing. However, it never states the positive trigger condition — e.g. when a verification is running and you want to abort it — nor points to a sibling for the excluded cases, so the agent must infer usage from 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?

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is fully covered structurally. The description adds that a fuller mode exposes sources, eligibility and live evidence, plus a caveat that UI access alone is not a completed workflow — useful but thin behavioral context.

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

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

Three short sentences, no filler, and the core purpose statement is front-loaded before the parameter hint and caveat. The final caveat sentence is slightly aphoristic but earns its place as a usage warning.

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

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

With no output schema, the description bears responsibility for describing returns; it names categories (coverage, restrictions, sources, eligibility, live evidence) but gives no sense of shape or size. For a zero-required-parameter read-only tool this is adequate but not fully self-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 carry full burden. It explains what detail=full unlocks, but leaves `family` undefined — no hint about what values are valid or what a family represents, and `detail=summary` (the default) is never contrasted beyond implication.

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?

"Task coverage summary and restrictions" names a resource but the domain jargon ("task coverage") leaves the actual output ambiguous — is it a list of supported tasks, a coverage percentage, or a feature matrix? It is distinguishable from the action-oriented siblings (studio_click, studio_launch) as an informational tool, but the verb is 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?

"Request family or detail=full for sources/eligibility/live evidence" gives a concrete condition for escalating detail, which is real usage guidance. However, it never says when to call this tool at all versus studio_status or studio_verification_status, nor does it state 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 destructiveHint=true and idempotentHint=false; the description adds the operational consequences: it consumes a single-use token and returns the after-state. 'Never guess or retry blindly' reinforces the non-idempotent/destructive nature without contradicting the hints. It leaves out error or failure behavior, which keeps it from 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?

Four tight sentences with the targeting rule front-loaded and the safety warning last. Telegraphic phrasing like 'Consumes token; returns after-state' is efficient rather than padding, though it reads slightly compressed.

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, non-idempotent click with no output schema, the description covers targeting, token lifecycle, the pixel-bounds trap, and that the after-state is returned. Missing only failure or stale-element recovery guidance, a minor gap given the annotations already flag destructiveness.

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

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

Schema description coverage is only 29%, so the description carries the burden; it clarifies the element_id-versus-x/y exclusivity, the physical-pixel source for tree bounds, and that observation_token is single-use and consumed. It says nothing about button, modifiers, or count, all of which are documented only by the schema's enum/default values.

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

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

The description names a concrete verb plus both targeting modes, element_id and image x/y, so the agent can tell which address form to use. It does not distinguish itself from siblings such as studio_hover or studio_drag, which is the only reason 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?

'Click one current UI element_id OR visible returned-image x/y point' sets the eligibility condition for each mode, and 'never pass tree bounds as x/y' plus 'never guess or retry blindly' give explicit do-not rules. No sibling alternative is named, so an agent that meant to hover or drag gets no redirect.

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, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds useful operational context by saying it consumes a token and that the agent should inspect resulting edits, but it does not describe token invalidation, irreversibility, or the response 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 two tightly packed sentences with no filler, and the core drag modes are front-loaded before the token/inspection caveat. Every phrase contributes to selecting or invoking 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?

This is a destructive UI automation tool with 9 parameters, low schema description coverage, and no output schema. The description adds some necessary workflow context, but it is still too thin regarding coordinate semantics, token acquisition, mode selection, and how to inspect resulting edits.

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 9 parameters and only 11% schema description coverage, the description must carry more semantic weight. It correctly groups the parameters into endpoint/path modes and optional button/modifiers/duration, but it does not explain coordinate pairing, visibility constraints, the points path limits, or how required/optional combinations work.

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 (Drag) and identifies two execution modes: visible image endpoints or a bounded path, plus optional button/modifiers/duration. This is clear enough to distinguish from siblings like studio_click or studio_hover, though it does not explicitly name those alternatives.

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

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

It implies use for drag gestures and notes that the call consumes a token and that resulting edits should be inspected, which gives some workflow guidance. However, it does not say when to prefer studio_drag over studio_click/studio_hover, nor when to use endpoint dragging versus a bounded path.

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, idempotentHint and destructiveHint=false, so the safety profile is covered; 'no media changes' largely restates that. The useful additions are the workflow link to verify_export and the purpose of rejecting unchanged files, but nothing is said about persistence or whether the checkpoint expires.

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 compact clauses, front-loaded with the action and the timing constraint; nothing is padded. The trailing fragment 'no media changes' is clipped but not harmful.

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

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

For a one-parameter tool with full annotation coverage and no output schema, the description covers purpose and workflow but leaves the sole input undefined and only implies that a checkpoint_id is produced. An agent can guess the call but not the correct value for 'path'.

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

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

The single parameter 'path' has 0% schema description coverage and the description never explains it — no indication of whether it is an output file, a directory, or a studio project path. Worse, the description names 'checkpoint_id', which is not a parameter of this tool at all, so an agent may look for it in the schema and find nothing.

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 concrete verb and resource — 'Record exact output baseline before Export' — which is specific enough to distinguish it from studio_verify_export and studio_import_media. It falls short of 5 because 'baseline' and 'checkpoint' are never defined in terms of what is actually captured.

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 timing guidance ('before Export') and names the downstream consumer, verify_export, so the agent knows the lifecycle pairing. It does not state what happens if a checkpoint already exists or whether the step is optional.

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 the mutation/safety profile (readOnlyHint=false, idempotent=false, destructive=false). The description adds that it consumes a token (partly redundant with the schema's 'single-use observation token') and that it returns an 'after-state', which is useful since there is no output schema. However, it does not explain what the after-state contains, whether hovering may open persistent submenus that require follow-up clicks, or any rate/visibility constraints.

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

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

Two short, front-loaded sentences with no filler. The second sentence ('Consumes token; returns after-state') is efficient but somewhat telegraphic, leaving 'token' and 'after-state' undefined in the description itself.

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

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

Given no output schema and moderate schema coverage, the description is adequate but incomplete: it omits what the after-state is, whether a hover can leave open UI needing a subsequent action (relevant given non-idempotence), and the coordinate frame for x/y. These are things an agent would need to invoke it confidently in a multi-step UI flow.

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

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

Schema description coverage is only 33%: observation_token is documented, but x and y have bare integer constraints. 'Hover a visible image point' adds the useful hint that x/y are coordinates within the visible image, but the description does not elaborate coordinate frame, bounds, or behavior for off-screen/invalid points.

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 (hover) and a specific resource (a visible image point), plus the intended outcome (tooltips/submenus). It is clearly distinguishable from click/drag siblings in practice, though it never names an alternative explicitly.

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

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

'for tooltips/submenus' implies the usage context, but there is no explicit when-to-use versus studio_click/studio_drag guidance, no precondition such as requiring a prior observation, and no when-not-to-use statement.

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 the non-read-only, non-destructive, non-idempotent profile; the description adds genuinely non-obvious facts: it requires the Studio-owned Open dialog to be open, the token is burned on use, retries are therefore unsafe, and originals are not moved. It does not describe failure/timeout behavior, keeping it from 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?

Three short sentences, front-loaded with the action and mechanism, then the token cost, then the verification follow-up. No filler or restatement of the title.

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

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

With no output schema, the description correctly tells the agent that success must be established by inspecting the resulting screen rather than a return value — a useful pointer. But it leaves out prerequisites (which tool produces the token), the format/constraints of 'paths', and any partial-failure semantics for a batch of up to 32 files.

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

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

Schema coverage is 50%: observation_token is self-documented as a single-use token, which the description merely echoes. The 'paths' parameter is undocumented in both places — the description only hints they are local file paths, without saying whether they are absolute, what the 32-item cap means, or how duplicates/invalid paths are handled.

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 concrete verb+resource ('Import existing local media') and the mechanism ('Studio-owned Open dialog'), which is enough to separate it from the export/verification siblings. It does not explicitly name a sibling it must not be confused with, so it stops 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?

'Consumes its token' and 'Inspect the resulting screen to establish import success' imply the workflow (observe first, verify after), but the description never says so outright or names the tools to call (studio_observe, studio_verify_export) or when not to use this. Usage is inferable rather than stated.

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

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

Annotations already establish that this is non-read-only but non-destructive and idempotent; the description reinforces this with 'if closed' and clarifies the scope with 'no project edits'. It does not describe failure behavior or whether the launch call returns immediately, but the wait_ready handoff covers the main sequencing concern.

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

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

Two short sentences, front-loaded with the action and condition. The follow-up guidance and scope exclusion are stated without 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 zero-parameter launch tool with annotations and no output schema, the description gives enough information to call it correctly and tells the agent what to do next. It could mention failure modes or whether the process is launched detached, but those are minor gaps for this simple 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?

There are zero parameters, so there is no parameter documentation burden; the schema also disallows additional properties. A baseline 4 is appropriate because the description adds no parameter semantics beyond the empty schema.

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

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

The description uses a specific verb and resource: starting the pinned Studio installation. It also distinguishes its role from the sibling studio_wait_ready by assigning window-readiness handling to that 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?

It explicitly states when to use it: only if Studio is closed. It also names the follow-up alternative, wait_ready, for waiting on the window and excludes project edits.

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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered. The one added trait is 'verified' — meaning unverified/stale windows are filtered out — which is genuinely beyond the annotations, but it is left undefined and no rate/refresh behavior is mentioned.

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

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

A single sentence with no filler, front-loading the verb and the returned resource. It is tight but verges on under-specified rather than optimally structured.

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

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

With no parameters and no output schema, the description does the necessary work by naming the returned fields (windows/dialogs and IDs) and a filtering guarantee ('verified'). Only the meaning of 'verified' and whether the list is a snapshot versus live remains unexplained.

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 there is nothing for the description to disambiguate and no schema gap to compensate for. Baseline 4 applies.

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

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

Specific verb 'List' plus concrete resource 'Studio windows/dialogs and IDs' tells the agent exactly what it gets back. It stops short of naming the sibling studio_select_window, so the boundary between listing and selecting is only implied by 'for selection'.

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?

'For selection' implies a list-then-select workflow, so usage is inferable, but the description never states when to call this versus studio_select_window, studio_observe, or studio_status, and gives no prerequisites such as Studio being launched.

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

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

Annotations already declare the tool as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds meaningful behavioral context: supported formats (MP3/WAV/LRV), the treatment of missing projection as unknown, and the crucial caveat that metadata does not prove stitching quality or camera-mode eligibility. This goes beyond annotations and is valuable for correct interpretation.

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

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

Two tightly packed sentences front-load the core functionality and follow with critical limitations. Every clause earns its place, with no redundant restatement of the name or annotations.

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

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

For a simple one-parameter read tool with no output schema, the description effectively enumerates the returned data fields and clarifies interpretation limits. It leaves minor gaps around path semantics and error behavior, but the annotations and field enumeration make it largely 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 description coverage is 0% for the single 'path' parameter, so the description must compensate, but it only implies supported file types (MP3/WAV/LRV) without explaining path format, absoluteness, or error handling. It provides minimal semantic 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 uses a specific verb ('Read') and enumerates the exact metadata fields returned (duration, codecs, dimensions, FPS, streams, spherical projection), making the tool's function unambiguous. It does not explicitly differentiate itself from siblings like studio_import_media or studio_verify_export, but the local file inspection focus is clear.

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

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

There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The caveat about metadata not proving stitching quality is a limitation on interpretation, not a usage rule for selecting the 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 mark it read-only and non-destructive, and the description adds non-obvious behavior: persisted preferences, include_text=auto resetting UIA, and separate observation clearing screenshot-typing focus. It does not fully explain return contents, but it meaningfully extends the annotation profile without contradicting it.

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

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

The description is very compact and mostly front-loaded, with defaults clustered and no filler. The telegraphic fragments, especially "Fresh Studio image/token," reduce clarity but do not add wasted text.

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

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

For an observation tool with eight optional parameters and no output schema, the description should define what "token" contains and what is returned. It gives coordinate conventions and defaults but leaves return shape and several controls unclear.

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

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

Schema coverage is 50%, and the description supplies several defaults (JPEG 1600/q85, compact output, native-dialog UIA) plus the include_text=auto reset behavior. It still omits settle_ms, max_elements, and include_screenshot, so it only partially compensates for the remaining schema gaps.

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 "Fresh Studio image/token" only implies that it obtains a fresh screenshot and UI token; it never states a clear verb or that it captures the Studio UI tree. Coordinate-system and default notes help identify it as an observation tool, but the purpose is still vague relative to siblings like studio_status or studio_capabilities.

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 statement of when this should be used instead of studio_status, studio_list_windows, or studio_capabilities, and no prerequisites are given. The only guidance is coordinate handling and the focus-clearing caveat, which is not tool-selection guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so safety is covered. The description adds genuine non-annotation context: it consumes a token, returns after-state, and rejects system/app-switching keys. These are useful behavioral disclosures beyond the structured 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 short, front-loaded sentence fragments with no waste. The key action, side effects, and validation rejection are each stated economically.

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 a token-consuming key tool with 25% schema coverage and no output schema, the description covers token consumption, returns after-state, and key rejection. But 'after-state' is undefined and the repeat/interval parameters go unexplained, so an agent still lacks some detail needed to call it precisely.

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

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

Schema description coverage is only 25% (only observation_token is documented). The description gestures at 'bounded repeats' and 'key/chord' but never explains key format, repeat bounds (1-30), or interval_ms semantics, leaving three of four parameters undocumented in both schema and description.

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

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

States a specific verb (send key/chord) and resource, distinguishing the keyboard action from siblings like studio_type_text or studio_click. The qualifier 'supported' and 'bounded repeats' narrows scope. It doesn't explicitly name a sibling, so not 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?

Usage is implied by 'Send a supported Studio key/chord', and 'System/app-switching keys are rejected' gives a partial constraint. However, there is no explicit when-to-use-vs-alternatives guidance (e.g., vs studio_type_text for text input), leaving routing to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=false, so the state-changing profile is covered structurally. The description adds genuinely useful context beyond that: the single-use observation token is consumed and an after-state is returned, plus direction semantics for positive delta. It does not explain what happens with an expired/stale token, which is the main operational risk.

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 compact clauses, action first, with direction semantics and token cost front-loaded. Dense but readable; nothing is wasted, though the clauses are telegraphic enough to border on under-specification.

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?

Six parameters, low schema coverage, and no output schema mean the description carries a lot of weight. It covers token consumption and after-state but leaves axis semantics, coordinate frame (viewport vs. window-relative), and token freshness failure modes unexplained for a state-changing interaction tool.

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

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

Schema coverage is only 17% (only observation_token documented), so the description must compensate and does so partially: it explains x/y as an optional visible image point, relates delta to down/right movement, and ties modifiers to zoom. The axis parameter (vertical/horizontal default) and the -1200..1200 delta bounds are left entirely to 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?

"Wheel at an optional visible image point" states a concrete verb (scroll/wheel) and target, and the title confirms the Studio surface. It is distinguishable from point-click or key-press siblings, but the description never names an alternative or says what content is scrolled (window vs. pane), which would have made it 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. An agent must infer that this is for scrolling rather than using studio_press_key (PageDown) or studio_drag, and nothing says when zoom-via-modifiers is appropriate.

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 state idempotent, non-destructive, and non-read-only behavior. The description adds important non-obvious context beyond that: selecting invalidates the old token and input should follow an observe step.

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

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

Two short sentences are front-loaded with the core action and then the main caveat. There is no filler or repetition.

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

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

The description covers token invalidation and the observe-before-input workflow, but it leaves window_id acquisition and return/new-token behavior unaddressed. With no output schema and no parameter descriptions, those are material gaps.

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

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

The schema has 0% description coverage for the single parameter, window_id, and the description does not explain its format, source, or whether it comes from studio_list_windows. The phrase 'verified Studio window/dialog' hints at the target but does not document 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 gives a specific verb and resource: 'Select a verified Studio window/dialog.' That is enough to distinguish selection from siblings like studio_list_windows or studio_launch, though it does not explicitly name the alternative tool.

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

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

The phrase 'observe before input' supplies a sequencing prerequisite, but the description does not say when to use this instead of studio_list_windows or studio_launch. Usage context is implied rather than fully specified.

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

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

Goes beyond the annotations by disclosing that the observation token is consumed (single-use) and that the value readback is verified afterwards, plus the Qt fallback limitation. These are non-obvious operational traits. It stops short of saying whether a failed readback errors out or leaves partial state, which matters for a destructiveHint=true tool.

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

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

Three short sentences, zero padding, with the core action front-loaded. Each sentence carries distinct information: action, token/verification behavior, and limitation/fallback.

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, non-idempotent mutation with no output schema, the description omits failure semantics (what happens if the control rejects the value or readback mismatches) and permission/prerequisite requirements. An agent knows how to call it but not how to interpret or recover from a bad outcome.

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 67%, with element_id and observation_token both described in the schema. The description adds only implicit semantics via 'Consumes token' and 'current UIA tree' (freshness requirement). The value parameter — including the 16000-char limit and whether it must match control type formats — is not elaborated on.

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: 'Set an editable control from the current UIA tree.' The scope qualifiers ('editable control', 'current UIA tree') distinguish it from studio_type_text and studio_click, though it never names those siblings explicitly.

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

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

'Unsupported Qt controls require screenshot typing' implies an alternative path but does not name the sibling tool (studio_type_text) or state the condition for choosing it. There is no explicit when-not guidance, e.g. that a fresh observation is required or that stale tokens fail.

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, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real behavioral value by promising no side effect on Studio's lifecycle ("Does not start Studio") and by naming the four state categories returned, which the annotations do not 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?

Two short sentences, the positive capability stated first and the exclusion second, with no filler. Every clause carries information an agent can act on.

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-arg, fully annotated read tool with no output schema, the description is nearly sufficient: it lists what state is inspected and rules out a side effect. It is slightly thin on return semantics — terms like "backend" and "token readiness" are not unpacked, and it doesn't say whether a missing Studio install yields an error or a status flag.

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 and the schema is fully described, so there is nothing for the description to disambiguate. Baseline of 4 applies; the description correctly does not waste words on arguments.

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

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

Specific verb ("Read") plus an enumerated set of resources: installation/backend state, Studio windows, selection, and token readiness. The negative clause "Does not start Studio" separates it from studio_launch, but the boundary against studio_list_windows and studio_verification_status is left implicit even though those siblings overlap with the reported content.

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 only explicit guidance is the exclusion "Does not start Studio", which usefully routes launch intent elsewhere. There is no positive statement of when to call this (e.g. before acting, to preflight readiness) and no mention of studio_capabilities or studio_verification_status as alternatives for narrower queries.

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 annotations already declaring destructive=true and readOnly=false, the description adds useful context about mode prerequisites, explicit replace semantics, and the need to inspect the result. 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 definition is compact and front-loads the core action. Later sentences are dense but each carries relevant usage or safety 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 destructive, state-changing UI tool with no output schema, the description covers the key mode requirements and advises inspecting the result. It is mostly complete, though failure behavior and undo/state effects are not described.

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

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

Schema description coverage is only 25%, so the description must compensate, and it does add meaning for text, replace, focus_mode, and observation_token. It names both modes and explains replace explicitly, though it omits details such as the text length limit.

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: "Type literal text in a focused field." It is clear what the tool does but does not explicitly distinguish it from sibling tools such as studio_set_value or studio_press_key.

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

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

It gives clear operational preconditions: accessibility mode requires editable UIA, and screenshot mode requires a preceding click plus inspected caret/focus and token. It also clarifies that replacement is explicit and the typed result should be inspected, but it does not name alternative 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 readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuine value beyond that by explaining the status semantics: which terminal state counts as success and which states warrant error inspection. It stops short of describing polling behavior or how long results persist.

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

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

Two short sentences with the core action front-loaded and no filler. The second sentence is compressed to the edge of ambiguity ('inspect failed/cancelled errors') but still earns its place.

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

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

No output schema exists, so the description must carry the return-value burden; it describes the meaning of completed/ok, failed, and cancelled states but not the shape of the response or which fields carry error details. The job_id parameter is also left unexplained, leaving a modest gap for a status tool.

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

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

There is one required parameter (job_id) with 0% schema description coverage, and the description never mentions it or its expected form. With the schema providing no documentation, the description should have compensated but 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?

States a specific verb+resource: reading full-decode progress/result, which is distinct from generic studio_status and studio_export_checkpoint. However, it never names the sibling tools it could be confused with, so differentiation is implicit rather than explicit.

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 a clear interpretive rule (only completed+ok means success; inspect failed/cancelled errors), which implies when to call it. But it never says when to prefer this over studio_status, studio_verify_export, or studio_cancel_verification, nor whether it should be polled or called once.

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

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

The description adds substantial behavior beyond the read-only, idempotent annotations: full verification is asynchronous via job_id, quick decoding takes about one second, spherical checks require metadata, and validity/change does not prove edits or Studio authorship. It does not cover failure behavior or permissions, but the annotations already carry the safety profile.

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

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

The description is compact and front-loaded, with each sentence contributing a distinct constraint: stable output checks, spherical metadata requirements, quick/full behavior, and the authorship caveat. No sentence is filler, though the telegraphic style trades some clarity for brevity.

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

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

For a complex 15-parameter verification tool with no output schema and no schema descriptions, the description is too sparse. It explains high-level mode and async behavior but omits most parameter semantics, expected outputs, and what the optional baseline/settings checks actually do.

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 15 parameters and 0% schema description coverage, the description must carry most parameter meaning. It only loosely references mode, baseline, settings, and projection, and does not explain min_bytes, timeouts, stable_for_ms, expected dimensions, codec, audio, or duration tolerance.

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 says 'Check stable output' and mentions baseline/settings/projection, spherical metadata, and decodes, which collectively imply media verification. However, it never clearly states that it verifies an exported media file at a path, leaving the core purpose somewhat vague despite helpful surrounding clues.

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 distinguishes quick mode as a one-second decode from full mode returning a job_id, and says to poll status for completion, which gives useful usage context. It still lacks explicit guidance on when to choose this tool versus siblings like studio_verification_status or studio_media_info, and does not say when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the 10-second ceiling and a token-invalidation side effect, but "Invalidates token" is never explained and sits in uneasy tension with readOnlyHint — an agent cannot tell what token, what breaks after it is invalidated, or whether prior observations must be redone.

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?

Only two short sentences, with the duration limit front-loaded. Nothing is padded, but the density is achieved by eliding meaning rather than by precision — the second sentence packs two unexplained concepts into seven 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?

A single-parameter, no-output-schema tool should be fully describable, yet an agent still lacks the default value, the token semantics, and any differentiation from `studio_wait_ready`. The description is too thin for the ambiguity its own jargon introduces.

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 `milliseconds` parameter, so the description must carry the load. It conveys the upper bound (ten seconds) implicitly but never names the parameter, never states the 1000 ms default, and never explains what a value of 0 or a mid-range value does.

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 verb and effect ("Wait up to ten seconds") are concrete, but the two qualifiers ("without replaying input", "invalidates token") are jargon that an agent cannot resolve without inside knowledge. Nothing distinguishes it from the near-identically named sibling `studio_wait_ready`, so an agent cannot tell the two waits apart from the text alone.

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?

"Observe before input" is the only sequencing hint, and it is oblique — it implies a wait should be followed by an observation, but never states the condition for calling this tool. There is no guidance on when to prefer it over `studio_wait_ready` or `studio_status`, and no 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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value with the caveat that window readiness does not prove media processing/export completion, but it omits what happens on timeout (default 10000ms cap) and that only the first match is returned.

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

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

Two short sentences, front-loaded with the core action and followed by the most important caveat. No filler, though the second sentence could be tightened further.

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?

Eleven optional parameters, low schema coverage, and no output schema, yet the description never describes what the observation returns (screenshot, element list, text) or how the selection/settle/timeout parameters interact. An agent must read the whole schema to call this safely.

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

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

With 11 parameters and only 36% schema description coverage, the description should compensate but barely does. The phrase 'saved capture preferences' hints at the persistence behavior of output_detail/image_format, yet kind, settle_ms, timeout_ms, max_elements, title_contains and include_screenshot get no explanation in either place.

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 (wait for a matching Studio window) plus an immediate follow-on action (observe with saved capture preferences). It is differentiable from siblings like studio_list_windows and studio_status, though the overlap with studio_observe is only implicitly resolved.

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: call this before acting on a window, and it distinguishes itself from studio_wait by requiring a matching Studio window. However, it never says when NOT to use it, nor does it point to alternatives such as studio_list_windows for discovery or studio_verify_export for completion checks.

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