Server Quality Checklist

Tool Scores

• session_record_eventsC
  2.7/5.0
  Behavior2/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 only says 'Fetch', omitting important traits such as pagination behavior, event ordering, whether results are read-only, or what kind of events are included.

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

  Conciseness4/5

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

  The description is a single front-loaded sentence with no filler words. It is concise and easy to parse, even though it is thin on useful detail.

  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?

  The tool has no output schema and no annotations, so the description is the only source of context. It fails to explain pagination semantics, event types, ordering, or how this relates to session_record_start and session_record_stop, leaving an agent with insufficient information to confidently use the tool.

  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 0%, so the description must compensate. It adds meaning for sessionId by connecting it to 'a session', but it says nothing about limit or offset, leaving pagination parameters semantically empty.

  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 states a specific verb 'Fetch' and a specific resource 'recorded events for a session'. It clearly distinguishes the operation from navigation, clicking, and other session actions, though it does not explicitly contrast with sibling record tools.

  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?

  No guidance is provided about when to use this tool versus alternatives like session_record_list, session_record_replay, or session_record_start. The description only states what it does, not the context or conditions under which it should be selected.

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

• session_fillC
  2.8/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 full responsibility for behavioral disclosure. It reveals the supported target kinds and rich text editors, but does not disclose whether the fill overwrites existing content, fires input events, requires visibility, or what happens if the selector/ref is missing. These are material behaviors for a form-filling action.

  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?

  Two sentences with no filler. The first sentence states the action and target, and the second adds relevant scope (rich text editors). Nothing is redundant or bloated.

  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?

  For a tool with four parameters, no annotations, and no output schema, the description leaves important gaps: parameter semantics for selector and value, behavioral expectations (overwrite vs append, event triggering), and when to choose this over the similar 'session_type' sibling. It is too sparse to fully guide an agent on correct invocation.

  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 only 25%, with only 'ref' described. The description does not compensate: 'with a value' adds no more meaning than the 'value' parameter name already implies, and it says nothing about how to construct 'selector' or when to use 'tabId'. The useful 'ref' semantics are already in the schema, so the description's contribution is minimal.

  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 states a specific action ('Fill') and resource ('form field (input, textarea, or contenteditable)'), plus supported rich text editors. This makes the core purpose clear. However, it does not explicitly distinguish this from the sibling 'session_type', which could perform similar actions in some contexts.

  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?

  No explicit guidance on when to use this tool versus alternatives like 'session_type' or 'session_click'. The mention of ProseMirror, Lexical, Slate and other rich text editors implies a use case, but it stops short of stating 'use this when interacting with rich text editors' or mentioning that 'session_type' is preferred for normal inputs.

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

• session_read_pageC
  2.8/5.0
  Behavior2/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 signals a read-only operation and describes the kind of content returned, but it does not explain authentication requirements, behavior on invalid or missing tabId, whether the page must be loaded, or any side effects. This is a meaningful gap.

  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 communicates the core purpose without filler or redundancy. Every part of the sentence adds useful information.

  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?

  While this is a relatively simple tool, there is no output schema and no parameter description, so the description must do more. It explains the high-level return content but leaves out how to select the tab and what the actual return structure looks like, making it incomplete for safe invocation.

  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 0%, yet the description does not mention the sole tabId parameter at all. The agent is left to infer from the parameter name and type that it identifies a tab, but has no information about whether it is required, optional, or what value should be supplied.

  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 verb ('Read') and the resource ('full page content'), and enumerates the content types it returns: text, inputs, and interactive elements. It does not explicitly differentiate itself from siblings that may overlap, such as session_snapshot or session_evaluate, so it stops short of a 5.

  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 gives no guidance on when to use this tool instead of session_snapshot, session_evaluate, or other siblings. The phrase 'authenticated page' hints at a precondition, but there is no explicit when-to-use, when-not-to-use, or alternative selection guidance.

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

