Server Quality Checklist

Tool Scores

• get_runtime_errorsA
  3.8/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 burden of explaining behavior. It discloses the source (preview iframe), the event types, and the available error fields, plus the 'recent' and 'when available' caveats. It does not mention ordering, retention limits, or whether retrieval has side effects, but for a read-only error lookup the description is reasonably transparent.

  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 with no filler. The first sentence states the action and output fields; the second provides the key usage scenario. It is appropriately sized and front-loaded.

  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 tool's purpose, output fields, source context, and a clear trigger for use. The optional parameters are well documented in the schema. The only notable gap is not addressing how this tool relates to sibling tools such as get_event_log or tail_events, but this is not critical for basic 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 input schema already documents both parameters with descriptions, ranges, and defaults, so schema coverage is 100%. The description adds no additional parameter-specific semantics, which is acceptable because the schema fully carries that weight.

  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 returns runtime errors and unhandled-rejection events from the preview iframe, with a specific verb and resource. It is easy to tell it is error-focused, though it does not explicitly name or differentiate itself from sibling tools like get_event_log or tail_events.

  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 a direct usage cue: 'Use this when the user reports a broken preview or you want to see what just crashed.' This provides clear context for when to invoke the tool, but it does not mention when not to use it or how it compares to alternative event/log tools.

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

• get_event_logA
  3.9/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 behavioral burden. It discloses meaningful traits: ring-buffered with 500 entries, 'bridge-reinstalled' events filtered out by default, and cursor-based pagination via 'since'. It does not mention output shape or access requirements, but it provides solid behavioral context beyond the schema.

  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?

  Three dense sentences contain all the essential facts with no wasted words. The core behavior is front-loaded, and parameters are summarized economically before the important default-filtering caveat.

  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 no required parameters and a fully documented schema, the description covers the important invocation details: source, level, kind, limit, since, and the default filter behavior. It does not describe the event return shape, and there is no output schema, but the tool is still sufficiently specified for correct 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?

  Schema coverage is 100%, so the baseline is 3. The description adds value above the schema by explaining the ring-buffer behavior, the cursor semantics of 'since', and the non-obvious default exclusion of 'bridge-reinstalled' events, which clarifies how the 'kind' parameter behaves.

  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 a specific resource ('recent BridgeEvents from the live preview') and a verb ('Returns'), and it is easy to understand what the tool produces. However, it does not explicitly differentiate from the sibling 'tail_events', which is likely the closest alternative.

  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 conveys the context in which the tool is useful (reading recent live-preview events) and details optional filters and pagination. It gives no direct guidance about when to prefer another sibling like 'tail_events' or 'get_runtime_errors', so the selection knowledge is only implicit.

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

• get_session_infoA
  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 burden. It discloses what the tool returns, including the caveat 'if known' for the preview URL, and implies a read-only diagnostic operation. It does not explicitly state side-effect-free behavior, but the zero-parameter getter framing makes this reasonably clear.

  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 lists what is returned, and the second gives the use case. It is front-loaded, efficient, and contains no redundant filler.

  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 diagnostic tool with no output schema, the description is complete enough. It names all relevant return fields and explains why an agent would call it, making it clear and actionable.

  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 no properties, so there are no parameters to document. The description correctly adds no unnecessary parameter details, meeting the baseline for zero-parameter tools.

  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 returns bridge connection state and enumerates specific fields: connection mode, preview URL, event count, and bridge version. It is specific and unambiguous, but it does not explicitly differentiate itself from sibling tools like get_event_log or query_preview_state.

  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 a clear usage directive: 'Use to verify the bridge is actually receiving data before relying on other tools.' This tells an agent when to use it, though it does not mention when not to use it or name alternative tools.

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

• tail_eventsA
  4.4/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 and does disclose the key blocking behavior, timeout semantics, and return of matched events. It does not explicitly state what happens when maxWaitMs elapses with no matching event (empty list vs. null vs. error), which is a meaningful ambiguity.

  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 definition is compact and well-structured: the core blocking behavior is front-loaded, followed by use-case guidance, examples, and defaults. Every sentence earns its place without unnecessary 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?

  Given the absence of annotations and an output schema, the description covers the essential behavior, parameters, and alternative usage well. The only notable gap is the unspecified timeout result, which prevents it from being fully 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?

  Schema coverage is 100%, so the schema already documents kinds, limit, and maxWaitMs. The description adds helpful context like runtime-signal examples and the default/max wait time, but it mostly restates what the schema already provides.

  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 identifies a specific behavior (long-poll blocking) and a specific resource (events matching `kinds`). It also distinguishes itself from the more obvious sibling, get_event_log, by explicitly saying this tool avoids polling.

  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?

  It states exactly when to use the tool: to wait for runtime signals like route changes or build completion. It also names the polling alternative (get_event_log) and frames this tool as the non-polling option, giving an agent clear selection guidance.

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

• query_preview_stateA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden, and it does so well. It discloses that the operation is a live snapshot request, that password fields are filtered out of form results, and that it times out in 800ms when no host page is connected. These are meaningful behavioral traits beyond the schema, giving the agent accurate expectations about safety and failure 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 compact and front-loaded, with the core action in the first sentence and the most important behavioral caveats (password filtering, timeout) included without filler. Every clause earns its place, and the list of kinds is structured for quick parsing.

  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 two-parameter tool with no output schema and no annotations, the description is remarkably complete. It explains what the tool returns for each kind, warns about password filtering, and specifies the timeout failure mode when no host page is connected. An agent has enough context to select, invoke, and interpret the result 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?

  Schema coverage is 100%, so the schema already documents both parameters, but the description adds substantial meaning beyond the bare field names. It explains what each 'kind' value returns, notes password filtering, and clarifies that 'combined' is available. The optional 'selector' parameter is less elaborated, but the schema's 'Optional CSS selector to scope the query' is adequate there.

  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 specific verb and resource: 'Asks the connected browser page for a live state snapshot.' It then enumerates the exact kinds ('form', 'route', 'selection', 'focus', 'all'), making the tool's purpose unambiguous. It also distinguishes itself from the session/log/event/error siblings by framing this as a page-state query rather than historical or session data.

  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 establishes clear usage context: use this when you need the current live state of the connected browser page, especially form values, route, selection, or focus. It does not explicitly name sibling alternatives or state when not to use them, but the sibling names (get_session_info, get_event_log, get_runtime_errors, tail_events) are clearly different domains, so the intended placement is reasonably obvious.

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