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

No annotations are provided, so the description must disclose side effects and output. It only says 'verify' without stating whether the tool is read-only, what happens on failure, or what response it returns. This leaves significant ambiguity for the agent.

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

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

Two short sentences convey purpose and usage with no filler. The key information is front-loaded.

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

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

The description explains what the tool checks and when to run it, but lacks details about the result/return value, failure behavior, or if any setup actions are performed. Given no output schema, these details would typically be necessary.

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

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

The input schema has no parameters, so there is nothing to document. The description's omission of parameter details is appropriate, and the baseline for zero params is met.

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

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

The description clearly states the tool's function ('Verify the machine is ready to record a demo') and lists specific resources checked (native cursor helper, ffmpeg, Chrome, say voices). This distinguishes it from sibling tools like chrome_launch or start_recording, as it's a pre-flight check.

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

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

The instruction 'Run this first in a new session' provides explicit timing and context for use. While it doesn't mention alternatives, none exist among siblings for this verification task, so the guidance is sufficient.

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 a behavioral detail ('Fade out') beyond the bare action, but with no annotations, it does not disclose what happens if no highlight exists, whether any state is permanently altered, or if any confirmation is required. The fade-out is a nice touch but coverage is minimal.

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

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

The description is a single concise sentence that immediately conveys the operation. Every word is purposeful, and it is front-loaded with the verb and object.

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 no-parameter, no-output tool, the description is sufficient. It doesn't explain edge cases like clearing non-existent highlights, but given the simplicity and absence of a schema, this is a minor gap. It could be slightly more complete by mentioning that it only affects overlays created by chrome_highlight.

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

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

The tool has zero parameters, so the description does not need to explain parameter semantics. Per the rubric, a zero-parameter tool earns a baseline of 4. The description adds no parameter info because there is none to add.

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

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

The description clearly states the action ('Fade out and remove') and the target resource ('highlight overlay'). This distinguishes it from the sibling chrome_highlight tool, which presumably adds a highlight, making the purpose unambiguous.

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

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

Usage context is implied by the tool name and the existence of chrome_highlight, but there is no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or conditions (e.g., whether a highlight must exist).

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

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

With no annotations, the description carries full burden. It discloses the prerequisite (--remote-debugging-port) and the optional tab selection behavior. It does not describe failure modes or side effects, but 'attach' is sufficiently non-destructive and the prerequisite is clearly stated.

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

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

Two sentences, front-loaded with the core action, no wasted words. Every clause adds information relevant to using the tool correctly.

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 tool with two optional parameters and no output schema, the description covers the essential context: what Chrome to attach to and how to optionally select a tab. It could mention what happens on failure or return value, but the prerequisite is clearly stated, making it complete enough for an agent.

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

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

Schema coverage is 100% (both parameters have descriptions in the schema), so the baseline is 3. The description adds 'Optionally pick the tab by URL substring' which reinforces urlContains but does not add new meaning beyond the schema's own description. Port is also unchanged.

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 ('Attach') and identifies the exact resource ('already-running Chrome that has --remote-debugging-port'), clearly distinguishing it from siblings like chrome_launch. It also adds the optional tab-selection capability, making the tool's purpose unambiguous.

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

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

The phrasing 'attach to an already-running Chrome' clearly implies usage when Chrome is already running with the debug port, implicitly contrasting with chrome_launch for new instances. However, it does not explicitly name alternatives or provide exclusion criteria, so it stops short of full 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?

No annotations are provided, so the description carries the transparency burden. It adds a key behavioral detail—'Awaits promises'—which goes beyond the schema. However, it does not disclose potential side effects (e.g., JS execution may modify page state) or error handling, leaving some gaps.

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

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

The description is two short sentences, front-loaded with the core purpose and no filler. Every word contributes meaningful 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?

Given the simple one-parameter schema and no output schema, the description adequately covers the core behavior and return value. It could mention limitations (e.g., expression must be JSON-serializable) but is complete enough for straightforward usage.

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

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

