Server Quality Checklist

Tool Scores

• stagehand_actB
  3.2/5.0
  Behavior2/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 of behavioral disclosure. It merely says 'perform' without explaining side effects, whether the action can be undone, if it requires a page to be loaded, or what happens on failure. Since this is likely a state-changing tool, more transparency is needed.

  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, concise sentence that immediately states the tool's purpose with examples. Every word earns its place; no filler or redundancy.

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

  Completeness2/5

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

  Despite having 2 parameters, nested objects, and no output schema, the description is minimal. It does not explain return values/outcomes, how it connects to other stagehand tools, or the scope of 'action'. Given the complexity and sibling toolset, more context is needed for an agent to select and 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 description coverage is 100%, with detailed descriptions for both 'action' and 'variables' including examples and variable merge behavior. The description itself adds no parameter information beyond what the schema already provides, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states it performs a single action on the page, with concrete examples (click, type). This distinguishes it from multi-step tools like stagehand_agent or stagehand_scenario, though it doesn't explicitly name sibling tools. The verb 'perform' and resource 'action on the page' are specific enough.

  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?

  Usage is implied by the phrase 'single action'—suggesting it's for one-off interactions rather than multi-step flows. However, there is no explicit guidance on when to use this tool vs. alternatives like stagehand_observe or stagehand_extract, nor any mention of exclusions or prerequisites.

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

• stagehand_observeB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the tool finds elements and optionally returns an action, without detailing side effects, return format, session requirements, or any safety implications. This is insufficient for a tool that likely interacts with a live page.

  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, efficient sentence that front-loads the main purpose. However, the phrase 'optionally return an action' is vague and could confuse the agent about what the tool actually returns, reducing clarity without adding meaningful structure.

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

  Completeness3/5

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

  The tool is simple (one parameter, no output schema), and the schema description provides extensive guidance on the instruction parameter. However, the description lacks context about the tool's role in the overall workflow (e.g., observing before acting) and its return behavior, making it minimally complete.

  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?

  The input schema has 100% coverage for the single parameter, with a detailed description of how to formulate the instruction. The tool description adds no new parameter information, matching the baseline of 3 for 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 finds interactive elements from an instruction, with a specific verb ('find') and resource ('interactive elements on the page'). It also hints at an optional action output, distinguishing it from sibling tools like stagehand_act (which performs actions) and stagehand_extract (which extracts data).

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

  Usage Guidelines2/5

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

  No explicit guidance is provided for when to use this tool instead of alternatives. The description does not name sibling tools or exclusion criteria, though the 'optionally return an action' phrase implies it may precede act. The schema description mentions later use with the act tool, but the description itself lacks this context.

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

• stagehand_agentB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It adds a behavioral detail: 'uses both DOM-based and coordinate-based actions for maximum reliability.' However, it does not disclose potential side effects, permission requirements, return behavior, or the fact that the agent may navigate and interact with external pages, leaving significant 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.

  Conciseness5/5

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

  The description is extremely concise—two short sentences that front-load the core purpose ('Execute a task autonomously') and a supporting operational detail ('uses both DOM-based and coordinate-based actions'). Every word contributes meaning, with no redundancy.

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

  Completeness2/5

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

  This is a high-complexity agent tool with no output schema and no annotations, yet the description is minimal. It does not explain what the agent will do beyond 'execute a task,' how it handles variables or steps, or what the result will look like. The rich parameter schema helps but does not compensate for the missing behavioral and output context.

  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%, with detailed descriptions for all three parameters (prompt, maxSteps, variables) already provided in the schema. The tool description itself adds no parameter-specific semantics, so baseline 3 is appropriate.

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

  Purpose4/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: 'Execute a task autonomously using Stagehand agent in hybrid mode.' The verb 'execute' and resource 'task' are specific, and the mention of 'autonomously' distinguishes it from more targeted sibling tools like stagehand_act or stagehand_extract, though it does not explicitly name alternatives.

  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 implies usage for autonomous, multi-step tasks through the word 'autonomously' and 'hybrid mode,' but it does not explicitly state when to use this tool over alternatives or provide exclusions. It lacks direct guidance on when not to use it or how it relates to sibling tools.

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

