Server Quality Checklist

Tool Scores

• list_routesA
  4.5/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 that the tool returns a list of routes with stable IDs and reflects the current canvas state. This is useful behavioral context, though it does not address potential limitations like pagination or performance.

  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: two short sentences cover purpose, return values, and usage guidance. It is front-loaded with the most important information and contains no filler 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 zero-parameter list tool with no output schema, the description is complete. It explains what the tool does, what it returns, when to use it, and the stability of route IDs, leaving no ambiguity about its purpose or invocation.

  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 baseline is 4. The description adds value by explaining the purpose of the returned data (route IDs for removal/duplicate avoidance), which compensates for the lack of parameter details.

  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 verb-resource pair: 'List all routes' on the 'Design Canvas'. It specifies what is returned (route ID, path, viewport dimensions, canvas position), distinguishing it from sibling tools like add_route, remove_route, and capture_canvas.

  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?

  Usage guidance is explicit: 'Call this before removing routes... or before adding routes'. This tells when to use the tool, though it does not explicitly name alternative tools or state when not to use it. The context is clear, so it earns a 4 rather than a 5.

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

• remove_routeA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It clearly discloses that path-based removal only removes the first match and can be risky with duplicate paths, which is a critical behavioral nuance. It could mention whether removal is permanent or affects attached elements, but the key risk is well-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?

  The description is tightly structured: one purpose sentence followed by three concise constraint bullets. No filler; every sentence provides actionable guidance.

  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 (2 optional params, no output schema), and the description covers main usage scenarios and the edge case of duplicate paths. However, it does not specify whether id and path are mutually exclusive or what happens to attached elements when a frame is removed, leaving a minor 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 input schema already provides 100% description coverage for both parameters, so the baseline is 3. The description adds workflow context—preferring id, calling list_routes for exact viewport—which goes beyond the schema and 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 verb+resource statement ('Remove a route frame from the Design Canvas'), immediately distinguishing it from sibling tools like list_routes and add_route. The 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 Guidelines5/5

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

  The CONSTRAINTS section explicitly instructs the agent to prefer removal by ID, warns against path removal due to duplicate risk, and directs the agent to call list_routes first for specific viewport removal. This provides clear when/how guidance and names an alternative tool.

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

• add_routeA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the behavioral transparency burden. It discloses that the route is loaded from the connected dev server, displayed as a live frame, and returns a route ID. It also explains auto-positioning, horizontal stacking, and the behavior of adding duplicate routes at different widths for responsive comparison.

  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 well-structured with a clear main statement, bulleted constraints, and a separate responsive comparison note. Every section earns its place, and there is no redundant or filler content.

  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?

  Despite having no output schema, the description explicitly states that the tool returns the route ID. It covers purpose, restrictions, positional defaults, width labels, and a non-obvious use case (adding the same path multiple times for responsive comparison). This is a complete and self-sufficient description for an add-route tool.

  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?

  Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it constrains paths to start with '/', explicitly prohibits full URLs, defines standard viewport widths, and explains how omitted x/y coordinates lead to horizontal stacking. This operational guidance is 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 uses a specific verb and resource: 'Add a web page route to the Design Canvas.' It clearly distinguishes this tool from siblings like list_routes, remove_route, and capture_canvas by describing its unique purpose of adding a live frame to the canvas.

  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: routes are loaded from the dev server and displayed as live frames, with explicit constraints on path format, width standards, and auto-positioning. It also provides a concrete responsive-comparison workflow. It does not explicitly name sibling alternatives or state when not to use it, but the intended use case is well conveyed.

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

• capture_canvasA
  5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does so thoroughly. It discloses non-cached rendering, full page load waiting, WebKit rendering, performance cost, default image count, and the ability to target specific routes—important behavioral traits beyond what the schema shows.

  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 well-structured with clear USAGE and CONSTRAINTS sections. Every sentence adds practical value—no filler or redundancy—and the format makes it easy for an agent to scan and apply the guidance.

  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 fully contextualized despite having no output schema: it covers purpose, performance, constraints, parameter usage, alternatives, and expected output format. The information is sufficient for an agent to decide when and how to invoke the tool correctly.

  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 coverage is already 100%, but the description adds meaningful context: the default limit of 3, the benefit of passing specific route IDs for speed and context savings, and the source of route IDs (list_routes/add_route). This goes well beyond the raw schema definitions.

  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 captures fresh screenshots of routes on the Design Canvas, with specific details like triggering a new render and returning images. It distinguishes itself from sibling tools (list_routes, add_route, remove_route) by focusing on visual verification rather than route management.

  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?

  Explicit usage guidance is provided: use after making code changes for visual verification, avoid speculative calls due to cost, and pass specific route IDs to save time/context. It also names Playwright as the alternative for cross-browser verification, giving clear when-to-use and when-not-to-use direction.

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