Server Quality Checklist

Tool Scores

• session_actB
  3.3/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 of disclosing behavioral traits. It only lists the actions and does not describe side effects (e.g., navigation, page mutations), failure modes, waiting behavior, or how 'eval' interacts with the page context. This is minimal transparency for a tool that performs potentially impactful browser actions.

  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, front-loaded sentence that states the purpose and the supported actions in a compact, readable list. There is no redundant information, making it highly concise and well-structured.

  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 (4 parameters, no output schema, no annotations), the description is too sparse. It does not explain what each action does, expected formats for target beyond schema snippets, or any return values or error behavior. Sibling tools hint at session context, but the description alone is insufficient for an agent to fully understand the tool's behavior.

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

  Parameters2/5

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

  Schema description coverage is 50%, with value and target described in the schema. The description adds no meaning beyond what the schema already provides; it merely repeats the action enum. It does not clarify relationships like which parameters apply to which actions or how session_id is used, so it falls short of compensating for the undocumented parameters.

  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 with a specific verb ('Perform') and resource ('browser action'), and enumerates the specific actions (goto, click, fill, press, eval). This clearly differentiates it from sibling tools like session_start, session_observe, session_end, and qa_get_trace, which handle other aspects of the session lifecycle.

  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 the tool's usage (when you need to perform a listed browser action) but does not explicitly state when to use it versus alternatives such as session_observe for inspecting state or session_start for creating a session. No exclusions or comparative guidance is provided, so usage is implied rather than explicit.

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

• session_observeA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It does not explicitly state that the operation is read-only, nor does it describe error behavior for invalid session IDs or inactive sessions. The word 'return' suggests non-mutation, but other behavioral aspects are undisclosed.

  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 sentence with no unnecessary words. It is front-loaded with the verb and clearly states the output components, making it extremely concise and well-structured.

  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 one parameter and no output schema, the description adequately specifies the return value (URL and aria-snapshot). It does not detail the output format or error handling, but given the tool's simplicity, the description is nearly complete, with only minor missing context.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It references 'session's page' which implies session_id identifies a session, but it does not explain what a session_id is, its format, or how to obtain it. This is minimal semantic addition beyond the raw parameter name.

  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 states a specific verb 'return' with a clear resource: 'current URL and aria-snapshot of the session's page.' This clearly differentiates it from sibling tools like session_start and session_act, which focus on lifecycle actions, and qa_get_trace, which retrieves traces.

  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 when to use the tool (to observe the page state) but does not explicitly state when not to use it or mention alternatives. It lacks guidance on prerequisites such as needing an active session, which is left to the user to infer.

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

• session_startA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure. It discloses that a fresh tab is opened and that recording starts, which is useful. However, it does not explain state resets (e.g., if a session already exists), navigation behavior for the optional URL, or any return values or session identifiers.

  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 sentence that is front-loaded with the primary action ('Open a fresh browser tab') and has no filler or redundant phrases. It earns its place entirely.

  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?

  The core action is covered, but the tool has no output schema and no annotations, so the description should explain what happens after starting (e.g., whether a session ID is returned, how the session continues). The relationship to sibling tools is also omitted, which is important for an orchestration flow.

  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% because both parameters have descriptions, so the baseline is 3. The description adds only a minor hint that the goal is central by calling the session 'goal-driven', but it does not provide additional semantic detail 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 uses a specific verb and resource: 'Open a fresh browser tab and start recording a goal-driven session.' This clearly identifies the tool as the session initializer, distinguishing it from siblings like session_act and session_observe.

  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 when starting a new session, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any preconditions or that subsequent tools (session_act, session_observe) should follow. Guidance is only implicit.

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

• qa_get_traceA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral transparency. It discloses what the trace includes and the prerequisite ordering, but does not explicitly state whether the operation is read-only, what happens if session_end has not been called, or any side effects. The name 'get' implies read-only, but explicit disclosure is absent.

  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, each earning its place. The first sentence states the core action and output contents, while the second provides a necessary ordering instruction. No unnecessary words or repetition.

  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 simple retrieval tool with one obvious parameter and no output schema, the description is fairly complete: it covers what is returned (goal, steps, URL, snapshot) and the required prerequisite. It does not cover error cases or what to do if the trace is unavailable, but these are likely edge cases that can be inferred or discovered at runtime.

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

  Parameters2/5

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

  Schema coverage is 0% and the description does not mention the session_id parameter at all. While the parameter name is self-explanatory, the description could have clarified that it expects the session ID from session_start or session_end, or provided format details. The lack of any parameter guidance fails to compensate for the sparse 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 action ('Return the full recorded trace') and specifies the exact contents (goal, every step, final URL, final aria-snapshot). It distinguishes itself from sibling tools by focusing on post-session retrieval for evaluation, not session management or actions.

  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 instruction 'Call session_end first' provides a clear prerequisite for when to use the tool, implying it should be used after session completion. However, it does not explicitly contrast with sibling tools or state when not to use it, though the context of sibling names makes the role obvious.

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

• session_endA
  4.2/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden of disclosing behavior. It transparently mentions the closing of the session, persistence to disk, and returning the path. It does not state that the session becomes invalid after closing, but 'close' implies this, and the key side effects are 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 a single, well-structured sentence that sequentially lists the actions: close, persist, and return. Every word adds value, and it is instantly readable. There is no redundancy.

  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 simple one-parameter tool with no output schema, the description sufficiently covers the purpose, side effects, and return value. It could be more explicit about the session_id parameter and the irreversible nature of closing, but it provides enough information for an agent to invoke the tool correctly in most contexts.

  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 a single required parameter, session_id, with no description, and schema coverage is 0%. The description indirectly maps the parameter by referring to 'the session', suggesting that session_id identifies which session to close. This provides some context but does not explicitly describe the parameter's format or constraints.

  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 a specific action ('Close the session') and its side effects ('persist the trace to disk', 'return the path'). It distinguishes this from sibling tools like session_start, session_act, session_observe, and qa_get_trace by focusing on the terminal action of a session.

  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 implies the tool is to be used when ending a session and saving its trace. While it does not explicitly mention alternatives or exclusions, the context is clear: 'Close the session' is a definitive action that an agent would choose when finishing a session. The sibling tools cover other phases, making the usage context evident.

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