Server Quality Checklist

Tool Scores

• session_navigateB
  3.1/5.0
  Behavior2/5

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

  Annotations provide only a title, so the description carries the full burden of behavioral disclosure. It states the action but does not mention whether navigation waits for page load, what happens to the current page state, whether an active session is required, or what the return behavior is.

  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 one concise sentence with no filler or redundancy. It front-loads the core action and resource, making it easy to parse.

  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?

  For a simple two-parameter tool with no output schema, the core call shape is covered. However, the lack of details about navigation completion, return value, and potential side effects leaves some ambiguity for an agent deciding whether the call succeeded.

  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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no deeper meaning beyond restating that navigation occurs; the parameters are already adequately documented.

  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 states a clear action ('Navigate') and resource ('browser session to a new URL'), making the tool's purpose immediately understandable. It is distinct from sibling tools like session_scroll or session_click, though it doesn't explicitly call out those differences.

  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?

  There is no guidance on when to use this tool versus alternatives such as session_scroll, session_eval, or session_wait. The description only states what it does, not the context or conditions that would make it the right choice.

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

• session_scrollA
  3.8/5.0
  Behavior3/5

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

  Annotations only provide a title, so the description carries the behavioral disclosure burden. It discloses direction and magnitude but does not mention side effects, whether it affects the current session page, or whether it preserves navigation history. Adequate for a benign viewport action, 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.

  Conciseness5/5

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

  A single sentence with no wasted words, front-loaded with the action and key unit of measurement. Every element 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 action with full parameter schema coverage and no output schema, the definition provides enough information for selection and invocation. It could explicitly state that scrolling applies to the current page of the given session, but the session_id parameter and sibling context make that inferable.

  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 already documents all three parameters with descriptions and defaults, so schema coverage is 100%. The description repeats 'up/down' and 'viewport-heights' but adds no new semantic detail beyond what the schema provides.

  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?

  States the exact operation (scroll), the resource (the page), and the unit of measurement (viewport-heights), making it clear what the tool does. It is also clearly distinct from sibling tools like session_navigate and session_click.

  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-to-use guidance or alternatives are named, but the action is self-descriptive and no sibling tool provides scrolling. The usage context is implied rather than explicitly stated.

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

• session_closeA
  4/5.0
  Behavior4/5

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

  With no annotations providing safety hints, the description carries the burden and discloses the key side effect (dropping the on-disk login snapshot for persistent sessions) and contrasts it with idle expiry. This is valuable transparency beyond the bare action.

  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 with no filler. The core action is front-loaded, and the second sentence adds a critical nuance 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?

  For a simple close operation with one parameter and no output schema, the description covers the action, the resource effect, and a key caveat. It does not mention error handling or return values, but these are not essential for a close 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?

  The single parameter session_id is fully described in the schema ('Session ID'), so the description adds no extra meaning. Schema coverage is 100%, so baseline 3 applies.

  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 a specific action (close) on a specific resource (browser session), and the note about persistent sessions distinguishes it from sibling tools like session_create or session_list. The verb and resource are unambiguous.

  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 (close when done with a session) but does not explicitly contrast with alternatives or give when-not conditions. The snapshot detail is more behavioral than usage guidance.

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

• session_inputA
  4/5.0
  Behavior2/5

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

  The description does not disclose side effects (e.g., triggering events, focus changes, return values, or potential errors). The 'events' parameter hints at behavior, but the description itself leaves the actual outcome unspecified. Since no annotations provide safety hints, this is a notable gap.

  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, well-formed sentence that leads with the action and specifies the target and source of the index. No extraneous 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?

  The tool is simple and the description covers the essential context: what it does, how to identify the element, and a prerequisite (session_state). The lack of behavioral details slightly detracts, but for a basic interaction tool the provided context is sufficient.

  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?

  All four parameters have clear, functional descriptions. The 'events' parameter is particularly well explained with both 'full' and default behaviors. The 'index' parameter correctly references '/state output' for provenance.

  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 action ('Type text into an input/textarea element') and specifies the targeting mechanism ('by its index'), which is distinct from sibling tools like session_click or session_drag.

  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 phrase 'from session_state output' explicitly tells the user where to obtain the index, implying a prerequisite step. It does not explicitly contrast with alternatives, but the purpose is sufficiently scoped for a focused tool.

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

