Server Quality Checklist

Tool Scores

• studio_typeA
  4/5.0
  Behavior4/5

  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 discloses that typing is keystroke-by-keystroke (not a paste) and that input appears on tape, implying recording. However, it does not detail error handling or idempotency, which is acceptable for a straightforward typing tool.

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

  Conciseness5/5

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

  Two concise sentences that immediately convey the tool's action and key behavioral nuances. Front-loaded with the verb 'glide to an input and type'—no wasted words.

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

  Completeness4/5

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

  For a typing tool with full schema coverage and no output schema, the description plus schema provide sufficient context. The behavior (keystroke-by-keystroke, recording awareness) is adequately described, though absence of return value mention is acceptable.

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

  Parameters3/5

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

  Schema coverage is 100% with descriptions for all three parameters. The description adds marginal value by suggesting 'demo content' for input_text and implying human pace for delay_ms, but does not significantly enhance understanding beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's action: typing text at a human pace keystroke by keystroke, distinguishing from pasting. The verb 'type' and resource 'input' are specific, and the context of studio tools makes differentiation from siblings natural.

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

  Usage Guidelines3/5

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

  The description provides context (use realistic demo content, aware of recording) but does not explicitly state when to use this tool vs. alternatives. No exclusions or when-not-to-use guidance is given.

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

• studio_gotoA
  4.1/5.0
  Behavior4/5

  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 details that the tool waits for network settle, optional wait_for selector, and skeleton loaders before lifting the card, which is good behavioral transparency. It does not mention auth or rate limits, but these are less critical for a navigation tool.

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

  Conciseness4/5

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

  The description is a single paragraph but well-structured, front-loading the purpose, then usage, then behavior. It is concise yet informative, though could be slightly tighter.

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

  Completeness4/5

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

  With 5 parameters, one required, and no output schema, the description covers the tool's behavior (transition card, waiting conditions) well. It omits return values but that's acceptable without an output schema. The context is sufficient for an agent to use the tool correctly.

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

  Parameters3/5

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

  Schema coverage is 100%, so the description adds minimal value beyond the schema. For example, it adds 'usually the surface name' for title and example 'DASHBOARD' for eyebrow, but these are marginal. Baseline 3 is appropriate given high schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool navigates to a URL with a transition card to avoid loading flash. It distinguishes from sibling tools like studio_click (click action) and studio_narrate, etc., making the purpose specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description advises using this for 'the opening shot AND every surface change', giving clear context for when to invoke it. However, it does not explicitly state when not to use it or compare with alternatives like studio_click for navigation, slightly limiting the guidance.

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

• studio_screenshotA
  4.2/5.0
  Behavior4/5

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

  Discloses high-DPI (2x), PNG format, output directory, file path return, and effect of captions/rings. No annotations provided, so description carries full burden and does well.

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

  Conciseness5/5

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

  Four sentences, no fluff, front-loaded main action. Every sentence adds value.

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

  Completeness4/5

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

  Covers purpose, modes, return value, and a caveat. Missing details on error handling or overwrite behavior, but sufficient for basic use.

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

  Parameters3/5

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

  Schema coverage is 100% with clear descriptions for all three parameters. Description restates the modes but adds no new information beyond the schema.

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

  Purpose5/5

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

  Clearly states verb 'Take a screenshot', resource 'current frame', output format 'PNG', and high-DPI detail. Uniquely identifiable among sibling tools.

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

  Usage Guidelines4/5

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

  Provides context of when it works ('any time during a session') and two modes (element-only or full_page). Includes a preparatory note about clearing captions. No explicit exclusions needed as no sibling overlaps.

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

• studio_finishA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels. It discloses all important behaviors: closes the browser, strips dark frames, transcodes, local voice narration, music bed, subtitles, social crops, GIF generation, auto-correction of voice timing, and return of file info. This is very transparent.

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

  Conciseness4/5

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

  The description is appropriately sized for a complex tool with many features. It front-loads the core purpose and then expands. While lengthy, every sentence adds value. Could be slightly more concise, but highly efficient overall.

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

  Completeness5/5

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

  Given the complexity (7 parameters, no output schema, no annotations), the description is remarkably complete. It covers the entire workflow, fallback case, and return value details. Nothing essential is missing.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The tool description adds workflow context but does not add meaning beyond what the parameter descriptions already provide. No additional parameter details are given in the main description.

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

  Purpose5/5

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

  The description uses a specific verb (Stop recording and produce) and clearly identifies the resource (final files). It lists the major actions (closes browser, strips frames, transcodes, voice-over, subtitles, crops, GIF) and distinguishes from sibling tools like studio_start and studio_caption by being the finishing tool.

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

  Usage Guidelines4/5

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

  The description implicitly indicates when to use (after recording, to finalize) and provides a fallback scenario ('Without ffmpeg you still get the raw WebM'). However, it does not explicitly exclude alternative tools or state when not to use this tool.

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

