Server Quality Checklist

Tool Scores

• detect_visual_occlusionA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the core method (bounding box intersection), but does not mention important limitations such as ignoring z-index, opacity, or stacking context, nor does it describe the return format or any side effects. This is a moderate 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?

  The description is two sentences: the first states the function and method, the second provides examples. It is concise, front-loaded, and contains no wasted words.

  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?

  There is no output schema, so the description should ideally explain the return value, but it doesn't specify whether it returns a boolean, ratio, or other result. It also omits any mention of the viewport parameter's role, though the schema covers that. Overall, the description covers purpose and examples but leaves some operational details undefined.

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

  Parameters3/5

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

  The schema provides 100% coverage of all parameters, including nested viewport properties. The description only reinforces the role of target_selector and overlay_selector via examples, adding no new semantic meaning. Baseline 3 applies because the schema handles parameter documentation.

  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 ('checks if one element physically overlaps another') and the method ('computing the intersection of their bounding boxes'). It provides concrete example questions ('is this button hidden under a sticky header? Does the cookie banner block the CTA?'), which distinguishes it from sibling tools by focusing on overlap/occlusion.

  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 with practical scenarios, indicating when the tool is appropriate (e.g., for sticky header and cookie banner issues). However, it does not explicitly name alternatives or state when not to use the tool, so it falls short of full usage guidance.

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

• compute_viewport_reflowA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core behavior (measuring position/size changes) but does not mention side effects, prerequisites, or output format. The description is not misleading but is somewhat minimal.

  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, with the first sentence defining purpose and the second providing usage examples. It is front-loaded, concise, and free of unnecessary 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?

  Given the tool's moderate complexity, clear input schema, and no output schema, the description covers the main purpose and usage scenarios. It lacks explicit return format details, but the example questions imply the kind of results produced, making it reasonably complete.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all three parameters (url, selectors, viewports), so the description does not need to add parameter details. The tool description adds no extra parameter context, but the schema already fully documents them, supporting the baseline score of 3.

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

  Purpose5/5

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

  The description clearly states the tool measures element positions and sizes across viewport sizes, which is a specific verb+resource. It distinguishes itself from sibling tools like extract_bounding_boxes or detect_visual_occlusion by focusing on reflow behavior across breakpoints, and it provides concrete example questions.

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

  Usage Guidelines4/5

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

  The description gives explicit usage guidance with 'Use to answer:' followed by practical questions, indicating when the tool is appropriate. It does not explicitly exclude alternative tools, but the use cases are clear enough to guide selection.

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

• verify_spatial_relationshipsA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the return behavior ('pass/fail per rule with a human-readable reason'), which is valuable. However, it does not mention edge cases such as missing selectors, rule evaluation order, or error handling, which would be relevant for an agent deciding whether the tool's behavior is predictable.

  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 core purpose, and includes concrete examples. There is no redundant or filler content; 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?

  The tool has a complex nested input schema and no output schema, but the description compensates by explaining the output format (pass/fail per rule) and giving usage context. The schema handles the structural details, and the description provides the intent. It lacks only peripheral details like handling of invalid selectors or rule limits, which are not critical for selection.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters. The description adds meaningful examples of rule expressions that illustrate the 'rules' parameter semantics, but it doesn't materially expand on url or viewport. Given the high schema coverage, a baseline 3 is appropriate with slight bonus for the examples.

  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 ('validates') with a clear resource ('spatial layout rules') and provides concrete examples ('nav must be above hero', 'sidebar must be left of content'). It clearly distinguishes this tool from siblings like extract_bounding_boxes or detect_visual_occlusion by focusing on rule verification rather than extraction or detection.

  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 an explicit use case: 'Use to answer: does the page layout match the design specification?' This tells the agent when to apply the tool. However, it does not explicitly name alternatives or state when not to use it, though the sibling tools imply other layout-analysis scenarios.

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