• session_snapshotC
  2.8/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 behavioral disclosure. It communicates that this is a capture operation and names the output categories, but it does not explicitly state whether the page is modified, whether authentication is needed, or whether the snapshot is purely read-only.

  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 with no filler. It efficiently conveys the core purpose and the main output categories without wasting tokens.

  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?

  With no output schema and no annotations, the description should explain the refs structure, what 'active element' means, and what happens when tabId is omitted. None of these are addressed, and the tool's relationship to sibling read/capture tools is unclear, making the overall definition incomplete.

  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 0%, and the description does not mention the optional tabId parameter or explain what happens when it is omitted. The parameter name gives a minimal hint, but the semantics of targeting a tab and the default behavior are left entirely undocumented.

  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 states a specific action ('Capture a semantic snapshot') on a specific resource ('a page') and enumerates the captured contents: URL, title, active element, and interactive elements with refs. It does not explicitly distinguish this from sibling tools like session_read_page or session_screenshot, so it falls just short of a 5.

  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?

  There is no guidance on when to use this tool versus session_read_page, session_evaluate, or session_screenshot. The description never mentions prerequisites, typical invocation timing, or exclusions, so the agent must infer appropriate usage from context.

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

• session_record_replayC
  2.9/5.0
  Behavior2/5

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

  With no annotations, this description carries the full burden, and it only conveys that replay targets the original tab. It does not disclose side effects on the tab/browser, whether the replay requires an explicit stop first, how speed affects playback, or what happens after replay completes.

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

  Conciseness4/5

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

  A single, front-loaded sentence with no filler, and the key qualifiers ('stopped', 'original tab') are packed in. It earns a high conciseness score, though brevity comes at the cost of missing behavioral and parameter detail.

  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?

  The tool is action-oriented, has no annotations, and has no output schema, so the description should supply the missing behavioral and return context. It does not explain return type, tab state after replay, errors for an invalid session, or the speed parameter's effect — leaving the definition under-specified for a new agent.

  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 describes the speed parameter (default 1), but sessionId, the only required parameter, has no schema or description explanation. The tool description adds no parameter-level meaning, so an agent must guess that sessionId refers to a previously recorded session ID.

  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 uses a concrete verb-resource pair ('Replay' + 'stopped recording session') and adds a scope qualifier ('in the original tab'). This distinguishes it from the recording-management siblings like session_record_start/stop/list/events, even though it never names them.

  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 intended use — replaying a session after it has been stopped — but it never states when to prefer it over related tools or lists any exclusions. The 'stopped' qualifier hints at a precondition, but alternatives and non-use cases are left unspoken.

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

• session_pressB
  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 behavioral burden. It only says a key is pressed; it does not disclose possible side effects like form submission or navigation, whether the element is focused first, keydown/keyup behavior, or what the outcome/return value looks like.

  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?

  A single concise sentence that is front-loaded with the verb and packs useful examples in parentheses. There is no filler or repetition.

  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?

  With no output schema, no annotations, and four parameters where three lack schema descriptions, the description is too thin. It does not explain how to populate key, tabId, selector, or ref correctly, nor what an agent should expect after invoking it.

  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 only 25%, so the description must compensate. It adds valid-key examples and a sense of targeting, but it leaves key semantics, tabId, and selector behavior undocumented and does not clarify the relationship between ref, selector, and tabId.

  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?

  States a specific verb ('Press') and resource ('keyboard key') with examples, and identifies the target as focused or specific element. This generally distinguishes it from mouse/text siblings like session_click and session_type, though it doesn't name them explicitly.

  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 examples (Enter, Tab, Escape) imply it is for special-key presses, and 'on the focused element or a specific element' gives targeting context. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives such as session_type for text input.

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

• session_evaluateB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that it executes JavaScript and returns a result, but fails to mention that code execution can be destructive, may cause navigation, could throw errors, or that the result format is unspecified. This is a significant gap for a powerful tool with no annotation guardrails.

  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, focused sentence that front-loads the core action and result. There is no filler or redundancy. While it is underspecified in other dimensions, conciseness itself is optimal for a tool of this simplicity.

  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 complexity of code execution, the description is incomplete. It lacks any statement about return value format, error handling, side effects, or whether tabId is required to select a non-active tab. Without an output schema or annotations, an agent cannot predict what the tool will actually return or how to handle failures, making it insufficient for reliable invocation.

  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?

  The schema provides no descriptions and coverage is 0%, so the description must compensate. It clarifies that 'code' is JavaScript to be executed, but does not explain 'tabId' at all — whether it targets a specific tab or defaults to the active one. The description adds minimal value beyond the bare schema, leaving the agent guessing about tabId semantics.

  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 executes JavaScript in the page context and returns the result. The verb 'execute' and resource 'JavaScript' are specific, and it is distinct from sibling tools like session_snapshot or session_read_page that read state instead of running arbitrary code. Even without explicit sibling differentiation, 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 Guidelines2/5

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

  The description offers no guidance on when to use this tool over alternatives. It does not mention that this is for arbitrary script execution, nor does it indicate when not to use it (e.g., preferring dedicated navigation or click tools). The absence of any contextual cue leaves the agent to infer applicability solely from the schema's existence.

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