The schema provides 100% coverage for the 'expression' parameter with the description 'JS expression'. The tool description simply repeats this concept without adding further meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Evaluate') and resource ('JavaScript in the connected tab'), and states the return type ('JSON value'). This clearly distinguishes it from sibling tools like chrome_navigate or chrome_page_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?

Usage is implied by the description ('Evaluate JavaScript in the connected tab') but there is no explicit mention of when to use this over alternatives like chrome_locate or press_key. No exclusions or alternative tool names are given, so it stays at the implied-usage level.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains the visual effects of both styles and notes that the highlight persists until cleared with chrome_clear_highlight, which is important context. It does not mention side effects like DOM mutation or interaction blocking, but the tool is non-destructive and low-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?

The description is a single, information-dense sentence that front-loads the purpose, defines both style options, and points to the clearing tool. No wasted words.

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

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

For a simple 2-parameter tool with no output schema, the description fully covers purpose, parameter semantics, and lifecycle (how to clear). The sibling tool reference provides necessary context. Nothing essential is missing.

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

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

Although the schema covers 100% of parameters, the description enriches the 'style' parameter by explaining the specific visual behavior of each enum value ('spotlight' dims the page, 'pulse' draws an outline). The 'selector' parameter is adequately described by the schema as a CSS selector.

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

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

The description clearly states the tool applies Keynote-style emphasis to an element, with two named styles ('spotlight' and 'pulse') and their visual effects. It distinguishes itself from sibling chrome_clear_highlight by explicitly saying how to clear it.

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

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

The description implies when to use the tool (to emphasize an element) and references chrome_clear_highlight for removal, serving as a complementary alternative. It lacks explicit when-not-to-use guidance, but for a simple visual utility this is sufficient.

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

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

With no annotations, the description carries the full burden of disclosure. It reveals the use of a dedicated clean demo profile and guarantees it never touches the user's real browser profile, which is critical behavioral context. However, it does not disclose potential side effects such as port conflicts, process management, or what 'attach' implies if a browser is already 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?

The description is two sentences with no fluff. Every phrase adds useful information, and the safety guarantee is prominently placed.

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

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

Given the tool's moderate complexity (3 parameters, one nested object, no output schema), the description covers the main purpose, safety guarantee, and optional URL behavior. However, it doesn't explain what the tool returns or how to consume the DevTools connection, which could be important when chaining with sibling tools like chrome_connect or chrome_navigate. This slight gap prevents a higher score.

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

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

The schema already provides descriptions for 67% of parameters (url and port have clear explanations, windowSize has nested width/height in pixels). The description adds only marginal value by saying 'optionally opening a URL' for the url parameter, but doesn't clarify port or windowSize beyond what schema provides. It doesn't explain how these parameters interact with the demo profile or DevTools.

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

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

