Server Quality Checklist

Tool Scores

• get_textC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral context. It states what the tool does but doesn't disclose error handling, performance characteristics, whether it returns formatted/raw text, or if it requires specific page states. This is inadequate for a tool with potential 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 a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.

  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?

  Given no annotations, no output schema, and a tool that likely interacts with a browser/page context, the description is incomplete. It doesn't explain return values, error conditions, or dependencies on other tools (e.g., 'navigate' first), leaving significant gaps for an AI 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?

  Schema description coverage is 100%, so the schema already documents the 'selector' parameter fully. The description adds no additional meaning about parameter usage beyond implying it extracts text from elements matching the selector, which aligns with but doesn't enhance the schema.

  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 verb 'Get' and the resource 'text content of an element', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_console_logs' or explain what type of element it works on (DOM element vs. other).

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a page to be loaded), when not to use it, or how it relates to siblings like 'click' or 'navigate'.

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

• navigateC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions navigation but doesn't describe what happens after navigation (e.g., page load behavior, error handling, or whether it waits for completion). This leaves significant gaps in understanding the tool's behavior.

  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, clear sentence that directly states the tool's function without any unnecessary words. It's perfectly front-loaded and efficiently communicates the core purpose in minimal space.

  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 browser navigation tool with no annotations and no output schema, the description is insufficient. It doesn't address what happens after navigation, potential errors, or how it interacts with other browser tools, leaving the agent with incomplete context for effective use.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the single parameter 'url' clearly documented in the schema. The description adds no additional semantic context beyond what's already in the schema, so it meets the baseline score without providing extra value.

  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 action ('navigate to') and target ('specific URL in the browser'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'click' or 'get_text' which also involve browser interaction, so it doesn't reach the highest score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'click' or 'type', nor does it mention any prerequisites or context for navigation. It simply states what the tool does without indicating appropriate usage scenarios.

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

• screenshotC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't cover aspects like file format (e.g., PNG, JPEG), save location, permissions needed, or error handling. This leaves significant gaps for a tool that performs a system-level operation.

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

  Conciseness5/5

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

  The description is a single, clear sentence with zero waste—it directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it highly efficient.

  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?

  Given the tool's complexity (a system operation with potential side effects), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., file path, success status) or behavioral details like format or errors, leaving critical gaps for agent use.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the 'name' parameter documented as 'Name for the screenshot file (without extension)'. The description adds no additional parameter semantics beyond this, so it meets the baseline for high schema coverage without compensating further.

  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 action ('Take a screenshot') and the target ('of the current page'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_text' or 'set_viewport', which might also involve page content manipulation, so it doesn't reach the highest score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'get_text' for text extraction or 'set_viewport' for viewport adjustments. It lacks explicit context, exclusions, or prerequisites, leaving usage decisions to inference.

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

• set_viewportC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It states the tool sets the viewport size and hints at mobile simulation, but lacks critical behavioral details: it doesn't specify if this affects current page rendering, requires an active browser context, has side effects (e.g., page reload), or error conditions (e.g., invalid dimensions). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

  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, efficient sentence that front-loads the core purpose ('Set the browser viewport size') and includes a concise, relevant example. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly scannable and clear.

  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?

  Given the tool's complexity (a mutation operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like how the viewport change is applied, what happens to the current page, error handling, or return values. For a tool that modifies browser state, more context is needed to ensure safe and correct usage by an AI 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?

  Schema description coverage is 100%, with clear descriptions for 'width', 'height', and 'mobile' parameters. The description adds marginal value by linking 'mobile simulation' to the 'mobile' parameter, but doesn't provide additional semantics beyond what the schema already documents (e.g., no guidance on typical width/height values, interaction between 'mobile' and dimensions, or default behaviors). Baseline 3 is appropriate as the schema does the heavy lifting.

  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 action ('Set') and resource ('browser viewport size'), with the parenthetical example providing additional context about mobile simulation. It distinguishes from siblings like 'navigate' or 'screenshot' by focusing on viewport configuration rather than navigation or capture. However, it doesn't explicitly differentiate from all siblings (e.g., it could mention this is for visual/rendering adjustments vs. interaction tools like 'click' or 'type').

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

  Usage Guidelines2/5

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

  The description provides minimal guidance with the example 'e.g., for mobile simulation', which implies a use case but doesn't specify when to use this tool versus alternatives or prerequisites. There's no explicit when/when-not guidance, no mention of dependencies (e.g., requires a browser session), and no comparison to sibling tools like 'navigate' for page loading or 'screenshot' for capturing the viewport after setting it.

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

• get_console_logsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that logs are 'captured during the session', implying real-time or session-specific data, but lacks details on format, volume, permissions, or potential side effects like performance impact. This leaves significant gaps for a tool that retrieves data.

  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, clear sentence that front-loads the core action and resource without any wasted words. It's efficiently structured and easy to parse, making it highly concise.

  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?

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'console logs' entail (e.g., error messages, browser logs), the return format, or any limitations, which is inadequate for a tool that retrieves session data without structured output 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?

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't add unnecessary param details, earning a high score for not overloading with irrelevant information.

  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 verb ('Get') and resource ('all console logs captured during the session'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_text' or 'screenshot', which might also retrieve session data, so it doesn't reach the highest score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'get_text' or 'screenshot', nor does it mention prerequisites or context for usage. It simply states what the tool does without indicating when it's appropriate.

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

• clickB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('click') but doesn't describe what happens after clicking (e.g., page navigation, form submission, error handling), whether it requires specific page states, or any side effects like waiting for page loads. This leaves significant gaps for a mutation tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable. Every word earns its place by conveying essential information without redundancy.

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

  Completeness2/5

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

  Given the tool's complexity (a mutation action with potential side effects), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure status), error conditions, or behavioral nuances like click simulation versus actual browser events, leaving the agent with insufficient context.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the parameter 'selector' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (it merely repeats 'CSS selector'), so it meets the baseline of 3 where the schema does the heavy lifting without adding value.

  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 specific action ('click') and target ('an element on the page identified by a CSS selector'), using a precise verb+resource combination. It effectively distinguishes this tool from sibling tools like 'type' (which inputs text) or 'navigate' (which changes URLs), 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a page must be loaded first), exclusions (e.g., when not to click certain elements), or comparisons to sibling tools like 'get_text' or 'screenshot'. Usage context is implied but not explicitly stated.

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

• typeB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('Type text') but fails to describe critical behaviors such as whether it simulates keystrokes, clears existing content, handles errors if the selector is invalid, or requires the page to be in a specific state. This leaves significant gaps in understanding how the tool operates.

  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, efficient sentence that front-loads the core action and target, with zero wasted words. It is appropriately sized for a simple tool with two parameters, making it easy for an agent to parse quickly.

  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?

  Given the tool's complexity (a mutation action with no annotations and no output schema), the description is incomplete. It does not address behavioral aspects like error handling, side effects, or return values, which are crucial for an agent to use the tool correctly in a web automation context.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters ('selector' and 'text') fully documented in the input schema. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, so it meets the baseline for high schema coverage without compensating further.

  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 specific action ('Type text') and target resource ('into an input field identified by a CSS selector'), using precise verbs and distinguishing it from sibling tools like 'click' or 'get_text'. It directly communicates what the tool does without ambiguity.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'click' or 'set_viewport', nor does it mention prerequisites such as needing a page to be loaded. It lacks explicit context for usage decisions, leaving the agent to infer based on the tool name alone.

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