• stagehand_screenshotA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the screenshot is returned and saved as a resource, adding useful side-effect information. However, it lacks details on output format, resource naming, or whether an active page is required, leaving some behavioral ambiguity.

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

  Conciseness5/5

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

  The description is a single concise sentence of 12 words, immediately conveying the core function and side effect. Every word contributes value, with no redundant or vague filler.

  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 one parameter and no output schema, the description covers the essential action and the resource-saving behavior. It is complete enough for a basic screenshot tool, though it could clarify what 'return it' means (e.g., base64, URL) or that an active page context is required.

  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?

  The input schema has a single parameter 'name' with full description, achieving 100% schema description coverage. The tool description does not add additional meaning to the parameter beyond what the schema already provides, aligning with the baseline 3 for 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 'Capture a full-page screenshot and return it (and save as a resource)' clearly states the action (capture) and the resource (screenshot), while specifying 'full-page' to differentiate it from partial screenshots. It is distinct from sibling tools like stagehand_navigate or stagehand_extract, which serve different purposes.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, such as stagehand_observe or stagehand_demo_video. There is no mention of prerequisites (e.g., an active session or page) or exclusions, leaving the agent to infer the appropriate context.

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

• stagehand_session_createA
  3.7/5.0
  Behavior3/5

  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 default backend (local Playwright), the option to use cloud, and the side effect of setting the session as active. However, it does not mention error conditions, session reuse behavior, or return values.

  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, front-loaded with the action, and every sentence provides useful information without waste. It is appropriately sized for the tool's simplicity.

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

  Completeness3/5

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

  The tool has 4 optional parameters and no output schema. The description covers the core behavior and the main configuration option, and the schema covers all parameters. However, the description does not mention what the tool returns or the behavior when reusing a sessionId, which may be necessary for an agent to use the tool correctly in all cases.

  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?

  The input schema has 100% coverage, so the baseline is 3. The description explicitly mentions the cloud parameter and its default, but does not add meaning to browserWidth or browserHeight beyond the schema. Overall, the description adds minimal value over 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 uses a specific verb 'Create' and a specific resource 'browser session', and also states that the session is set as active. This clearly distinguishes it from sibling tools like stagehand_session_close, which is for closing sessions.

  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 implies usage for creating a session but does not explicitly state when to use this tool versus alternatives. It provides configuration guidance (local vs cloud) but no exclusion criteria or references to alternative tools.

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

• stagehand_extractA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states that extraction happens from the current page and uses an instruction, which implies a read-only operation, but it does not explicitly mention side effects, prerequisites, or output format. The description provides minimal but accurate 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.

  Conciseness5/5

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

  The description is a single, concise sentence that immediately conveys the tool's purpose and key requirement. There is no redundant information or filler.

  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 tool's simplicity (one parameter, no output schema), the description adequately communicates the core functionality and scope. It could clarify the return format further, but 'structured data or text' gives a sufficient general sense. The description is complete enough for an agent to make a basic selection decision.

  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?

  The schema already covers the parameter with 100% description coverage, including a detailed explanation and example. The tool description only adds the phrase 'using an instruction,' which does not meaningfully 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 function with a specific verb ('Extract'), the resource ('the current page'), and the outcome ('structured data or text'). This distinguishes it from sibling tools like stagehand_navigate or stagehand_screenshot.

  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 implies that the tool is used when you need to extract data from the current page, but it does not explicitly mention when to use it versus alternatives like stagehand_observe or stagehand_act. No exclusions or alternative tool names are provided.

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

• stagehand_scenarioA
  4/5.0
  Behavior3/5

  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 execution is agent-driven and returns structured pass/fail/blocked results per assert. Yet it does not mention potential side effects (e.g., navigation, state changes) or whether a session is required, leaving behavioral details partially undisclosed.

  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 concise sentences, front-loaded with the core action and outcome. Every word earns its place, with no redundant information.

  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?

  The schema covers parameter semantics thoroughly, and the description explains the tool's purpose and result format. However, it omits prerequisites like session usage and does not discuss how this relates to sibling tools, leaving some contextual gaps for a complex tool.

  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 the schema already documents all parameters in detail. The description adds no parameter-specific meaning beyond what the schema provides, matching the baseline of 3.

  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 executes a multi-step test scenario using the Stagehand agent, with specific arrange/act/assert structure. It distinguishes itself from sibling tools like stagehand_act (single action) and stagehand_navigate by emphasizing the multi-step scenario nature.

  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 implies usage for multi-step test scenarios and mentions returns per assert step, giving context. However, it does not explicitly state when to prefer this over alternative tools or exclude single-action cases, so it lacks direct exclusions but provides clear context.

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

