Server Quality Checklist

Tool Scores

• browserC
  2.9/5.0
  Behavior2/5

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

  Only one behavioral trait disclosed: 'automatically starts browser on first use'. With no annotations, description should provide more behavioral details (e.g., lifecycle, side effects of actions like stop) but does not.

  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 very short (two sentences) and front-loaded with the main purpose. It is appropriately sized for the level of detail but could be slightly more informative without losing conciseness.

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

  Completeness2/5

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

  For a tool with 9 parameters and 12 actions, the description is insufficient. It does not explain return values, list all actions, or provide usage examples. No output schema exists to compensate.

  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 described in the schema. Description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 applies.

  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?

  Description clearly states it's the main browser control tool and that actions are selected via 'action' parameter. However, it does not differentiate from sibling tools like browser_click, which could cause confusion about when to use this tool versus those.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool vs alternatives. The description lacks any context about prerequisites, when to choose specific actions, or how to decide between this main tool and sibling tools.

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

• browser_clickA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions the prerequisite but does not disclose behavioral traits such as success/failure outcomes, navigation waits, or error handling. This is insufficient for a tool with no 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 sentences with no wasted words. The first sentence states the primary action, and the second provides the prerequisite. Efficiently front-loaded.

  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?

  Given the simple tool (2 parameters, no output schema), the description is adequate for basic usage. It covers the prerequisite and action. However, lacks details on what happens after the click (e.g., page navigation, errors), which could be important for an agent.

  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 covers both parameters with descriptions (100% coverage). The description adds no additional meaning beyond the schema, such as explaining the format of the ref or page_id. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool clicks a page element using an ARIA snapshot reference (e.g., e42). It distinguishes from sibling tools like browser_snapshot (for obtaining snapshots) and browser_type (typing), making the specific action 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 explicitly states the prerequisite: 'Must call browser_snapshot first to obtain the reference.' This guides when to use the tool. However, it does not mention when not to use it or provide alternatives, which slightly reduces clarity.

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

• browser_snapshotA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It explains that the tool returns a list of interactive elements with references, implying a read operation. However, it does not disclose if any state changes occur, authentication needs, or potential side effects. The description is adequate but lacks 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 two sentences long and front-loaded with the main purpose. Every sentence provides value: the first defines the action and output, the second explains how to interact with the output. No unnecessary words.

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

  Completeness4/5

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

  Given the tool has no output schema, the description compensates by describing the return format (list with references). It also links to the next step (using browser_click). It covers the essential aspects for usage. However, it could mention error conditions or requirements (e.g., page must be loaded).

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

  Parameters4/5

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

  The schema has 100% coverage for the single parameter 'page_id', with a description. The tool description adds the default behavior ('if not specified, use the current page'), which provides extra context beyond the schema. This justifies a score above the baseline of 3.

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

  Purpose4/5

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

  The description clearly states the tool retrieves an ARIA accessibility snapshot and returns interactive elements with numbered references. This distinguishes it from siblings like browser_click (clicking) and browser_type (typing). However, it could more explicitly contrast with other browser tools.

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

  Usage Guidelines3/5

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

  The description provides a usage hint: after getting the snapshot, use browser_click(ref) to click elements. But it does not specify when to use this tool versus alternatives, nor does it mention scenarios where it should not be used. The guidance is minimal.

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

• browser_typeA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Discloses typing behavior and dependency on snapshot, but lacks details on side effects, permissions, or error conditions. Adequate minimally.

  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, front-loaded with action. No redundant information.

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

  Completeness4/5

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

  Covers core functionality and prerequisite. With 4 parameters (2 required) and no output schema, description is fairly complete. Could mention submission behavior, but schema covers it.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. Description does not add extra meaning beyond the schema; it repeats the same info.

  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?

  Description clearly states verb (type text), resource (input box), and method (via ARIA snapshot reference). Distinguishes from sibling tools: browser_snapshot is prerequisite, browser_click is clicking, browser is generic.

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

  Usage Guidelines4/5

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

  Explicitly states prerequisite: must call browser_snapshot first to get the reference. Provides clear usage context, though no alternatives or when-not-to-use guidance.

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