• studio_holdA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses the key behavior: gliding to an optional target and keeping micro-drift to avoid dead-static hold frame drops. Does not cover all edge cases but provides critical insight.

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

  Conciseness5/5

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

  Two sentences, no wasted words. Front-loads the action and purpose, then adds usage guidance. Each sentence earns its place.

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

  Completeness4/5

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

  No output schema exists, but for a simple hold tool the description covers purpose, usage context, parameter details, and a behavioral nuance (micro-drift). Missing some edge cases but adequate for the tool's simplicity.

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

  Parameters4/5

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

  Schema coverage is 100%, but the description adds context: explains that 'target' is optional and gives an example, and clarifies that 'ms' has a default of 2200 with a suggested range. Adds value beyond schema.

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

  Purpose5/5

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

  The description clearly states the tool's action ('Hold the shot') and resource, distinguishing it from siblings like studio_click or studio_scroll by focusing on pausing with micro-drift to keep tail frames.

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

  Usage Guidelines4/5

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

  Explicitly recommends usage after captions, highlights, and zooms, and suggests a typical duration (2000–3000ms). Does not explicitly mention when not to use or alternatives, but context from sibling tools implies them.

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

• studio_zoomA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, but the description reveals key behaviors: captions stay screen-fixed while content scales, and failure to reset causes the zoom to persist. This adds significant context beyond the input schema.

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

  Conciseness5/5

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

  Two sentences pack the core action and the critical usage rule without superfluous words. Front-loaded with the main verb and resource.

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

  Completeness4/5

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

  For a zoom tool with no output schema, the description covers the action, special behavior (captions fixed), and the essential reset requirement. It is sufficiently complete for an agent to use it correctly.

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

  Parameters3/5

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

  Schema covers all 4 parameters with descriptions. The description reinforces the importance of 'reset' and the default for 'zoom_scale', but doesn't add new meaning beyond the schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Camera punch-in: smoothly zoom the page toward a target (CSS selector or visible text)'. It uses specific verb and resource, and the unique zooming action distinguishes it from sibling tools like studio_click or studio_highlight.

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

  Usage Guidelines5/5

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

  Explicit guidelines are given: 'ALWAYS studio_zoom with reset=true before navigating or showing the end card, or the next scene inherits the zoom.' This tells when to use the tool and when not to (i.e., without reset before navigation).

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

• studio_cancelA
  4.5/5.0
  Behavior5/5

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

  No annotations provided, so description fully covers behavior: idempotent (no-op), destructive (discards tape), but only screenshots preserved. Excellent disclosure.

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

  Conciseness5/5

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

  Three front-loaded sentences, no wasted words. Every sentence adds value.

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

  Completeness5/5

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

  Fully sufficient for a parameterless tool with no output schema. Covers purpose, effect, safety, and idempotency.

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

  Parameters3/5

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

  Schema has 0 parameters with 100% coverage. Baseline 3 applies; no additional parameter info needed.

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

  Purpose5/5

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

  Clearly states 'Abandon the current recording session' with specific verb and resource, and explains consequences (closes browser, discards tape). Distinguishes from sibling tools like studio_start or studio_finish.

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

  Usage Guidelines4/5

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

  Provides clear context: safe to call when no session active (no-op). Does not explicitly contrast with siblings like studio_finish, but usage is well implied.

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

• studio_narrateA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description provides key behavioral traits: the line is synthesized at studio_finish, it holds the shot, and hold_ms controls duration. This adds 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.

  Conciseness5/5

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

  Two sentences, no fluff. The main action is front-loaded, and every clause adds necessary detail.

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

  Completeness4/5

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

  For a simple tool with 2 parameters and no output schema, the description covers core behavior, duration guidance, and dependency on studio_finish. Minor omission: no mention of errors or audio limits, but acceptable.

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

  Parameters5/5

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

  Schema coverage is 100%, and the description adds nuance: 'spoken, not shown' for line and guidance for hold_ms based on word rate. This enriches the schema's documentation.

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

  Purpose5/5

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

  The description clearly states it records voice-over without a caption, distinguishing it from sibling tools like studio_caption. The verb 'Record' and resource 'voice-over' are specific.

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

  Usage Guidelines4/5

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

  It explains when to use (before studio_finish with voiceover:true) and how to set hold_ms based on sentence length. However, it doesn't explicitly mention when not to use, though the sibling list implies alternatives.

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

