Server Quality Checklist

Tool Scores

• navigateA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses return values on success and error and the default tab selection, but does not mention loading behavior, timeouts, or failure conditions beyond a generic error response.

  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, front-loaded with the main verb, and contains no extraneous information. Every sentence earns its place.

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

  Completeness4/5

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

  Given the tool's simplicity, two parameters, and no output schema or annotations, the description provides a good overall picture including return format and default tab behavior. It could be more complete by describing load waiting or error detail, but it suffices for basic usage.

  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 0%, so the description must compensate. It adds value by explaining tab_id's default behavior, but for url it only repeats the parameter name without additional format or constraints beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb and resource: 'Navigate a Chrome tab to url'. It distinguishes itself from siblings like evaluate and cdp_command by focusing on navigation.

  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 explains the default behavior when tab_id is omitted, which provides context for parameter usage. However, it does not explicitly discuss when to choose this tool over alternatives like evaluate or cdp_command, nor does it mention any exclusions.

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

• list_tabsA
  4.1/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the return format and the error behavior when Chrome is unreachable. Although it does not explicitly state the tool is read-only, the verb 'list' implies no side effects, and the error condition adds useful context.

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

  Conciseness5/5

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

  The description is exactly two sentences, front-loaded with the primary action, and efficiently includes the return type and error condition with no unnecessary words. It is concise and well structured.

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

  Completeness5/5

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

  The tool is simple with no parameters and no output schema. The description fully covers its behavior: what it does, what it returns, and when it errors. That is sufficient for an agent to select and 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?

  There are zero parameters, so the input schema is trivially complete. The description does not need to compensate for undocumented parameters, and the baseline for a zero-parameter tool is 4.

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

  Purpose5/5

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

  The description uses the specific verb 'List' with the resource 'open Chrome page tabs' and further distinguishes the tool by showing the return shape (tabs with id/title/url/type). This is clearly distinct from sibling tools like navigate or evaluate.

  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 only states what it does but does not explain when to prefer it over cdp_command or other siblings, or mention any exclusions or prerequisites.

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

• evaluateA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description itself conveys important behavioral details: promises are awaited, return values are provided with a specific structure on success, and errors are returned on failure or uncaught JS exceptions. It does not mention potential side effects or permission requirements, but the core behavior is well 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 concise and well-structured: it opens with the primary purpose, then explains default behavior, promise handling, and return format. Every sentence adds value without unnecessary padding.

  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 description covers the key operational aspects: default tab selection, promise resolution, and return/error shapes. Since there is no output schema, this return information is essential and present. Minor omissions like tab-not-found behavior or special return types prevent a perfect score, but overall it is contextually 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?

  Schema description coverage is 0%, so the description must clarify parameters. It explains that expression is a JavaScript expression and that tab_id defaults to the first page tab when omitted. This adds meaningful context beyond the raw schema, though it could be more detailed about expression syntax or edge cases.

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

  Purpose5/5

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

  The description clearly states the tool's function: evaluating a JavaScript expression in a Chrome tab. This specific verb+resource distinction separates it from sibling tools like list_tabs and navigate, which have different purposes.

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

  Usage Guidelines3/5

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

  The description provides usage context by noting that the first page tab is used when tab_id is omitted, but it does not explicitly compare with alternatives or state when to use this tool over cdp_command or other siblings. The intended use is implied but not formally contrasted.

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

• pingA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses return behavior for both success and failure cases, including the exact JSON structure. It does not mention side effects, but for a ping operation, none are expected, so this is adequate.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the purpose, and includes the important return value details. Every sentence earns its place, with no redundant or verbose language.

  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 no parameters and no output schema, the description provides sufficient detail about the return values and the operation's purpose. It could mention that it has no side effects, but the tool is simple enough that this is not a major gap.

  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 there is nothing to describe. Per the rubric, a baseline of 4 is appropriate since no parameter semantics need to be added beyond the empty schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Check connectivity to Chrome's DevTools endpoint'. It uses a specific verb ('Check') and resource ('Chrome's DevTools endpoint'), and the response format distinguishes it from sibling tools like cdp_command or navigate.

  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 as a connectivity check, which is a sensible precursor to other CDP operations, but it does not explicitly state when to use this tool vs alternatives or provide exclusions. The context suggests it is a health check, but no direct guidance is given.

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

• cdp_commandA
  4.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains that the tool targets a page websocket, that browser-level domains fail, and that it runs against a given tab or the first page tab. It also documents the return format. However, it does not warn about potential side effects of raw CDP commands (e.g., Page.navigate changing state), which would be useful for an escape-hatch 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 concise and well-structured: the first sentence states the purpose, the second gives usage context, and the third provides key technical details and return format. Every sentence earns its place with no 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?

  The description covers the essential aspects for a raw CDP tool: purpose, usage context, target selection, domain limitations, and return format/error format. This is quite complete given the low complexity. The only gap is the lack of explicit mention of potential side effects or safety precautions, which would be a valuable addition for an escape hatch.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must fully compensate. It does so by explaining 'method' as any CDP method with examples, 'params' as its parameters, and 'tab_id' implicitly through 'Runs against the given tab (or the first page tab).' This adds meaningful context beyond the bare schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Send a raw CDP command and return its raw result — escape hatch.' This is a specific verb+resource combination and it distinguishes itself from siblings by positioning itself as a low-level fallback. It also clarifies its scope (page websocket only, browser-level domains not supported), which further differentiates it.

  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 'Use when the higher-level tools don't cover what you need,' giving a clear guideline for when to use this tool versus alternatives. It also states the limitation that browser-level domains like Browser.* and Target.* are not supported, helping the agent avoid misuse.

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