• calculate_perceptual_contrastA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It does a good job by stating that both WCAG 2.x and APCA formulas are evaluated simultaneously and that the tool is intended to expose cases where legacy WCAG is misleading. It does not mention side effects like network page loads or dependence on rendered CSS, but for a read-only analysis tool this is a meaningful, honest behavioral description.

  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 and front-loads the core action ('Measures color contrast...') followed by concrete user questions. Every phrase earns its place; there is no fluff or repetition of schema content.

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

  Completeness4/5

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

  The description is largely complete: it explains what the tool measures, why the dual-formula approach matters, and the kinds of questions it answers. The schema provides thorough parameter documentation, including nested viewport fields. However, there is no output schema and the description does not mention what the return value looks like, so an agent is left to infer the exact response shape.

  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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra parameter-level detail beyond the schema; it merely restates that text and background selectors are involved. It does not clarify how viewport size might influence contrast measurement or how selectors are resolved.

  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 ('Measures') and names the exact resource ('color contrast between a text element and its background'), making it unmistakably distinct from the sibling layout/visual tools. It also names the two formulas (WCAG 2.x and APCA), which is concrete and differentiates the tool's scope.

  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 provides clear, crisp use cases: 'does this text pass accessibility contrast requirements?' and 'Is it actually readable even if it technically passes the legacy formula?' These give strong context for when the tool should be used. However, it does not explicitly say when not to use it or name alternative sibling tools for similar measurement tasks.

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

• extract_bounding_boxesA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full transparency burden. It clearly discloses what the tool returns (geometric position, size, z-index, viewport visibility) and implies a read-only operation, but it does not discuss edge cases such as missing selectors or default viewport behavior. Still, it gives a solid, non-misleading picture of 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 two sentences long: the first states the tool's function, and the second provides example use cases. Every sentence earns its place with 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 tool with three parameters (two required) and no output schema, the description gives enough context for an agent to select it appropriately. It clarifies the data returned (position, size, z-index, visibility) and the use case, though it does not specify the exact return format. Overall, it is sufficient for effective selection and 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?

  The schema describes all 3 parameters with 100% coverage, so the description adds no extra parameter-level detail. The mention of 'one or more DOM elements' aligns with the selectors array, but there is no added syntax or format guidance 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 clearly states the tool returns geometric position, size, z-index, and viewport visibility for DOM elements. This specific verb+resource distinguishes it from sibling tools like detect_visual_occlusion or verify_stacking_context, which focus on different analyses.

  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 provides concrete example questions ('where exactly on screen is this element?', 'Is it visible?', 'Is it off-screen?') that signal when to use this tool. However, it does not explicitly mention alternative tools or exclusion criteria, so it lacks the explicit when-not-to-use guidance needed for a 5.

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

• verify_stacking_contextA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It transparently explains the tool's behavior: it reveals a chain of ancestors and explains why they create stacking contexts. This goes beyond a simple 'verifies stacking context' and gives insight into the output and purpose. It could have mentioned read-only or error behavior, but as a low-risk analysis tool, 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: the first states the core action and output, the second gives concrete usage examples. Every sentence earns its place, and it is front-loaded with the main purpose.

  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 has three parameters (one nested) and no output schema. The description explains the core output (the chain and reasons) and gives real-world scenarios, which is fairly complete. It does not detail edge cases like element not found or handling of dynamic pages, but for a focused diagnostic tool this is acceptable.

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

  Parameters3/5

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

  The input schema has 100% coverage of parameter descriptions (url, selector, viewport), so the baseline is 3. The description does not add extra parameter-level detail, but it contextualizes the purpose of the selector and viewport implicitly through the diagnostic use 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 uses a specific verb ('Reveals') and resource ('full CSS stacking context chain for an element'), clearly distinguishing it from siblings such as detect_visual_occlusion or compute_viewport_reflow. It also provides concrete diagnostic questions, making the purpose explicit.

  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 clearly states when to use the tool ('why is my z-index:9999 element still behind a modal? Does this element create its own stacking context?'), which is strong usage context. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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