• studio_captionA
  4.6/5.0
  Behavior4/5

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

  No annotations provided, so the description carries full burden. It discloses that caption_text is also recorded as voice-over script, that clear fades out the caption, and that no_voice excludes from narration. It does not fully clarify whether multiple calls stack or replace, but the phrase 'show (or replace)' implies replacement. Minor gaps exist but overall transparent.

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

  Conciseness4/5

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

  The description is front-loaded with the main purpose and is reasonably concise. Every sentence adds value, but it could be slightly streamlined without losing information. Slight verbosity around the voice-over explanation.

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

  Completeness4/5

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

  Given the complexity (4 parameters, no output schema, no annotations), the description covers the tool's behavior, constraints, and relationships to studio_hold and studio_finish. It does not discuss return values or errors, but for a UI caption tool this is acceptable. Overall complete.

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

  Parameters5/5

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

  Schema coverage is 100%, yet the description adds significant meaning: explains that caption_text doubles as voice-over script, describes eyebrow as 'small uppercase kicker', and clarifies that clear fades out and no_voice excludes from narration. This goes far beyond the schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'show (or replace) the bottom-left storyline caption'. It specifies the resource (storyline caption) and action (show/replace), and distinguishes from sibling tools by mentioning the voice-over relationship and alternative usage via no_voice.

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

  Usage Guidelines5/5

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

  Explicitly describes when to use the tool (narrate the current beat), constraints (under ~12 words, leave up 2-4s using studio_hold), and specific cases like clearing captions with clear=true or suppressing narration with no_voice=true. It also ties to studio_finish for voice-over, giving clear context.

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

• studio_end_cardA
  4.6/5.0
  Behavior5/5

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

  No annotations are provided, so the description fully carries the burden. It details visual behavior (centred glass card over still visible product), timing (~2.5s hold), and clarifies that the URL is shown as text, not a live link. This provides adequate transparency for the agent to understand the effect.

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

  Conciseness5/5

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

  The description is two sentences long with no wasted words. It front-loads the purpose ('Show the closing card') and immediately follows with visual and functional details. Every sentence earns its place.

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

  Completeness4/5

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

  For a simple UI tool with 3 parameters and no output schema, the description covers the visual output, behavior, and integration with studio_finish. It does not mention error scenarios or edge cases, but for typical use, it is sufficiently complete.

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

  Parameters4/5

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

  Schema coverage is 100%, but the description adds value beyond the schema: it clarifies that the subtitle is 'one supporting line under the title', the title is 'the big closing line', and the URL is displayed as text, not a link. These details enrich the schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool shows a closing card with a title, optional subtitle, and URL, placed as a centred glass card over the visible product. It distinguishes itself by specifying it is 'the classic outro' and explicitly mentions the subsequent step (studio_finish), differentiating it from siblings like studio_caption or studio_highlight.

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

  Usage Guidelines4/5

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

  The description provides a clear usage hint: 'Hold ~2.5s after this, then studio_finish', indicating this tool should be used before studio_finish as the closing step. It does not explicitly state when not to use or mention alternatives, but the context of a sequence makes the guidance sufficient.

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

• studio_highlightA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses side effects: scrolling into view, overlaying rings, stacking until cleared. Also describes return values for success and failure, and advises retrying with studio_screenshot. No contradictions.

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

  Conciseness5/5

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

  The description is a single paragraph with front-loaded purpose. Every sentence is informative and necessary—no fluff. It efficiently covers behavior, usage, and return values.

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

  Completeness5/5

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

  Given no output schema and 4 parameters without nesting, the description covers all needed details: side effects, error handling, best practices, and parameter semantics. No apparent gaps.

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

  Parameters4/5

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

  Schema already provides descriptions for all 4 parameters (100% coverage). The description adds value by explaining the interaction between clear and other parameters, giving example values like '.metric-card' or 'Monthly revenue', and clarifying that label and eyebrow are optional. This goes beyond the schema alone.

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

  Purpose5/5

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

  Clearly defines the tool as drawing an accent ring around a target (CSS selector or visible text) with an optional label card. It distinguishes itself from sibling tools like studio_screenshot or studio_click by explicitly calling it a 'look here' callout.

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

  Usage Guidelines4/5

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

  Provides explicit guidance to call clear=true before navigation, zoom, or changing target to avoid stale rings. Mentions retrying with studio_screenshot on error. However, it does not explicitly compare with sibling tools like studio_cancel for clearing rings, nor state when not to use this tool beyond the clear advice.

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