• session_loginB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full disclosure burden. It mentions the prerequisite of the extension and Pro, but does not clarify side effects, such as whether retrieving credentials also creates a session, whether credentials are returned to caller, or why masterPassword might be needed. The word 'login' in the name suggests possible session mutation, but the description only says 'decrypt and retrieve'.

  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 short sentences with no fluff. The main action is front-loaded, and the requirement is stated directly. Every word earns its place.

  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?

  For a tool with no annotations and no output schema, this description is incomplete. It does not explain the optional parameters, the relationship with session_store_login, the return value, or the exact effect of calling it with mastePassword. An agent would likely struggle to know whether additional inputs are needed or what will happen after invocation.

  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?

  Only half of the parameters are described in the schema, and the description does not compensate for the undocumented tabId and masterPassword fields. It repeats 'domain' context already present in the schema and adds no meaning for the other parameters, especially masterPassword, which is likely relevant to decryption.

  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 ('Decrypt and retrieve') with a specific resource ('stored credentials for a domain'), making the tool's core function immediately clear. It also naturally distinguishes itself from siblings like session_store_login, which handles storing rather than retrieving credentials.

  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 a prerequisite ('Requires the extension and Pro') but gives no guidance on when to choose this tool over alternatives, such as session_store_login or session_navigate. There is no explicit 'when to use' or 'when not to use' context.

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

• session_clickB
  3.3/5.0
  Behavior2/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. 'Click' indicates a user-like interaction but does not disclose whether the click can trigger navigation, whether it waits for the page to settle, what happens if the element is not found, or whether it may invalidate a prior snapshot.

  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 with no wasted words. It immediately identifies the action and the two targeting options, making it easy to scan.

  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?

  There is no output schema and no annotations, so the description alone must make the tool fully understandable. It omits important operational context, such as tabId's meaning, whether a click waits for navigation, error behavior for invalid selectors, and whether the function returns a new snapshot or just a success indicator.

  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?

  The description adds some meaning for selector and ref by introducing 'CSS selector' and '@eN ref from a snapshot,' but the schema already states that ref is used instead of selector. The tabId parameter is completely undocumented in both the schema and the description, and with only 33% schema coverage, the description should compensate more.

  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 ('Click') and a specific resource ('an element'), and clearly identifies the two targeting methods: CSS selector or @eN ref from a snapshot. This makes the tool's purpose distinct from siblings like session_type or session_press without requiring the schema.

  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?

  Usage context is implied by the action itself: when you need to click an element, use this tool. However, the description gives no explicit guidance about when to prefer session_click over session_press, session_fill, or session_select, nor when to choose a CSS selector versus a snapshot ref.

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

• session_record_startB
  3.4/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 for behavioral disclosure. It only lists what events are captured; it does not mention that recording is an ongoing stateful operation, whether a returned sessionId is needed later, how to stop the recording, or any side effects on the page or browser.

  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 focused sentence that front-loads the action and resource and packs the relevant event scope into a short list. Every word contributes value with no filler.

  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?

  For a state-changing tool with no annotations and no output schema, the description is too thin. It omits the recording lifecycle (that recording persists until stopped), the need for a sessionId in later operations, and any prerequisite such as session_install. The sibling names hint at the workflow, but the description itself leaves those gaps.

  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?

  All three parameters are already fully described in the schema with 100% coverage, including defaults and optionality. The description adds no parameter-level meaning beyond the schema, so the baseline score of 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 uses a specific verb and resource — "Start recording user interactions on a tab" — and enumerates the captured event types (clicks, scrolls, keystrokes, form fills, navigations). This makes its purpose immediately clear and distinguishes it from sibling tools like session_record_stop and session_record_events.

  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 start verb implies this tool is used to begin a recording session, but the description gives no explicit guidance about when to use it versus related tools such as session_install, session_record_stop, or session_record_replay. Usage context is inferred from the tool name and siblings rather than directly stated.

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