• import_curlA
  4.1/5.0
  Behavior4/5

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

  No annotations exist, so the description carries full responsibility. It discloses that the tool produces a live session_id, that it uses the cookies from the pasted request, and that it 'sits' on the copied request's URL. It also reveals supported copy flavors and the absence of a password requirement. It does not mention side effects such as overwriting an existing session or any network implications, but the core behavior is thoroughly explained.

  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 four sentences, each adding distinct information: the interactive workflow, the output, and supported formats. It is front-loaded with the core purpose. There is no wasted wording, though the sequence of steps (DevTools → Network → right-click → Copy as cURL) could be condensed without losing meaning.

  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 two-parameter tool with no output schema, the description provides enough operational context: where the input comes from, what the output is, and that the session inherits the URL. It lacks error scenarios or explicit limitations, but given the tool's simplicity, the description is otherwise 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?

  Schema description coverage is 100%, so the baseline is 3. The description adds workflow context for the `curl` parameter (how the human obtains it and that it parses in three formats), which slightly enhances the schema. It offers no additional meaning for `use_proxy`, which the schema already describes clearly. Overall, the description adds some value but does not go far 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 states a specific verb and resource: 'Import login state from a real browser in one paste.' It explains the output (a live session_id with cookies, on the copied URL). This distinguishes it from sibling tools like session_create, session_cookies, or session_import by referencing the cURL paste workflow and 'no password or second login needed'.

  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?

  Clear usage context is provided: the human authenticates in their own Chrome first and then pastes a cURL command, avoiding re-login or CAPTCHA. The description explains exactly which precondition is required (single authentication) and that it works with bash, PowerShell, and cmd copy flavors. It does not explicitly name sibling alternatives to choose from, but the workflow guidance is unambiguous.

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

• fetchA
  4.2/5.0
  Behavior4/5

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

  Annotations only carry readOnlyHint=true; the description adds meaningful behavior: static pages are served over plain HTTP (~100ms), JS pages get a full browser, and render_tier controls auto/http/obscura behavior. There is no contradiction with the read-only hint.

  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 dense sentences, front-loaded with the core action and output format, followed by usage scope and the key rendering decision. Every sentence earns its place; the render_tier sentence adds the 'refuses the upgrade' nuance rather than repeating the schema.

  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 12-parameter tool with no output schema, the description provides selection context, output format, and the tiering model, while the input schema carries the remaining parameter detail. It does not summarize advanced features like sanitize, xhr capture, or tls_fingerprint, but the schema coverage compensates.

  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 baseline is 3. The description primarily supplements render_tier with contextual performance notes and the 'refuses the upgrade' behavior; the other parameters are already fully documented in the input 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 opens with a specific verb and resource: 'Fetch a webpage and return clean markdown/html/text.' It also scopes the tool to READ-only web content retrieval, which separates it from sibling interaction tools like click, session_navigate, or download.

  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 gives an explicit trigger: 'Use whenever the agent needs to READ any web page', and lists concrete cases (blogs, docs, SPAs, Cloudflare-protected sites). It also advises on rendering mode (http for static, browser for JS), but does not explicitly name alternatives or when-not conditions.

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

• session_dragA
  4.2/5.0
  Behavior4/5

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

  Annotations only provide a title, so the description carries the full behavioral burden. It discloses the sequence of events (press, interpolated moves, release), the timing parameters, and the specific widgets it affects. It does not mention whether it blocks or returns after sending events, but for a drag operation this is a reasonable level of 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?

  A single, well-structured sentence that front-loads the main action and then explains the mechanism. Every clause adds value; there is no redundancy 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?

  For a 5-parameter tool with no output schema, the description covers the behavior, timing, and target types adequately. It does not explain return values (likely none) or session prerequisites, but these are implicitly covered by the schema and the tool's nature. It is complete enough for an agent to call 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 coverage is 100%, so all parameters are already documented in the input schema with descriptions. The tool description essentially restates the flow (press at from, steps interpolated, release at to) but adds no new semantic meaning beyond the schema. The baseline of 3 applies since the schema handles the heavy lifting.

  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 a specific action (drag the mouse) with the resource (viewport positions) and details the mechanism (press, interpolated moves, release). It also distinguishes the tool by noting it moves AMarker-style drag targets and canvas selections, separating it from generic click 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?

  The description implies usage for dragging operations that require mouse movement tracking, but it does not explicitly mention when to avoid it or name alternatives. It gives clear context about the type of targets it works on, which helps an agent decide, though not explicitly.

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

• session_screenshotA
  4.2/5.0
  Behavior4/5

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

  Annotations only provide a title, so the description carries the behavioral burden. It adds valuable detail: the screenshot reflects the current DOM including mutations, is rendered by the built-in renderer, and returns a structured base64 payload. It does not explicitly state non-mutating behavior, but the action itself makes that clear.

  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 with no filler: the first states the core action and DOM context, the second clarifies default sizing and pairing, and the third gives the return shape. Information is front-loaded and 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 six parameters and no output schema, the description appropriately covers the non-obvious behavior (mutations included, built-in renderer, default sizing) and supplies the return object shape. Remaining parameter details are already in the schema; error conditions and format caveats are not addressed, but are not critical for invocation.

  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 every parameter already has a clear description, including width/height defaults and selector behavior. The description reinforces the viewport default and adds the session_viewport pairing, but adds little semantic meaning 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?

  States a specific operation: capture the session's current DOM state as a base64 PNG via the built-in renderer, explicitly including mutations from clicks/evals. This clearly differentiates it from siblings like session_viewport (viewport metadata) and session_state (state inspection).

  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: use it to capture the live, mutated DOM, and pair it with session_viewport to evaluate responsive layout. It does not enumerate exclusions or alternative screenshot tools, but no sibling directly competes, 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.