• stagehand_session_closeA
  4/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It discloses two concrete actions (closing session and resetting context), which is more than a bare 'Close session'. However, it does not mention side effects like unsaved data loss, reversibility, or prerequisites, which would be expected for a destructive operation.

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

  Conciseness5/5

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

  The description is a single sentence that is concise and front-loaded with the action. Every word contributes to the meaning, with no unnecessary fluff.

  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 zero-parameter, no-output-schema tool, the description covers the essential action and context reset. It does not elaborate on cleanup or timing, but these are less critical given the tool's simplicity. It is mostly complete for an agent to understand when to invoke it.

  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?

  The tool has zero parameters, so the schema is empty. The description adds no parameter-specific details, but none are needed. Baseline for zero parameters is 4.

  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 ('Close') and resource ('current browser session'), and adds 'reset the active context' which clearly distinguishes it from sibling tools like navigate or extract. This is a precise statement of the tool's core function.

  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?

  No explicit when/when-not guidance or alternative mentions are included. The purpose implies it should be used to end a browser session, and sibling pair with stagehand_session_create suggests the opposite operation, but no direct usage context is given.

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

• stagehand_demo_videoA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It explains the full pipeline: actions run via stagehand.act with CDP screencast, narration via OpenAI TTS, and concatenation into final.mp4. It discloses the need for OPENAI_API_KEY and the prerequisite of an active session at the desired starting page. It does not mention potential side effects on the page state, but this is implied by running actions.

  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 four sentences, each contributing: purpose, process, prerequisite, and environment requirement. It is front-loaded with the main verb and resource, and every sentence adds operational detail without redundancy.

  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 tool's complexity (7 parameters, no output schema), the description provides a solid overview of the workflow and key constraints. It explains the pipeline, the active-session dependency, and the need for an API key. It does not explicitly describe the return value, but the outputDir parameter and mention of final.mp4 make the output clear. Minor gap: no mention of failure behavior or cleanup (though keepIntermediates parameter addresses intermediates).

  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?

  The schema provides 100% coverage with descriptions for all 7 parameters, so the description is not required to add much. The description adds context about how actions are processed (via stagehand.act with screencast) and the TTS generation, which indirectly explains the voice and narrate parameters, but it doesn't go beyond the schema's own descriptions. This meets the baseline for 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 opens with a specific verb and resource: 'Record a narrated demo video of a known-good Stagehand script.' It clearly differentiates from siblings like stagehand_act or stagehand_run_script by emphasizing narration, CDP screencast, and final mp4 concatenation.

  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 states a clear prerequisite: 'Uses the active Stagehand session — make sure the page is at the desired starting state before calling.' This gives context for when to call. It also indicates this is for 'known-good' scripts, implying not for exploratory use. However, it does not explicitly name alternative tools or state 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.

• stagehand_get_urlA
  4.3/5.0
  Behavior4/5

  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 the tool returns the full URL including query/fragment, which clarifies scope and implies a non-mutating read operation. It does not mention error behavior or prerequisites, but for a simple getter this is reasonable.

  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 sentence that is front-loaded with the verb and resource, and every word adds value. It is concise without sacrificing necessary detail about the URL format.

  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 tool has no parameters and no output schema, the description sufficiently describes the return value (full URL with query/fragment). It is complete for a trivial getter tool.

  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?

  The tool takes zero parameters, so the schema provides complete coverage. The baseline for no parameters is 4, and the description does not need to add parameter semantics because none exist.

  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 the specific verb 'Return' and identifies the exact resource: 'current page URL', with explicit detail that it includes query/fragment. This clearly distinguishes it from sibling tools like stagehand_navigate or stagehand_extract.

  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 implies usage from its simple getter nature, but it does not explicitly state when to use this tool over alternatives or mention any prerequisites (e.g., requiring an active page). No exclusions or alternative tool references are provided.

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