• studio_startA
  4.7/5.0
  Behavior5/5

  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 details the behavior: launches a headless browser, captures video, returns config and output directory. It also warns about incorrect background causing flashes and explains the purpose of storage_state_path for credential-free recording.

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

  Conciseness4/5

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

  The description is a single paragraph that efficiently conveys purpose, constraints, and parameter guidance. It is front-loaded with the primary action and then adds details, though it could benefit from slight structural separation.

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

  Completeness5/5

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

  Given the complexity of the tool (8 parameters, nested theme object, no output schema), the description covers all essential aspects: return value, single-session constraint, parameter usage tips, and important caveats. It feels complete for an AI agent.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds significant meaning beyond the schema. For example, it explains that theme.bg should match the app background to avoid flashes, and that hide_selectors removes UI elements. It provides practical guidance for using storage_state_path and cookies.

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

  Purpose5/5

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

  The description uses a specific verb-resource pair: 'Start a recording session'. It clearly distinguishes from siblings like studio_finish and studio_cancel by stating that one session is active at a time.

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

  Usage Guidelines4/5

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

  Explicitly states that only one session can run and must be ended with studio_finish or studio_cancel. Provides context for when to use parameters like theme and hide_selectors, but does not explicitly list when not to use the tool.

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

• studio_scrollA
  4.9/5.0
  Behavior5/5

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

  No annotations provided, but the description discloses smooth scrolling (never a jump cut), side effect (only page scroll position, no click/navigation), and return value ('scrolled' on completion). Fully transparent.

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

  Conciseness5/5

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

  Three sentences, front-loaded with core action, each sentence provides essential information without redundancy. Very concise and well-structured.

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

  Completeness5/5

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

  Despite no output schema, the description covers all necessary aspects: parameters, behavior, side effects, return value, and usage context. Complete for a scroll tool with clear, thorough guidance.

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

  Parameters4/5

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

  Schema coverage is 100% with parameter descriptions. The description adds value by specifying mutual exclusivity of to_y and to_target, and explicitly states the default duration of 1300 ms, enhancing understanding beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool scrolls with cubic easing to a Y offset or target element, never with a jump cut. It distinguishes from siblings by emphasizing it's purely scroll, no click or navigation, and is used between story beats.

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

  Usage Guidelines5/5

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

  Explicitly says 'Use between story beats to bring the next area on camera' and advises to scroll before studio_click or studio_highlight to reveal off-screen elements. Provides clear context and suggests alternatives.

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

• studio_clickA
  5/5.0
  Behavior5/5

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

  No annotations are provided, so description carries full burden. It discloses the deliberate slow glide, post-click waiting for page settle, re-application of theme overlays, and return values/error messages. No hidden destructive behavior is omitted.

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

  Conciseness5/5

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

  Four dense sentences, each earning its place. Core action is first, followed by usage guidance, preconditions, selector strategy, and post-click behavior. No filler or repetition.

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

  Completeness5/5

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

  Despite no output schema or annotations, the description covers all critical aspects: return values, error conditions, post-click behavior, and parameter details. It also suggests adjacent tools for preconditions, completing the contextual picture.

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

  Parameters5/5

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

  Schema coverage is 100%, baseline 3, but description adds significant value: explains target can be CSS selector or visible text with examples, and for settle_ms gives default, allowed values, and purpose ('more deliberate beat'). This exceeds baseline expectations.

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

  Purpose5/5

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

  The description clearly states the tool's action: 'Glide the visible cursor to a target and click it' for walkthroughs. It distinguishes from sibling tools by specifying the deliberate slow motion and on-camera context.

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

  Usage Guidelines5/5

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

  Explicitly says 'Use for every button/link/menu interaction in the walkthrough.' Provides preconditions (target must be on screen, use studio_goto/studio_scroll first) and fallback strategy (CSS selector preferred, visible text as fallback). Also instructs on error handling: take screenshot and pick better target.

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