The description explicitly states a specific action ('Launch (or attach to) Chrome') with a clear resource and scope: a dedicated clean demo profile with DevTools control, optionally opening a URL. It also emphasizes a key differentiator ('Never touches the user's real browser profile'), making it distinct from likely siblings like chrome_connect.

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

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

The description provides context for when to use the tool: when a clean demo profile is needed and DevTools control is required, with an optional URL. It does not explicitly mention alternative tools or state when not to use it, but the context is clear enough to infer its primary use case.

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

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

With no annotations, the description carries the full transparency burden. It discloses the tool's outputs (coordinates, size, text, viewport status), the 100% zoom requirement, and the behavior of scrollIntoView. This adds valuable context beyond the raw schema, though it omits failure modes or side effects.

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 only two sentences long, front-loading the primary purpose and followed by key details. Every sentence earns its place with no redundant wording.

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?

While there is no output schema, the description covers the main return values and a critical constraint (zoom). It adequately addresses the tool's core use case, but does not mention error conditions or behavior when the selector is not found, which would provide extra completeness.

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

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

Schema coverage is 100%, so the baseline is 3. The description enhances the schema by noting that scrollIntoView is an 'instant jump' and advises avoiding it while recording, which adds pragmatic guidance. The selector parameter is self-explanatory.

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

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

The description clearly states the tool's purpose: resolving a CSS selector to screen coordinates for mouse_move, and it lists additional outputs (size, text, viewport status). This distinguishes it from siblings like chrome_scroll and chrome_highlight, making its unique role evident.

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

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

The description provides clear usage context by specifying it should be used before mouse_move to get coordinates. It also includes an important warning about avoiding scrollIntoView during recording. However, it does not explicitly mention when not to use this tool compared to alternatives, so a small gap remains.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses a key behavior—waiting for the page to finish loading—which is useful. However, it does not mention potential side effects, timeouts, or error handling, leaving some transparency gaps.

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

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

The description is a single, concise sentence that front-loads the action and purpose. Every word earns its place; there is no fluff or redundancy.

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

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

For a simple tool with one parameter, no output schema, and no annotations, the description is largely complete. It captures the core action and the wait behavior, and implies the need for a connected tab. It could have mentioned the connection prerequisite more explicitly, but it is not a significant gap.

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

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

The schema has one parameter (url) with a description, giving 100% coverage. The description adds no extra semantic detail about the parameter beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Navigate') and the resource ('the connected tab'), and adds a specific behavioral detail (waiting for the page to finish loading). It is distinct from sibling tools like chrome_scroll or chrome_eval, though it does not explicitly name alternatives, 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?

The description implies a prerequisite ('connected tab') and indicates the operation waits for load completion, giving some context. However, it does not explicitly state when to use this tool versus alternatives like chrome_eval or chrome_connect, nor does it mention 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?

With no annotations provided, the description carries the transparency burden. 'Read the visible text' clearly indicates a read-only, non-destructive operation, and 'visible' distinguishes from hidden or raw HTML content. However, it does not mention truncation behavior or return format, though maxChars in schema hints at truncation.

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

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

The description is a single, front-loaded sentence that conveys purpose and context without redundancy. Every word earns its place, making it highly concise and well-structured.

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

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

Given the tool's low complexity and the schema's complete parameter coverage, the description provides sufficient context for an agent to understand what the tool does and when to invoke it. It lacks only minor behavioral details like error handling or explicit output format, but these are not critical for this simple read tool among siblings.

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

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

The only parameter, maxChars, is fully described in the schema (100% coverage), so the description adds no additional meaning. The baseline of 3 is appropriate because the schema handles parameter semantics and the description does not need to compensate.

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

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

The description clearly states 'Read the visible text of the current page' with a specific verb and resource, distinguishing it from sibling tools like navigate, locate, and eval. The added purpose context ('for understanding the app before scripting the demo') further clarifies its role.

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

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

The description provides clear context for when to use the tool ('for understanding the app before scripting the demo'), implying it should be used for reading page content rather than navigating or evaluating. It does not explicitly mention alternatives or exclusions, but the context is sufficient for typical usage decisions.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the eased, per-pixel animation, the ~1/3 landing offset for selectors, and the ability to use absolute Y. This goes beyond the bare 'scroll' action, though it omits edge-case behaviors like handling when both parameters 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?

Two concise sentences, front-loaded with the core action ('Cinematic in-page scroll'), followed by targeting options and a practical usage hint. Every phrase earns its place with no redundancy or filler.

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

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

Given a low-complexity tool with three optional parameters and no output schema, the description covers purpose, targeting, behavior, and a usage nuance. It is complete for practical use, though it could briefly clarify precedence between selector and y or note that these are mutually exclusive.

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

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

The schema already documents all three parameters (100% coverage), so the baseline is 3. The description adds meaningful context for 'selector' (lands ~1/3 from top) and 'y' (absolute document Y), and provides a practical duration guideline (1200–2500ms on camera), adding value beyond the schema.

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

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

The description clearly states the tool's purpose with a specific verb ('cinematic in-page scroll') and resource ('page'), and distinguishes it from a basic scroll by highlighting 'eased, per-pixel, at reading pace' and targeting via CSS selector or absolute Y. This makes its role unique among siblings.

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

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

The description provides an implied usage context ('on camera', 'reading pace') and a duration recommendation (1200–2500ms), but it does not explicitly mention when to use this tool versus alternatives like the basic 'scroll' sibling. This is implied rather than directly stated.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: voice selection fallback ('Voicebox voice-clone when available, else say'), the action of rendering narration and overlaying it, and the return of both the final mp4 and each beat's duration. It also hints at the need to account for durations in pacing. This goes beyond a simple restatement and provides practical behavioral context.

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

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

The description is compact yet information-dense. It front-loads the 'ONE-CALL FINAL CUT' purpose, explains the process in one sentence, states return values, and adds a practical tip. No word is wasted; every sentence contributes actionable 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?

Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers the essential usage: it explains what the tool does, what it returns, and how to avoid timing pitfalls via the tip. It does not detail error conditions or prerequisites beyond the schema, but the core context is sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how engine and voice parameters interact ('Voicebox voice-clone when available, else say') and mapping the core flow to the 'beats' and 'atSeconds' parameters. This clarifies the intended overall behavior beyond the schema's individual parameter descriptions.

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

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

The description clearly defines the tool as a one-call operation that renders narration for each beat (using Voicebox when available, else say) and overlays it onto the recorded video at specified offsets. It explicitly names the return value (finished .mp4 and per-beat durations), which distinguishes it from sibling tools like render_narration and mux_narration.

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 tip provides clear workflow guidance: render beats first to learn durations, pace the recording to them, then use this tool to compose. This implies when to use the tool (after recording) and suggests a best practice, though it does not explicitly state when to prefer alternatives like render_narration or mux_narration over this combined 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?

With no annotations provided, the description carries the transparency burden. It reveals the 'glide-free' behavior and supports for right/double click, but it does not clarify whether the cursor physically moves to the target coordinates or remains at its original position, leaving a behavioral ambiguity.

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

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

The description is two concise sentences, front-loaded with the core action ('Click'), and contains no unnecessary words. It efficiently communicates the tool's capabilities.

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 tool with four optional parameters and no output schema, the description covers the primary invocation modes (current position, x/y) and modifiers (right/double). It omits minor details like default left-click behavior, but the schema already labels x/y as screen coordinates, making the description sufficiently 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 100% since all parameters (x, y, right, double) have descriptions. The description adds no additional meaning beyond the schema—it merely restates that clicks can happen at x/y coordinates. Baseline score is appropriate.

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

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

The description clearly states the tool's function with the verb 'Click' and specifies two modes: current cursor position or x/y coordinates. It also mentions support for right and double click, distinguishing it from sibling tools like mouse_drag and mouse_move.

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

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

The description implies when to use the tool (clicking at a location) but does not explicitly contrast it with alternatives like mouse_drag or mouse_move, nor does it provide exclusions or prerequisites. The context is clear but the guidance is not explicit.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals the sequence (press, drag, release) and the smoothing behavior, but lacks details such as whether it uses absolute screen coordinates, how it interacts with the page (e.g., synthetic events vs. physical mouse), or whether it blocks until complete. This is a minimal disclosure for a tool that could have side effects.

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, concise sentence that front-loads the core action. It avoids redundancy and wasted words, effectively conveying the tool's purpose in a compact form.

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

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

Despite having a well-described schema, the description is too brief to fully inform an agent in the absence of annotations and output schema. It does not explain return values, coordinate system, or any prerequisites (e.g., page must be loaded). For a tool with 5 parameters and no structured safety info, the description leaves too much unspecified.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context by connecting the coordinates ('from one point to another') and implying the duration parameter ('smoothly'), but it does not add significant meaning beyond the schema's parameter descriptions. It reinforces the relationship rather than introducing new semantics.

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

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

The description clearly states the tool's function: 'Press, drag smoothly from one point to another, release.' It identifies the specific action (drag) and the parameters (start and end points), distinguishing it from siblings like mouse_move (movement without pressing) and mouse_click (click without dragging).

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

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

The description implies usage: it's for dragging between two points with a smooth motion. However, it does not explicitly mention alternatives or exclusions, such as 'use mouse_move instead for repositioning without pressing.' The context of dragging is clear, but there is no direct guidance on when not to use it.

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

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

With no annotations, the description carries the burden, and it discloses the smooth, curved, eased path and the 'real cursor' nature. It also advises on appropriate timing. It doesn't mention edge cases or return values, but the core behavior is well described.

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

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

The description is two sentences, with the main action first and guidance second. No unnecessary detail.

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 mouse move tool with no output schema, the description covers the essential behavior and parameter guidance. It omits potential error handling, but that's likely not critical for this low-complexity tool.

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

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

The schema already describes all three parameters, so the baseline is 3. The description adds a recommended ms range (600–1000ms) and links it to on-camera moves, which is useful beyond the schema.

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

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

The description clearly states the tool's action: moving the real cursor to screen coordinates with a specific motion style. It distinguishes itself from sibling mouse tools (mouse_drag, mouse_click) by focusing on cursor movement and its human-like presentation.

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

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

It provides context for use ('like a human presenter', 'on-camera moves') and specific duration guidance for the ms parameter. However, it doesn't explicitly state when not to use it or alternative tools for other gestures.

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

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

With no annotations, the description carries the full burden. It discloses that video stream is copied (no re-encode) and audio is loudness-normalized, and that ffmpeg is required. However, it does not mention side effects like overwriting files, potential performance impact, or failure modes. This is reasonable but not rich.

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

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

The description is a single, well-structured sentence that starts with the action and includes key output details and a dependency. Every part adds value, and it is appropriately sized.

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

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

The description covers the core behavior and output format, and the schema is complete. However, it does not mention potential errors, the return value, or what happens if segments overlap or offsets are invalid. Given the complexity of video processing, a bit more context would be helpful.

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

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

Schema description coverage is 100%, so all three parameters (video, output, segments) are already described in the schema. The description adds no additional parameter-level information, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: layering narration segments over a video with precise offsets and producing an .mp4. It names the specific resource (rendered narration segments, recorded video) and the output format. While it doesn't explicitly distinguish from sibling tools like compose_final_video, the specific verb and output details make the purpose clear.

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

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

The description implies this tool is used after rendering narration and on a recorded video, but it gives no explicit guidance on when to use this tool versus alternatives. There is no mention of 'use render_narration first' or 'instead of compose_final_video'. The only prerequisite mentioned is ffmpeg.

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

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

With no annotations present, the description carries the full burden. It discloses that the tool blocks until finished, returns the spoken duration, and uses macOS say. It also reveals the important limitation that live audio isn't captured in recordings, which is critical 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?

Two sentences plus a note, all informative with no filler. It front-loads the action and includes the key caveat in a clearly marked note.

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 speech tool with three parameters, the description fully covers purpose, behavior, blocking semantics, return value, and workflow integration. The lack of output schema is mitigated by explicitly stating the return value (spoken duration). Complete for its complexity.

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

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

The input schema already provides 100% coverage with descriptive text for text, rate, and voice. The description does not add additional parameter-level meaning beyond noting the macOS 'say' implementation, so it doesn't exceed the baseline of 3.

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

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

The description clearly states the tool speaks narration live through speakers using macOS 'say', with a specific verb ('speak') and resource ('narration'). It distinguishes itself from render_narration and mux_narration by emphasizing 'live' and noting that audio isn't captured for recording.

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 notes that live audio is not captured in the recording and directs users to render_narration + mux_narration for the final cut, providing clear exclusions and alternatives. Also explains it's useful for pacing, giving context for when to use.

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

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

With no annotations, the description fully carries the burden. It explicitly states the tool holds for N seconds, which is the complete behavioral contract for a simple delay. It adds context about presenter pacing, though it does not mention blocking behavior (which is implied and unlikely to need disclosure).

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

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

The description is a single sentence that is front-loaded with the action ('Hold for N seconds') and provides useful context in the second clause. Every word earns its place.

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

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

Given the tool's extreme simplicity (one parameter, no output schema, no side effects), the description provides all necessary information: what it does and why. There are no 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 100% for the single 'seconds' parameter. The description's 'N seconds' loosely references it but adds no new meaning beyond the schema's 'seconds to wait'. Baseline 3 is appropriate.

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

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

The description uses the specific verb 'Hold' with a clear resource ('N seconds'), and the phrase 'presenter beats between actions' conveys the tool's role. It is distinct from all sibling tools, none of which perform a similar delay function.

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

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

The description indicates a clear usage context: between actions to let viewers absorb content. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous for a timing utility.

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

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

No annotations are present, so the description carries the burden of explaining behavior. It clearly enumerates the accepted keys and modifier names, providing an exhaustive list that goes beyond any structured data. It does not describe side effects like whether the key is pressed and released, but for a simple key-press tool, the list of valid inputs is strong disclosure. It does not contradict any annotations (there are none).

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

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

The description is two concise sentences. The first sentence states the core function, and the second sentence lists the supported keys and modifiers in a compact, scannable format. Every word earns its place; there is no fluff or repetition.

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

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

For a two-parameter tool with no output schema, the description is highly complete. It fully covers the allowed input space for both parameters. It does not mention return values, error behavior, or target focus, but these are arguably not essential for a key-press tool. The lack of annotations is compensated by the explicit key/modifier lists, making this close to fully contextual.

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

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

The input schema covers 100% of parameters with descriptions and examples, which earns a baseline of 3. The description adds meaningful value by enumerating the full set of valid key names (return, tab, space, escape, delete, arrows, home/end, pageup/pagedown, a–z, 0–9) and modifier names (cmd, shift, alt, ctrl). This transforms the schema's generic examples ('return', ["cmd"]) into a complete vocabulary guide.

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

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

The description opens with a specific verb and resource: 'Press a key with optional modifiers.' It distinguishes itself from sibling tools by listing the exact supported keys and modifiers, which separates it from type_text (typing text) and mouse actions. The scope is clear: individual key presses with keyboard shortcuts in mind.

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 context is implied rather than explicitly stated. The list of non-character keys (arrows, return, tab, etc.) suggests this is for shortcuts and navigation keys, and 'type_text' exists as a sibling tool for typing strings. However, there is no explicit 'when to use this' vs. alternatives, no mention of keyboard focus requirements, or 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?

The description discloses the core behavior (status and elapsed time) but does not explicitly state it is read-only or side-effect-free. With no annotations, the description carries the full burden and could benefit from saying 'does not alter recording state'.

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

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

A single, concise sentence that front-loads the core purpose. No redundant words or filler, making it highly 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?

Given the simplicity (no params, no output schema), the description adequately conveys the tool's purpose. It could be more complete by specifying the return format (e.g., boolean and time string), but it is sufficient for a basic status indicator.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly focuses on the output rather than inputs, needing no further parameter explanation.

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

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

The description clearly indicates the tool reports recording status ('Whether a recording is in progress') and duration ('for how long'). It is distinct from sibling tools like start_recording and stop_recording, though it lacks an explicit verb like 'returns' or 'gets'.

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: use this tool to check if a recording is active. However, there is no explicit guidance on when to prefer this over alternatives like voicebox_status, nor any exclusions or prerequisites mentioned.

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

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

With no annotations, the description carries full burden. It discloses several processing behaviors: per-sentence generation, jittered pauses, soft in-breaths, and -16 LUFS normalization, plus the engine fallback. This is substantial context, though it does not mention side effects like file overwrite/path creation or error behavior, which would push it to 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 two compact sentences, with the primary purpose and return value front-loaded in the first sentence. The second sentence packs key behavioral details without fluff. Every word contributes value, and no information is redundant with the schema.

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

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

For a tool with 6 parameters, no annotations, and no output schema, the description covers the main contract: what it does, engine fallback, processing traits, and the return value (exact duration). It lacks details on default output format and the exact return type, but given the complexity, the description is largely complete, meriting a 4.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema, particularly for the 'engine' parameter (explains when Voicebox vs say is used) and for the 'text' parameter (relates per-sentence generation and pauses to how text is processed). This extra semantic richness justifies a 4.

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

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

The description uses a specific verb ('render') plus resource ('a narration line to an audio file') and states the key outcome (return EXACT duration for muxing/pacing). It clearly distinguishes this tool from siblings like narrate (which implies playback), voicebox_status (status check), and mux_narration (muxing), by focusing on audio file generation with duration.

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

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

The description provides clear context on when to use the tool (for muxing/pacing) and explains the engine 'auto' behavior with a fallback to macOS say, which guides selection among engine choices. It does not explicitly name alternative tools for exclusion, but the purpose statement and sibling list make it clear that this is the rendering step, distinct from status checking or muxing.

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

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

With no annotations, the description carries the burden. 'List' clearly signals a read-only operation, and it details what data is returned (display id, bounds, main flag, mouse position). It doesn't discuss coordinate systems or live-update semantics, but for a simple informational tool, the behavioral disclosure is adequate.

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

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

A single, well-structured sentence that front-loads the action and lists the exact information returned. No filler or redundant wording.

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

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

Given the low complexity, zero parameters, and no output schema, the description fully explains what the tool returns. It covers both the display details and mouse position, making it sufficient for an agent to select and invoke the tool correctly.

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

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

The tool takes zero parameters, so there is nothing to document. The baseline for 0-parameter tools is 4, and the description appropriately adds no parameter information because none exists.

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

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

The description uses the specific verb 'List' with a clear resource ('displays') and details the output fields (id, bounds, main) plus the current mouse position. This clearly distinguishes it from sibling tools like mouse_move and mouse_click, which are action-oriented rather than informational.

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

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

The description clearly implies when to use the tool: when you need display configuration or the current mouse position. It doesn't explicitly mention alternatives or exclusions, but the context is unambiguous because no other sibling tool provides this kind of system information.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the scroll is OS-level, momentum-based, occurs at the cursor position, and defines the sign convention for dy. It does not cover edge behaviors like whether the scroll is smooth or if it blocks, but for a simple scroll action the key behaviors are well explained.

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

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

The description is two sentences, front-loaded with the core purpose, and every clause earns its place: OS-level, cursor position, sign convention, and the alternative tool. No fluff or repetition.

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

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

Given no annotations and no output schema, the description provides sufficient context for a simple scroll tool: what it does, where it operates, the sign convention, and an alternative for a specific use case. It doesn't mention return values or failure modes, but those are unlikely to be critical for a scroll utility, so the description is nearly complete.

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

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

The input schema already covers 100% of parameters with clear descriptions (dx, dy, ms), and the description adds the sign convention for dy ('dy > 0 scrolls the page DOWN'), though this is largely redundant with the schema's 'positive = down'. The description doesn't add meaningful parameter semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool performs an OS-level momentum scroll at the cursor position, with a specific verb ('scroll'), a clear resource ('OS-level'), and a location ('cursor position'). It also distinguishes itself from the sibling chrome_scroll by contrasting OS-level vs web-page-on-camera use.

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

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

The description explicitly says 'For scrolling a web page on camera, prefer chrome_scroll', providing a concrete alternative for a common scenario. It implies this tool is for OS-level scroll outside of that camera-specific web page context, giving clear when-to-use guidance.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits, but it only mentions the output format and optional restrictions. It fails to disclose that recording continues until stopped, potential permission prompts, or asynchronous behavior, which are critical operational side effects.

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, well-structured sentence that front-loads the verb and resource, includes the key output format, and has zero filler. It achieves maximum clarity in minimal 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?

The description covers the basic purpose and optional parameters, but it lacks essential workflow context such as the need to stop recording with a sibling tool, how the recording is finalized, or what the call returns. Given the tool's moderate complexity and absence of an output schema, this is a noticeable gap.

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

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

The description summarizes the display and area parameters as 'Optionally restrict to a display number or a pixel region,' but the input schema already provides detailed descriptions for all parameters, including nested area properties and output default. The incremental semantic value is limited, so the baseline score of 3 for high schema coverage is appropriate.

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

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

The description clearly states the action ('Start recording the screen'), specifies the output format (.mov) and platform (macOS native screencapture), and distinguishes itself from sibling tools like stop_recording and recording_status by focusing on the initiation of recording.

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 explicit guidance is provided on when to use this tool versus alternatives. While sibling names imply a paired workflow with stop_recording, the description does not state prerequisites, exclusions, or recommend alternative tools for specific scenarios, leaving the agent without selection context.

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

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

With no annotations, the description carries the burden of disclosing behavior. It clearly states the main side effect (stopping the recording) and the return values, but does not mention edge cases such as what happens if no recording is active, whether the operation is blocking, or where the file is saved beyond a generic path.

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

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

The description is a single clear sentence that front-loads the action and includes the key output information. There is no wasted text or unnecessary detail.

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, no-output-schema tool, the description covers the essential behavior and return values. It is slightly incomplete because it does not address the no-active-recording case or the exact return format, but these are minor given the tool's simplicity.

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

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

The tool has zero parameters, so the schema is empty and the baseline is 4. The description adds value by explaining the output (file path, duration, size) even though no parameter semantics are needed.

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

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

The description clearly states the tool's action ('Stop') and resource ('current screen recording'), and specifies that it returns the file path, duration, and size. This distinguishes it from siblings like start_recording and recording_status by focusing on the termination/finalization step.

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

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

The word 'current' implies that the tool should be used when a screen recording is already in progress, providing implicit usage context. However, there is no explicit guidance about when not to use it or how it compares to alternatives like recording_status or start_recording.

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

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

With no annotations, the description carries the full burden. It discloses key behavioral traits (jittered inter-key timing, slower after punctuation, default cps) and implies a prerequisite (focused control). It does not mention potential failures or side effects, but the provided behavioral details add substantial value beyond the schema.

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

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

Two concise sentences. The first states the core action and target, the second explains the timing parameter. No wasted words, and the most important information is front-loaded.

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

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

For a simple 2-parameter tool with no output schema, the description covers the action, target, behavior, and parameter defaults. Missing details like error handling or behavior when no control is focused are minor given the tool's simplicity.

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

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

Schema coverage is 100%, and the description repeats the cps default (12) already present in the schema. It adds no extra parameter-specific meaning beyond what the schema provides, so it meets the baseline for high coverage.

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

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

The description clearly specifies the action ('Type text into the focused control') and adds a distinguishing behavior ('human rhythm with jittered inter-key timing, slower after punctuation'). This distinguishes it from sibling tools like press_key or mouse_click, which handle discrete inputs.

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

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

The description implies when to use the tool: whenever text needs to be typed into a focused control, with a humanized timing. However, it does not explicitly exclude alternatives or state when not to use it, so it lacks a bit of comparative guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses the read-only nature by using 'check' and 'list,' and gives context (selecting a voice). It does not elaborate on error states or side effects, but for a simple status/listing tool, the behavior is reasonably transparent.

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

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

The description is two concise sentences. The first sentence front-loads the core purpose; the second gives practical usage context. There is no redundant information or filler, making it highly 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?

Given the tool's simplicity (no parameters, no output schema), the description covers the essentials: what it does, when to use it, and why. It could be slightly more explicit about the exact return format or potential failure modes, but it is largely complete for a pre-flight status check.

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

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

The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter details because none exist. It does imply the output (list of voices), which is appropriate for a parameterless tool.

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

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

The description clearly states the tool's function: checking the local Voicebox app and listing installed voices. The verb 'check' and 'list' are specific, and the resource (Voicebox app, installed voices) is explicit. It also distinguishes itself from sibling narration tools by framing this as a pre-rendering step.

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

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

The description provides explicit timing guidance: 'Run before rendering final narration to pick a voice with the user.' This is a clear 'when' instruction. However, it does not mention alternatives or exclusions, so it stops short of a full 5.

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