• session_stateA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only, and the description adds useful behavioral detail: it returns compact text with [N] indexes rather than a full page snapshot. This clarifies what the agent can expect from the response and how it should be used.

  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 with no filler. The first identifies the resource, the second describes the return format and purpose. Every word contributes to an agent's ability to use the tool correctly.

  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 read-only tool with one parameter and no output schema, the description covers the essential behavior and return format. It is complete enough for correct invocation, though it could optionally mention what happens when the page is not loaded or has no interactive elements.

  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 fully documents the only parameter, session_id, with a 'Session ID' description. The tool description does not add extra meaning about the parameter, but since schema coverage is 100%, no additional compensation is needed. This is the appropriate baseline.

  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 ('Get'), a specific resource ('current page state as an indexed list of interactive elements'), and explicitly says the output is for use with click/input tools. This clearly differentiates it from sibling tools like session_navigate or session_scroll.

  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 clear context for use: it returns indexed elements that are consumed by click/input tools, implying this should be called before interaction. It does not explicitly name alternatives or exclusions, but the purpose is clear enough for an agent to select it appropriately.

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

• session_click_xyA
  4.3/5.0
  Behavior3/5

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

  Annotations do not include readOnly or destructive hints, so the description carries the burden. It mentions 'real mouse events' but does not explicitly warn about potential side effects like navigation or state changes. The action is inherently interactive but not fully disclosed.

  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 succinct, consisting of two sentences that cover the action, method, use case, and click_count behavior. Every sentence adds value without redundancy or unnecessary detail.

  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?

  With all parameters documented in the schema and no output schema, the description provides sufficient context: what the tool does, when to use it, and how click_count behaves. There is no missing critical information 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.

  Parameters3/5

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

  The schema covers all 5 parameters with descriptions (x, y, button, session_id, click_count), which is 100% coverage. The description adds no extra parameter semantics 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.

  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 (click at viewport coordinates), the method (real mouse events), and the specific use case (canvas/map surfaces without a DOM element). It is distinct from sibling tools like session_click, which likely target elements.

  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 explicitly says when to use this tool: 'For canvas/map surfaces with no DOM element to index.' This provides clear guidance on when it is appropriate versus other click tools, and also explains the click_count behavior for double-clicks.

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

• session_cloneA
  4.3/5.0
  Behavior4/5

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

  Annotations only include a title, so the description carries the full burden. It discloses that the source session stays untouched (non-destructive) and that the new session carries the full login state. This is adequate for a clone operation, though it does not mention any potential side effects such as resource usage or failure modes.

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

  Conciseness5/5

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

  Three sentences, each earning its place: the first states purpose and contents, the second adds the key safety note, and the third provides usage and return format. Purpose is front-loaded, and there is no fluff.

  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 a single parameter, no output schema, and no annotations, the description covers purpose, behavior, usage scenarios, and return format. An agent has everything needed to decide when and how to call 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 coverage is 100% for the single parameter, with a clear description ('Session ID to derive from (stays alive and untouched)'). The tool description reiterates that the source is untouched but adds no 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 states a specific verb 'derive' and resource 'browser session', enumerates what is carried (cookies, localStorage/sessionStorage, viewport, etc.), and explicitly notes the source is untouched. This clearly distinguishes it from sibling tools like session_cookies or session_storage, which handle individual aspects.

  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 gives explicit use cases: 'snapshot a logged-in state before risky actions' or 'run the same login in parallel tabs.' While it does not name alternatives or provide explicit when-not guidance, the context makes it obvious that this tool is for whole-session cloning, whereas siblings are for parts. Strong guidance overall.

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