• agent_browser_runA
  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 the burden of behavioral disclosure. It adds key context: the tool is low-level, deterministic, and shares the browser session with Stagehand. However, it does not mention risks such as side effects on the browser state or that arbitrary commands could be destructive, which prevents a perfect score.

  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 three tightly written sentences. The action is front-loaded, and every sentence adds value: purpose, usage guidance, and session-sharing context. No redundant or filler content.

  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 one-parameter command runner, the description provides strong context: what it does, when to prefer it, and its relationship to Stagehand. It lacks explicit return/output or error behavior, but the presence of sibling agent_browser_help and the schema's examples mitigate this gap.

  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?

  The only parameter, 'args', has 100% schema description coverage with examples. The description doesn't add parameter-level details beyond the schema, 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.

  Purpose5/5

  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 ('Run a low-level browser command') and immediately differentiates from Stagehand by emphasizing 'precise, deterministic control'. It lists concrete use cases (element-by-ref interactions, DOM inspection, network debugging, JS evaluation), making the tool's scope clear.

  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 states when to use this tool over alternatives: 'Use over Stagehand when you need precise, deterministic control'. Also notes it shares the same browser session as Stagehand, implicitly warning against creating a separate session.

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

• stagehand_navigateA
  4.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden. It adds the useful localhost tunneling behavior, but does not disclose what happens after navigation (e.g., waits, error handling, return value). For a simple navigate tool this is acceptable, but there are gaps in behavioral 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 concise sentences that immediately state the purpose, then add usage constraints and a special-case note. No wasted words; 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?

  Given the tool's simplicity (one parameter, no output schema), the description covers the core use case, guidance on safe URLs, and the localhost tunneling detail. However, it omits behavior on page load failure or waiting, which would be useful but is not critical for such a basic operation.

  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?

  The schema has 100% coverage for the single 'url' parameter with a basic description. The tool description goes beyond the schema by adding practical constraints (URLs must be confirmed working) and special support for localhost URLs. This enriches the parameter semantics 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?

  The description starts with 'Navigate to a URL in the browser', which is a specific verb and resource. It clearly differentiates from siblings like stagehand_get_url (which reads the current URL) and stagehand_act (which performs actions). The purpose is unambiguous.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance: only use with URLs you are confident will work, otherwise fall back to https://google.com. It also mentions support for localhost URLs with automatic ngrok tunneling, providing a clear alternative and prerequisite context.

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

• agent_browser_helpA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral transparency. It clearly states the behavior: showing help and displaying available commands. As a help command with no parameters or side effects, this is sufficient disclosure, though it doesn't detail output format or any prerequisites.

  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, with the purpose front-loaded in the first sentence ('Show help for agent-browser'). It provides relevant context and usage without any extraneous text.

  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?

  For a zero-parameter tool with no output schema, the description is complete. It explains what the tool does, what it returns (available commands), and when to call it, which fully covers the agent's needs.

  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?

  The input schema has zero parameters, so the baseline for parameter semantics is 4. The description doesn't need to add parameter details, and it correctly makes no mention of parameters.

  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 with a specific verb+resource: 'Show help for agent-browser'. It distinguishes itself from sibling tools by describing agent-browser as a 'low-level browser automation CLI', which sets it apart from the stagehand tools and agent_browser_run.

  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 gives explicit usage guidance: 'Call this to see available commands.' It also implies a context difference by calling agent-browser 'low-level' and 'precise, deterministic control', suggesting it is for CLI-level help rather than higher-level stagehand operations, though it doesn't explicitly mention alternatives.

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

• stagehand_run_scriptA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses key behaviors: it returns {status, durationMs}, includes error and stack on failure, reuses the current session, and explains how bare imports resolve differently in inline vs path mode. It also notes that inline mode runs from a temp location, providing valuable runtime context beyond the schema.

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

  Conciseness5/5

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

  The description is well-structured into three logical sections: core behavior, return value, and usage guidance. Every sentence adds informative value without redundancy, making it efficient and easy to parse.

  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 the absence of an output schema, the description fully specifies the return format and explains edge cases like errors, import resolution, and mutual exclusivity. For a tool with three params and a nested object, it provides complete operational context.

  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 each parameter thoroughly described. The description adds a concise top-level constraint ('exactly one' of path/source) and summarizes the mode-specific difference in import resolution, adding practical meaning beyond the schema's already detailed field 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 states a specific verb and resource: 'Run a Stagehand script... against the current browser session,' and clarifies it executes a default export from defineScript. This clearly differentiates it from sibling tools like stagehand_navigate or stagehand_act by focusing on script execution.

  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 states when to use ('Use after authoring a script to validate it') and explains the advantage of reusing the live session with no separate setup. It also provides when-to-use guidance for inline 'source' vs 'path' modes, including the scenario where the caller lacks filesystem access.

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