• session_typeB
  3.4/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full disclosure burden. It does reveal a key behavioral trait (character-by-character simulation of keyboard input) that goes beyond the name, but it does not disclose side effects on existing contents, focus requirements, or timing behavior. Some transparency is present, but the absence of any side-effect or precondition guidance leaves it at a minimum-viable level.

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

  Conciseness4/5

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

  A single sentence with no wasted words; the core behavior is front-loaded and immediately understandable. It could be slightly more informative without becoming verbose, but as written it is appropriately sized.

  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 no annotations or output schema and only 25% parameter coverage, the description is too thin. An agent still lacks guidance on the relationship between required selector and optional ref, what tabId is for, and how the tool fits among the large sibling set. The schema partially covers this, but the description contributes little to fully invoking the tool correctly on the first try.

  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?

  Only one of four parameters (ref) has a schema description, and the tool description mentions none of the parameters. It fails to compensate for the 25% schema coverage by not linking 'text' and 'selector' to the described behavior, or explaining tabId's role. This is a significant gap for an agent trying to construct a correct call.

  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 ('Type') and resource ('a field'), and adds the qualifying details 'character by character' and 'simulating real keyboard input', which clearly distinguishes it from sibling session_fill or session_press. It tells an agent exactly what action the tool performs.

  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 niche (realistic, character-by-character input) but never states when to prefer it over session_fill or session_press, nor when not to use it. No explicit exclusions or alternative routing are given, leaving usage to be inferred from the behavioral hints.

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

• session_waitB
  3.4/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 of behavioral disclosure. It only says 'wait for a condition' and does not explain what happens on timeout, whether it throws or returns a status, whether it polls, or what the return value is. This is a significant transparency gap for a tool that can block for an arbitrary duration.

  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?

  One compact, front-loaded sentence communicates the core behavior and enumerates the condition types without wasted words.

  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 no annotations and no output schema, the description is too thin. It omits the default timeout, failure behavior, return value, and the meaning of tabId. An agent cannot reliably know whether a timed-out wait is an error or a normal outcome, which is essential for correct 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?

  Schema coverage is 50%, so the description needs to add meaning for undocumented parameters. It does clarify condition by naming the three modes and explains value as a URL substring or selector, but it leaves tabId completely unexplained and does not clarify the dependency between condition and value (e.g., value is unused for 'load').

  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?

  States precisely what the tool does: it waits for one of three conditions (load, URL match, selector presence). The verb 'wait' plus the condition types make the operation unambiguous and distinct from sibling navigation/read/snapshot tools.

  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 condition enum implies usage (e.g., wait after navigation or before interacting with a selector), but there is no explicit guidance on when to prefer this over alternatives, nor any mention of why one might choose it over session_health or polling via snapshot. Usage is inferable rather than stated.

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