• session_cookiesA
  4.3/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description discloses the return format, that cookies are scoped to the page's URL, and that the output round-trips with session_create's cookies field. This gives an agent practical behavioral expectations for a read-only export 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?

  Three tight sentences: the first states purpose and output format, the second gives the concrete use case, and the third reinforces the round-trip contract. Every sentence earns its place, with no filler.

  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 simple one-parameter read-only tool, the description is complete: it explains what is exported, the format, the URL scoping, and how to replay the cookies later. The lack of an output schema is mitigated because the return shape is explicitly described.

  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 fully documents session_id with 'Session ID', so the schema carries the parameter-semantics burden. The description does not add detail about how session_id affects the cookie export, so it stays at the baseline.

  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 names a specific verb ('Export'), a precise resource ('the session's current cookies'), and the exact output shape ('["name=value", ...]') for the page's URL. This clearly distinguishes it from broader siblings like session_export or session_state.

  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 explicitly states when to use the tool: 'Use to persist a logged-in session and replay it later via session_create with cookies.' It points to the relevant sibling session_create, though it does not explicitly mention when not to use it or contrast it with session_export.

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

• session_dialogA
  4.3/5.0
  Behavior4/5

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

  Discloses key behavioral traits: dialogs never block the page, each is auto-answered by default and logged into session_console at level 'dialog'. It explains the effects of accept (confirm() returns true, prompt() returns prompt_text) and dismiss (restores default), including the note that alert is always logged and never blocking. Since annotations provide no behavioral hints, the description carries the full burden and handles it well.

  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 concise yet comprehensive, front-loading the purpose in the first sentence and then efficiently explaining the non-blocking behavior and action effects in the following sentences. Each sentence earns its place without redundancy or 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?

  Given the tool's moderate complexity (3 parameters, no output schema), the description covers the main actions, their effects, the non-blocking nature, and logging behavior. It even describes the return structure for 'list' despite the lack of an output schema. While it doesn't mention error conditions or persistence across sessions, these are minor 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.

  Parameters4/5

  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 value beyond the schema: it specifies the output structure for 'list' ({policy, prompt_text, dialogs}) and clarifies that prompt_text falls back to the call's default argument when omitted, which the schema only implies. This extra semantic detail improves parameter understanding.

  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?

  States a specific verb ('inspect or flip') with a clear resource ('session's dialog policy') for window.alert/confirm/prompt. It distinguishes itself from sibling session_* tools by focusing on dialog policy control, leaving no ambiguity about its function.

  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?

  Implicitly conveys when to use the tool: whenever you need to inspect or change how dialogs are auto-answered. It does not explicitly name alternatives, but given the tool's unique scope, no exclusions are necessary. The action semantics (list/accept/dismiss) guide the agent on correct usage.

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

• session_exportA
  4.3/5.0
  Behavior4/5

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

  Annotations mark this as readOnlyHint=true, and the description aligns with that by describing an export operation. It adds valuable behavioral detail beyond the schema: the bash output replays actions against a fresh session, is meant to be handed to a shell or cron, and consumes zero model tokens. No side effects or destructive actions are implied.

  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 carefully structured sentences: the first states the core function, the second explains both format options and their use cases. Every clause earns its place, and the most important decision (which format) is presented immediately after the purpose.

  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 simple two-parameter export tool with read-only annotations and no output schema, this description is complete. It covers both possible formats, their outputs, and a concrete use case. An agent knows exactly what to expect from the tool and can invoke it correctly with just session_id.

  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 baseline is 3. The description adds a little extra context (e.g., 'navigate/click/input/scroll/eval' and 'zero model tokens'), but the core parameter meanings are already fully documented in the schema. The added value does not push it above baseline.

  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 leads with a specific verb and resource: 'Export a browser session's recorded action log.' It then differentiates the two output formats (bash replay script vs. jsonl raw log), which clearly separates it from sibling session tools like session_list or session_state. 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 Guidelines4/5

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

  The description gives clear usage context: format 'bash' is explicitly tied to creating a runnable curl script for shell/cron with zero model tokens, and format 'jsonl' is tied to getting the raw per-line log. It doesn't explicitly name sibling alternatives or exclusions, but the use cases are concrete and imply when this tool is appropriate.

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

• session_storageA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description reinforces this with 'Snapshot' while adding useful behavioral context: the output structure, the current-origin scope, and the timing warning about session idle timeout. It doesn't discuss failure modes or size limits, but the read-only annotation lowers the burden.

  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, each earning its place: the first states what the tool snapshots and returns, the second explains the restoration workflow, and the third gives the timing constraint. The purpose is front-loaded and there is no filler.

  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?

  Although there is no output schema, the description explicitly provides the return shape as {url, local_storage, session_storage}. It also explains how the output is consumed by session_create, what origin it applies to, and when to call it, making the description complete for an agent to invoke 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?

  The schema already documents the only parameter, session_id, at 100% coverage. The description adds no additional meaning about session_id semantics or valid values, so it stays at 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 states a specific verb ('Snapshot') and a precise resource ('the session's localStorage/sessionStorage for the current origin'), and it even names the exact return shape. It also separates this tool's role from cookie handling by explaining it captures the half of login state that cookies can't carry.

  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 clear usage context: call it before the session idles out, and feed the result into session_create's 'storage' field to restore logged-in state. It implies a complementary relationship with cookies but never explicitly names session_cookies as the cookie-handling alternative, so it stops short of an explicit when-to-use vs when-not-to-use statement.

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

• session_viewportA
  4.3/5.0
  Behavior4/5

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

  With no readOnlyHint or destructiveHint annotations, the description carries the burden, and it does well by disclosing side effects beyond a simple 'set': scripts observe innerWidth/innerHeight movement, media queries re-evaluate, element rects re-anchor, and mobile=true flips matchMedia pointer/hover answers. It also explains the retain-current-value behavior for omitted dimensions. It doesn't discuss auth or rate limits, but those aren't critical for a viewport setter.

  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 compact: two sentences with a front-loaded purpose, followed by a concise list of behavioral effects and a closing usage note. Every phrase adds value, and there is no filler or repetition beyond what the schema already covers.

  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 viewport mutation tool with no output schema, the description fully explains what happens when invoked, including the mobile flag's effect and the default for omitted width/height. Combined with the detailed schema, an agent has everything needed to decide whether and how to call the 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?

  The input schema already has 100% parameter descriptions, including 'omit to keep the current width/height' and mobile matchMedia behavior. The description largely restates these details ('Omitted width/height keeps the current value', 'mobile=true flips pointer/hover matchMedia answers to coarse/none'), adding little 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 opens with a specific verb and resource: 'Set the session's viewport (device emulation).' It goes beyond a vague label by enumerating concrete consequences (innerWidth/innerHeight change, media queries re-evaluate, element rects re-anchor), which clearly distinguishes it from sibling tools like session_navigate or session_scroll.

  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 establishes clear context: call this to emulate a device viewport for the session. It also gives a practical usage note ('Omitted width/height keeps the current value'). It doesn't explicitly state when not to use it or mention alternatives, but no sibling tool offers viewport control, so the context is sufficiently clear.

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

• downloadA
  4.4/5.0
  Behavior4/5

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

  Annotations provide only a title, so the description carries the full burden. It discloses streaming (no memory buffering), integrity hash, resume capability, and filename resolution order. It does not mention auth needs, error handling, or overwrite behavior, but the key behavioral traits are covered.

  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 with zero fluff. The first sentence front-loads the core function and key features; the second provides usage guidance and filename resolution. Every clause 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 tool with 5 params and no output schema, the description is nearly complete. It explains streaming, integrity, resume, filename rules, and intended use cases. It omits what the agent receives back (e.g., file path or status) and does not mention network failure handling, but these are minor given the richness already present.

  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%, so the baseline is 3. The description adds value by explaining filename resolution precedence (explicit → Content-Disposition → URL tail), which clarifies the 'filename' parameter beyond the schema. Other params like 'resume' and 'use_proxy' are adequately described in the schema and need no extra explanation.

  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 ('download'), a clear resource (file over HTTP(S)), and distinct behaviors (streaming to disk, SHA-256 hash, resume). It differentiates itself from siblings by explicitly contrasting with reading text content, making it unambiguous which tool to choose.

  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 explicitly states when to use it ('Use for binaries, archives, datasets, documents') and implicitly when not ('not its text content read'). It provides a clear use-case boundary but does not name a specific alternative tool like 'fetch', so it stops short of full explicit routing.

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

• render_markdownA
  4.5/5.0
  Behavior5/5

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

  Annotations are minimal (only a title), so the description carries the full burden. It extensively discloses behavior: determinism (same input, same bytes, sha256 in receipt), offline shell with no fonts/scripts, degradation of broken diagrams to visible code blocks, self-repair of unhonored routes with disclosure, view tabs with interactive behavior, a programmatic API (window.agxViewer), and session integration with viewport acceptance. It also clarifies that the audit never changes artifact bytes. No contradictions with annotations.

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

  Conciseness3/5

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

  The description is a single dense paragraph covering many features (diagrams, views, API, session, audit). It is front-loaded with the core purpose, but the sheer length and lack of structural breaks make it harder to scan. Every sentence carries information, but the density reduces conciseness; a more structured layout would improve it.

  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's complexity (multiple feature families: diagram rendering, views, API, session, quality audit) and no output schema, the description thoroughly explains what the receipt contains (sha256, composition grades, diagnostics, repairs, views) and how the artifact behaves (degradation, repair, viewport acceptance). An agent can correctly invoke the tool and interpret results without additional documentation.

  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 detailed parameter descriptions, so the baseline is 3. The description adds meaningful context beyond the schema: it explains that theme and preset are orthogonal, that colors bake at generation time, that quality affects severity ratings only, and that session_id enables viewport verification. This extra semantics justifies a 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 opens with a clear, specific statement: 'Render a markdown document into a deterministic, self-contained HTML artifact - the document layer, so the agent never writes HTML by hand.' This names the verb (render), resource (markdown document), and output (HTML artifact), and distinguishes the tool from manual HTML authoring. It is unique among siblings, none of which perform rendering.

  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 sets usage context: use this to produce HTML from markdown instead of writing HTML manually, and use session_id to load into a live session for verification. It also gives clear input guidelines (Mermaid must be translated to archify JSON; only archify JSON is accepted). However, it does not explicitly name alternative tools or exclusions, so it falls short of a perfect 5.

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

• searchA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnlyHint, the description discloses important runtime traits: results are aggregated and deduped, fetch_top retrieves full content, engines filter by name with an error on invalid names, time_range is only honored by dated-result engines, and engine_errors reports per-engine failures like CAPTCHA suspension. This is material behavior an agent must know and it goes well beyond the annotation.

  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 dense paragraph of about 130 words. It front-loads the primary purpose and usage in the first two sentences, then covers notable behaviors. Every sentence adds information, but the engine-filter phrasing is slightly awkward and could be clearer as a list.

  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 7 parameters, no output schema, and no other structured behavioral annotations, the description gives enough to invoke and interpret results reasonably: it names the engines, mentions engine_errors, tells the agent about time_range and image search. It does not mention result schema shapes or what happens when fetch_top requests fail, but these are minor for a well-known search 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?

  Schema coverage is 100%, so the baseline is 3. The description adds genuine semantics on top of the schema: engines as an array filter with error behavior and /doctor listing, time_range semantics about ignoring vs. honoring based on engine support, and the purpose of fetch_top. This raises it to 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 states a specific verb ('Search'), a concrete resource (the web via Baidu/Bing/Sogou/WeChat/Google), and the distinguishing behavior (aggregation, deduping, optional content fetch, image search). It clearly differentiates from the sibling browser-session and URL-level tools (fetch, download, etc.) so an agent can select it for discovery rather than retrieval of a known URL.

  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?

  'Use when the agent needs to FIND information online - replaces a search API' is an explicit trigger instruction. It gives good context but does not list what it is not for (e.g., fetching a specific known URL, which would fall to fetch), so it misses a full when-not/alternative comparison.

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

• session_createA
  4.6/5.0
  Behavior4/5

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

  With no readOnly/destructive annotations, the description carries the burden of transparency. It explains the session lifecycle (idle eviction, keepalive, persistent revival) and the storage-side effects (snapshot of cookies and web storage). It doesn't explicitly warn that the session is a server resource needing cleanup, but the session_close sibling and the described lifetime make this reasonably clear.

  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 dense but focused, with a clear main purpose sentence followed by a usage condition and parameter summaries. Minor redundancy between keepalive and persistent is acceptable given the complexity. No filler or irrelevant content is present.

  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 10-parameter tool with no output schema, the description covers the operational context thoroughly: when to use it, how login state is handled, lifetime controls, persistence semantics, and recovery behavior. It even notes the return value (session_id) and round-trip relationships with sibling session_cookies/session_storage tools, making the tool's role in the broader set clear.

  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?

  All 10 parameters have detailed schema descriptions that explain not only what each parameter does but why it matters (e.g., width pinned for consistent layout, persistent for storageState-style recovery). The tool description adds further context on login-state injection and round-trip storage, exceeding 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 clearly states the tool creates a persistent interactive browser session for multi-step interaction, and explicitly contrasts it with read-once operations. It names concrete use cases (login flows, forms, pagination, click-through) and the resource produced (session_id), making the purpose unmistakable.

  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 guidance to use when the agent must interact with a page rather than read it once, which distinguishes it from read-only tools. It doesn't name specific alternatives like fetch or search, but the contrast is clear enough and the parameter explanations cover when to adjust TTL, keepalive, and persistence.

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

• session_evalA
  4.6/5.0
  Behavior4/5

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

  Annotations provide no behavioral hints, so the description carries the full burden. It discloses persistence, navigation side effects, and exception reporting. Does not explicitly warn about destructive potential, but execution context is clearly described.

  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 with zero redundancy. Front-loads the main purpose, then adds behavioral caveats and exception handling. 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 powerful arbitrary-execution tool with no output schema and minimal annotations, the description covers persistence, navigation, and error reporting. It lacks mention of return value format or potential async behavior, but these are minor for the intended use case.

  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%, so baseline is 3. The description adds context about how the 'script' parameter behaves (runs in current page, persists) beyond the bare schema description, though it does not detail return value or formatting specifics.

  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 it executes JavaScript in a live session and returns the result, with a specific verb and resource. Explicitly contrasts with the sibling 'eval' tool, making differentiation immediate.

  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?

  Directly names the alternative stateless eval tool and explains the key difference: persistence vs. throwaway page. This gives agents a clear decision rule for when to use session_eval over eval.

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

• session_networkA
  4.6/5.0
  Behavior5/5

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

  Annotations only declare readOnlyHint=true. The description adds substantial behavioral detail: how media elements not fetched are merged as candidates, the via='network' vs 'dom' distinction, iframe handling, and default compact rows. No contradiction.

  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 dense but every sentence contributes: purpose, filter semantics, candidate behavior, default output, and a practical tip. It is front-loaded with the core action and scopes quickly, though slightly long.

  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 5-parameter tool with no output schema, the description covers usage, filter behavior, return format, and edge cases (decoys, iframes). An agent has everything needed to call it correctly.

  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 detailed parameter descriptions, so baseline is 3. The description adds extra meaning, especially for 'filter' (explaining decoys and candidate merging) and 'include_bodies' (the page's API face). This elevates it beyond 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?

  States a specific verb ('Read') and resource ('session's network request log'), with clear scope. Distinguishes from siblings by its focus on network traffic, which is unique among the session_* tools, and explains the 'filter' option for media extraction.

  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 when-to-use guidance: navigate first, let it load, then call, and explains the media filter for getting real video links. Does not explicitly name alternatives or exclusions, but the context makes appropriate usage obvious.

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

• cacheA
  4.7/5.0
  Behavior4/5

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

  Annotations only provide readOnlyHint=false, so the description carries the burden of disclosing mutating behavior; it does by saying 'clear to delete rows.' It also adds useful context about locality, latency, and full-text search behavior (Chinese substrings and English words), though it does not detail destructive edge cases or return behavior in depth.

  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 with no filler. It front-loads the core resource and action, then delivers performance guidance and mode routing in a logical progression.

  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 9-parameter, zero-required tool with no output schema, the description supplies the essential decision-making context: what data is cached, when to prefer it, and how to invoke each major mode. The remaining parameters (url, since_hours, limit, kind) are fully described in the schema, so nothing needed for correct invocation is missing.

  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%, so the baseline is 3, but the description adds real semantics by mapping query/get/stats/clear to their intended uses and by noting a capability constraint ('works for Chinese substrings and English words'). This goes beyond what the parameter descriptions already state.

  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: 'Query the LOCAL CACHE of every page this server has fetched and every search it has run.' It clearly defines the tool's scope and differentiates it from re-fetching or re-searching, making its purpose 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?

  It explicitly says 'Check here BEFORE re-fetching or re-searching' and quantifies the trade-off ('a hit is instant and free while a fresh fetch costs 5-60s'). This gives an agent a concrete rule for when to use the cache instead of the sibling fetch/search tools, and it also routes to the correct subcommand (query/get/stats/clear).

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

• session_clickA
  4.7/5.0
  Behavior5/5

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

  With no readOnly/destructive annotations, the description carries the full burden and does so thoroughly. It discloses that the click may navigate the session, that the returned url/text_after reflect the post-action page, and that session state (cookies, localStorage, globals) persists. This goes well beyond a simple 'clicks an element' and prepares the agent for 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.

  Conciseness5/5

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

  The description is compact yet information-dense. The first sentence establishes the core action and mechanism, the second covers navigation side effects and state persistence, and the final sentence warns about stale indexes. Every sentence earns its place with no fluff 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?

  For a fairly simple two-parameter tool with no output schema, the description covers all necessary aspects: what it clicks, how it does it, side effects on navigation and state, and how to obtain valid indexes. It even hints at the output fields (url/text_after), satisfying the gap left by the missing output schema.

  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?

  Both parameters are already described in the schema with 100% coverage, so the baseline is 3. The description adds meaningful context for `index` by explicitly tying it to the most recent session_state output and warning that indexes become stale after navigation, which is valuable operational guidance not present in 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 identifies a specific action – clicking an interactive element by index within a live browser session – and distinguishes it from coordinate-based alternatives like session_click_xy. It also specifies that it scrolls the element into view and fires a DOM click, making the tool's function 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?

  It implies usage after calling session_state, since indexes come from that output, and warns to re-list after navigation. It also notes this applies to a live session. However, it does not explicitly name an alternative tool (e.g., session_click_xy for coordinates) or state when not to use it, so guidance is clear but not exhaustive.

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

• session_consoleA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description discloses the ring buffer size (500 entries), sources captured (scripts, clicks, evals, navigation), ordering (newest last), and filter behavior. This is comprehensive and adds significant value over the annotation alone.

  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 compact—three sentences pack the core action, output format, buffer limits, sources, filters, and a practical usage tip. Every sentence earns its place, with the main purpose front-loaded.

  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, the description provides the full return shape. It also covers buffer limits, capture sources, ordering, and all filter parameters. There is no missing information an agent would need to call this tool correctly, making it contextually 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%, so baseline is 3. The description adds context by clarifying filter semantics (e.g., 'level (exact)' and 'limit (most recent N matches)') and shows how the output structure includes 'matched' count, which helps the agent use the parameters effectively 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 states a specific verb ('Read') and resource ('session's recent page console output'), and details the exact return structure. It clearly differentiates from sibling tools like session_state or session_network by focusing on console messages, making its purpose 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?

  It provides a clear use case ('The fastest way to see WHY a page misbehaves') and explains the capture scope, but it does not explicitly contrast with alternatives or state when not to use it. The guidance is helpful but lacks explicit exclusions or sibling comparisons.

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

• session_listA
  4.7/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds meaningful context about live sessions, idle age, auto-eviction, and the 8-minute idle limit, which helps the agent understand the lifecycle without contradicting annotations.

  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 purposeful sentences. The first states the core function and output fields, and the second gives usage guidance and expiration policy. No filler or redundancy.

  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, read-only list tool with no output schema, the description is complete. It tells the agent what the tool returns (idle age, eviction time), when to use it, and a key behavioral constraint (8-minute idle expiry). Nothing essential is missing.

  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 trivially complete at 100% coverage. Baseline for 0 params is 4; the description adds no parameter details because none are needed, and that 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 uses a specific verb ('List') and resource ('live browser sessions') and clearly states what information is returned ('idle age and the time left before auto-eviction'). It distinguishes itself from session_create by framing the tool as a discovery mechanism for reuse.

  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 the tool: 'discover a session to reuse instead of creating a new one'. It also provides a critical operational condition ('sessions expire after 8 min idle'), giving the agent a clear decision rule.

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

• session_waitA
  4.7/5.0
  Behavior5/5

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

  The annotations only declare readOnlyHint=true, so the description carries the behavioral disclosure burden. It adds substantial value: the page event loop keeps running, the tool returns {matched, elapsed_ms, detail}, errors name the selector/predicate on timeout, and exactly one of selector/predicate must be provided. This goes well beyond what the annotation or schema exposes.

  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 sentences with no wasted words. It front-loads the core behavior, then adds a brief usage example, return shape, and error behavior. Every sentence contributes distinct information needed to call the tool correctly.

  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?

  There is no output schema, so the description correctly explains the return value and error format. It also covers the key behavioral nuance (event loop keeps running), the mutual exclusion requirement, and timeout behavior. Combined with the fully described parameters, an agent has everything needed to invoke this tool correctly.

  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 already documents all four parameters with 100% coverage, so the baseline is 3. The description adds the important mutual-exclusion constraint 'Exactly one of selector/predicate,' which is not encoded in the schema, plus contextual behavior about error messages. This is meaningful added semantic value beyond the parameter 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 opens with a specific verb and resource: 'Wait until a CSS selector matches or a JS predicate turns truthy, with a timeout.' It clearly distinguishes the tool from navigation, scrolling, and other session tools by focusing exclusively on waiting, and it even provides a concrete usage example. This makes the tool's purpose unmistakable even without examining the schema.

  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 explicitly positions the tool as a replacement for blind sleeps for async content and gives a workflow: 'navigate, session_wait for ".price-card", then click/read.' It does not name sibling alternatives or state when not to use it, but the context is clear enough for a capable agent to select it appropriately.

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

• clickA
  4.8/5.0
  Behavior5/5

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

  Discloses side effects: creates a fresh stateless context, may trigger navigation, and returns clicked:false when no match. Since annotations provide no safety hints, the description carries the transparency burden and meets it.

  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?

  Description is dense but well-organized with dashes, covering all key aspects in two sentences. Slightly verbose but not redundant.

  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?

  Covers the essential context: stateless behavior, navigation possibility, failure case, and the alternative tool. No output schema exists, but the description mentions the failure return value.

  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 descriptions for all three parameters. The description adds the 'first CSS-selector match' behavior and relates wait_secs to the load-and-click sequence, going slightly 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?

  Clearly states it clicks an element on a one-off page, specifying the fresh context, wait, and selector matching. Distinguishes from session_click by contrasting one-off vs shared page.

  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 provides an alternative tool (session_click) for multi-step shared-page interactions, and describes when navigation may occur, giving concrete usage context.

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

• evalA
  4.9/5.0
  Behavior5/5

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

  The annotations provide only a title, so the description carries the full burden. It discloses all key behaviors: fresh browser context, optional wait, async/Promise support, the exact return shape {url, result}, and the fact that navigation is drained and reflected. It also states statelessness explicitly. There is no contradiction with the title annotation, and the description goes far beyond what annotations imply.

  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, tightly structured paragraph that leads with the core action and then covers the key details in logical order: context, wait, script, return, and navigation behavior. Every sentence adds essential information with no redundancy. It is front-loaded with the purpose and differentiator, making it easy for an agent to scan quickly.

  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?

  The tool has no output schema, so the description must explain the return value, which it does ({url, result}). It covers all parameters, side effects (navigation), statelessness, and the alternative when state is needed. For a tool of this complexity, nothing essential is missing; an agent has everything needed to call it correctly and interpret the response.

  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?

  While the schema already describes each parameter (100% coverage), the description adds meaningful semantic value: it clarifies how wait_secs is used (optional, time to settle), that script supports async/Promise, and the return format. It also explains the interaction between script and the returned url (navigation). This goes beyond mere schema definitions, though not to the extent of a 5, since the schema already covers the basics.

  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 core action: 'Execute JavaScript on a one-off page', followed by a precise breakdown of the flow (loads url, waits optionally, evaluates script, returns {url, result}). It also explicitly differentiates from the sibling tool session_eval by highlighting the stateless vs stateful distinction. This leaves no ambiguity about what the tool does or how it differs from alternatives.

  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 explicitly states when to use this tool (for one-off, stateless evaluations) and when not to use it, directly naming the alternative: 'when the script needs prior page state or a login, use session_eval.' It also explains the behavior around script-driven navigation, giving clear context for invocation. This is exemplary guidance for an agent to choose correctly.

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