• session_navigateA
  3.5/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 disclosure burden. It does add value by disclosing the tab-reuse behavior ('Reuses the active tab unless newTab is true') and the authenticated-session context. But it is silent on whether the call blocks until the page finishes loading, what happens on timeout or invalid URLs, and how an unauthenticated session is handled — all material for a navavigation 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?

  Two short sentences, front-loaded with the core action, and the tab-reuse caveat earns its place. Zero filler and nothing redundant with the schema.

  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?

  For a simple 3-parameter flat tool this is close to adequate, but with no output schema and no annotations, the missing wait-for-load and failure semantics leave an agent guessing about sequencing. It should state whether navigation completes before returning so the agent knows when subsequent read or interact tools can be issued.

  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% — url, tabId, and newTab all have meaningful schema descriptions. The description adds no new parameter-level detail (its newTab phrasing largely mirrors the schema text), so the baseline 3 applies.

  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?

  States a specific verb ('Navigate') and resource ('a tab ... in the user's authenticated session'), making the core action unambiguous. The second sentence adds the tab-reuse behavior, but it does not explicitly distinguish itself from the closest siblings like session_click or session_read_page.

  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?

  'Navigate a tab to a URL' implies the use case — directly loading a URL in the browser — which is reasonably clear. However, there is no explicit when-not-to-use guidance or routing to alternatives such as session_click for link-based navigation.

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

• session_screenshotA
  3.5/5.0
  Behavior3/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 usefully states the capture scope ('visible tab area') and the response format ('base64 PNG or JPEG'), which are important behavioral facts. However, it does not mention failure behavior, default format, or whether the operation has any side effects, leaving gaps for an agent to discover.

  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 with no filler. Every word contributes: the action, the scope, and the output format are all stated efficiently. It is appropriately sized for the information it provides.

  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?

  The tool has four optional parameters, no output schema, and no annotations, yet the description only covers the basic action and return format. It does not explain the effect of windowId, how format and quality interact, or what the default behavior is. An agent calling this tool correctly would need to rely on external knowledge or make assumptions.

  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?

  The description adds no parameter-level meaning. Two of the four parameters lack schema descriptions (format, windowId), and the description does not clarify their semantics, defaults, or whether quality only applies to JPEG. Since schema coverage is only 50% and the description does not compensate, the agent has limited guidance for constructing valid calls.

  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 verb ('Take a screenshot'), the resource ('visible tab area'), and the output format ('Returns base64 PNG or JPEG'). It is specific and self-contained, and among the sibling tools it is the only one that explicitly captures a screenshot, so there is no ambiguity about its purpose.

  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 use case is visual capture of the visible tab, but it does not explicitly state when to use this tool versus alternatives like session_snapshot or session_read_page. No exclusions or conditions are provided, so an agent must infer when a screenshot is the right choice.

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

• session_store_loginA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the disclosure burden. It states that credentials are encrypted and stored, and that extension/Pro are prerequisites. It does not explain whether an existing vault entry is overwritten, whether masterPassword is needed for vault access, or what output/errors to expect, so some key behavior is 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?

  One focused sentence with no filler; the primary behavior is front-loaded and the prerequisite is appended. Every word contributes.

  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 four parameters, no output schema, and no annotations, the definition is incomplete. It lacks parameter-level guidance, overwrite/merge behavior, return value, and failure states, and it does not address the ambiguity with sibling tools.

  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 0%, and the description must compensate. It only references 'credentials for a domain,' which roughly maps to domain/username/password, but it never explains domain, password, username, or the optional masterPassword parameter semantics.

  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 names a specific action ('encrypt and store'), a clear resource ('credentials for a domain'), and a destination ('the extension's vault'). This clearly separates it from the sibling session_login, which would perform an actual login, so an agent can identify this as a vault-persistence operation.

  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 use case: persist credentials in the vault. It also notes the prerequisite 'Requires the extension and Pro.' However, it does not explicitly say when to prefer this over session_login or other sibling tools, nor does it state when not to use it.

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

• session_record_stopA
  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 the full burden. It discloses the core side effect ('Stop a recording session') and the return value (event count and duration). It does not mention whether stopping is destructive/final, whether it persists captured events, or error behavior for non-existent sessions, so transparency is adequate but incomplete.

  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?

  A single, front-loaded sentence that states the action and the result with no filler. Every word contributes to the agent's understanding.

  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?

  For a one-parameter tool with no annotations and no output schema, the description gives the essential action and return value, and the schema covers the parameter. Still, the agent is left to infer lifecycle requirements (active session, relationship to session_record_start) and failure behavior, which would matter for correct 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?

  Schema description coverage is 100% and the sessionId parameter is already documented ('Session to stop; required only when multiple recordings are active'). The tool description adds no parameter-level meaning, so the baseline of 3 applies.

  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?

  Description opens with the specific verb 'Stop' and identifies the resource ('a recording session'), and it adds the distinctive outcome 'return the captured event count and duration.' This cleanly separates it from the session_record_start/list/events/replay siblings even without naming them.

  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 intended trigger is implied by the verb 'Stop': use this when an active recording should be ended. However, the description never states prerequisites (e.g., a prior session_record_start), when the optional sessionId is needed beyond the schema note, or what to do if no recording is active. It is implied usage, not explicit guidance.

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

• session_record_listA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description alone must disclose behavior. It implies a read-only operation by using 'List', but does not explicitly state there are no side effects, nor does it describe any constraints (e.g., scope of 'all' sessions). It provides basic but minimal behavioral context, adequate for a simple zero-parameter 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 a single concise sentence that front-loads the action and resource. There is no wasted text, and it is easily scannable.

  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 zero-parameter, no-output-schema tool, the description is reasonably complete. It specifies what is listed and the information returned. However, it lacks any mention of scope (e.g., all sessions for the current workspace or user) or ordering, leaving a minor ambiguity. Still, given the simplicity, it is adequate.

  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 and the schema is fully documented by being empty. The description adds no parameter-specific information because there are none to describe. Per the baseline for 0-parameter tools, this is sufficient.

  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 verb ('List') and resource ('recording sessions') along with the attribute ('their status'). It distinguishes from sibling tools like session_record_start/stop/events/replay, which are action-oriented, so an agent can easily tell this is the listing operation.

  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?

  No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparisons with sibling tools like session_record_events or session_record_replay. The agent must infer from the name and description when to call this.

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

• session_list_tabsA
  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 transparency burden. The verb 'List' clearly signals a non-destructive read operation, and the mention of returning ids, titles, and URLs gives a concrete sense of the output. It does not discuss edge cases or session prerequisites, but for a simple read-only 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?

  A single, information-dense sentence with no filler. It front-loads the action and then lists the exact output fields, making every word valuable.

  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 zero-parameter tool with no output schema, the description explains both the operation and the expected return contents (ids, titles, URLs). It lacks only minor details like ordering or empty-tab behavior, which are not essential 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?

  The tool has zero parameters, so there is no parameter semantics burden. The baseline of 4 applies because the description correctly omits parameter details that cannot exist.

  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 states a specific verb ('List') and a clear resource ('all open browser tabs') with the exact output fields (ids, titles, URLs). It is clear and self-sufficient, though it does not explicitly distinguish itself from sibling tools like session_snapshot or session_read_page.

  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?

  Usage is implied: an agent would use this tool when it needs an inventory of open tabs. However, there is no explicit guidance about when to prefer this over siblings, nor any mention of alternatives or exclusion conditions.

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

• session_selectA
  4/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 burden of behavioral disclosure. It reveals that the tool selects via value/text/index and that attempting to type into a select has no effect, which is useful behavioral context. However, it does not disclose what happens when no matching option is found, whether the selection triggers change events, or any waiting/error 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 a single focused sentence that leads with the core action and immediately clarifies the selection methods. The second sentence earns its place by preventing a common misuse. No filler or redundant restatement of the tool name.

  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 relatively simple select action, the description covers the action, the element type, and the selection strategies, and it warns against a common mistake. It is missing minor behavioral details like failure handling and does not describe the tabId parameter, but overall an agent has enough information to invoke the tool correctly in most cases.

  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 documentation covers 83% of parameters and already defines text, index, value, and selector. The description adds a high-level summary of selection modes but does not materially expand on the schema's parameter descriptions. The uncovered tabId parameter is not explained, so the description does not compensate for the small gap.

  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 ('Choose') with a specific resource ('an option in a <select> dropdown') and enumerates the selection modes: by value, visible text, or index. It also distinguishes itself from text filling with the warning that filling a select as a text field does nothing, which separates it from sibling tools like session_fill.

  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 indicates when to use the tool: when the target is a <select> dropdown, and how to select the option (by value, text, or index). It implies an exclusion from text-field workflows with 'Filling a select as though it were a text field does nothing,' though it does not explicitly name alternatives like session_fill.

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

• session_healthA
  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 behavioral burden. 'Check' signals a non-mutating inspection, and it specifies what is inspected (extension health and API availability) and the context ('connected session'). It does not explicitly guarantee a read-only profile or describe failure behavior, but for a zero-parameter diagnostic this 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?

  A single front-loaded sentence with no filler. The action, subject, and scope are all present, and every word contributes to the meaning.

  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, parameterless health check, the description is largely complete: it names both the action and the information returned. It would be slightly stronger if it mentioned expected failure modes or the response format, but since there is no output schema, those are minor gaps rather than blockers.

  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 no parameters and the schema already provides 100% coverage with an empty properties object. With zero parameters, there is nothing for the description to add, so the baseline of 4 applies.

  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 concrete verb, 'Check', and a specific resource: extension health plus browser API availability in the connected session. This clearly distinguishes it from sibling tools like session_navigate or session_evaluate, none of which are framed as health diagnostics.

  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?

  Usage is implied: an agent should call this when it needs to verify that the extension is healthy or determine which browser APIs are usable before proceeding. It does not explicitly state when not to use it or name alternatives, so the guidance relies on inference.

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

• session_installA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It transparently conveys that the tool only returns instructions and does not need a live session. It could go further by explicitly stating it makes no system changes, but 'Return installation instructions' strongly implies a read-only informational action.

  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 short sentences with no filler. The action and target are front-loaded, and the key precondition is stated immediately after, making it easy to scan.

  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, no-output-schema tool, the description provides everything an agent needs: what it returns, for which components, and the session requirement. There are no hidden prerequisites or additional behavioral details that would affect 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?

  The tool has zero parameters and an empty input schema, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter documentation is needed.

  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 ('Return installation instructions') and names two clear resources: the T3rnel Browser extension and the standalone automation browser. It is immediately distinguishable from the session_* sibling tools, which are runtime operations rather than setup instructions.

  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 clear usage context by stating that no active browser session is required, implying this tool is appropriate before or without a session. It does not explicitly name alternatives or exclusions, but the context is clear enough given the sibling set.

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