Server Quality Checklist

Tool Scores

• get_console_messagesA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of disclosure. It reveals the source mechanism (CDP Runtime) and the type of data returned (console.* and exceptions). However, it lacks information about potential side effects, authorization requirements, or rate limits, which are important for safe tool invocation.

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

  Conciseness5/5

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

  The description is two sentences long, front-loading the core purpose and adding a practical usage hint. Every sentence contributes information without redundancy or fluff, making it highly efficient for an agent to parse quickly.

  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?

  Given that there is no output schema, the description should ideally indicate the return format or structure of the console messages. It does not mention whether the returned data includes message text, timestamp, source, etc. While the schema parameters imply some output context, the description itself is incomplete for an agent to understand the full tool behavior.

  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 covers all parameters with descriptions, achieving 100% coverage. The description adds marginal value by mentioning the 'level' filter in context, but does not provide additional semantics beyond what the schema already conveys. Thus, it meets the baseline for high schema coverage.

  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 title and description explicitly state it returns console.* output and unhandled exceptions from the renderer, captured via CDP Runtime. This clearly distinguishes it from sibling tools like get_main_logs or get_network_requests by specifying the source (renderer) and content type (console messages and exceptions).

  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 provides a usage example with the 'level' parameter to filter errors, which implies when to use the tool. However, it does not explicitly state when not to use it or suggest alternative tools for different logging needs, leaving the agent to infer usage context.

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

• read_user_data_fileA
  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 must carry the burden. It discloses path-traversal protection, size cap, and return fields. However, it does not mention error behavior (e.g., file not found) or encoding, leaving gaps in behavioral understanding.

  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, no filler. The first sentence states purpose and location; the second covers protections and return. Perfectly front-loaded and efficient.

  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 no output schema, the description explains the return (text content and resolved path). It covers safety and size limits. It lacks error handling details, but for a simple read tool, it is reasonably complete.

  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% with clear param descriptions. The description adds value by giving examples of relPath values (config.json, api-logs/...) and explaining the maxBytes default. This goes beyond the schema's basic descriptions.

  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 the specific verb 'read' and resource 'file under userData', with examples like 'config.json'. It clearly distinguishes from sibling tools because no other tool reads files from userData.

  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 explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. There is no mention of prerequisites or exclusions.

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

• get_ipc_logA
  3.9/5.0
  Behavior3/5

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

  Describes the draining behavior and the content of returned entries, but lacks details on side effects (e.g., whether the buffer is cleared) and performance implications. With no annotations, more behavioral disclosure would be beneficial.

  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 concise sentences; the first covers action and prerequisite, the second describes entry structure. No redundancy or unnecessary details.

  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?

  Covers prerequisite and entry fields, but lacks information on result ordering (e.g., newest first), default behavior when limit/since omitted, and pagination. Given five parameters and no output schema, more completeness is needed.

  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 description adds minimal value beyond the schema's parameter descriptions. It provides context about the return value but does not enhance parameter understanding.

  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 drains pending IPC events and returns matching entries, specifying the verb and resource precisely. It distinguishes from sibling tools like get_console_messages and get_main_logs by focusing on IPC logs and requiring enable_ipc_logging.

  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?

  Explicitly mentions a prerequisite ('Requires enable_ipc_logging to have been called first'), providing clear context for when to use the tool. However, it does not discuss alternatives or 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.

• launch_via_npmA
  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 full burden. It discloses flag forwarding behavior and slower startup due to rebuild. However, it omits key traits like process lifecycle (background, needs stop_app), return behavior, and error handling. Adequate but not comprehensive.

  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 extremely concise: three sentences covering primary action, forwarding behavior, and usage context. No redundant words, main idea front-loaded. Excellent structure for quick comprehension.

  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?

  Given 8 parameters, no output schema, and no annotations, the description explains the primary use case and key behaviors. However, it lacks details on session management, return value, and post-conditions, which are important given the tool's complexity and sibling tools like 'stop_app'.

  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% with detailed parameter descriptions. The tool description adds context by explaining forwarding of specific flags and the slower startup reason in waitTimeoutMs. While helpful, it does not significantly enhance meaning beyond the schema, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool spawns an Electron app via npm script, specifies typical script ('start') and project type (electron-forge). It distinguishes from siblings by noting this is for forge workspaces where dev server must come up first. Purpose is highly specific and unambiguous.

  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 explicitly says 'Use this for an electron-forge workspace...' indicating when to use this tool. It mentions cwd must contain package.json and that forge rebuilds renderer, guiding usage. However, it does not explicitly state when NOT to use it (e.g., for direct binary launch).

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

• enable_ipc_loggingA
  4/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 of behavioral disclosure. It covers idempotency (no-op if proxy exists) and lifecycle (auto-reinstall on frame navigated). Missing a note on potential performance impact or whether it overwrites an existing manual proxy, but the key behaviors are 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 three focused sentences, each serving a distinct purpose: action, idempotency, and lifecycle. No wasted words, and the most critical info (what it does) is 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?

  For a tool that enables logging with no output schema, the description covers the essential aspects. It explains what it does, its safety (idempotent), and automatic reinstallation. It does not need to detail return values since there is no output schema. Slightly missing is how to stop logging or the format of logged data, but those are likely in sibling tools.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema provides. It does not explain the purpose of 'id' or 'target' or their relationship to the operation.

  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 injects a proxy over window.electronAPI to log all method calls into the IPC ring buffer. The verb 'inject' and resource 'window.electronAPI' are specific, and the scope (including user-triggered calls) adds precision. It naturally distinguishes from siblings like get_ipc_log (which reads logs) and clear_logs (which clears 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 explains that the tool is idempotent and safe to call multiple times, and that it auto-reinstalls after page navigation. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'call before get_ipc_log' or 'use this to start capturing log events'). The guidance is implied but lacks explicit comparison to sibling tools.

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

• get_main_logsA
  4/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 of behavioral transparency. It discloses that logs are interleaved in order of receipt, supports stream filtering, and has a default buffer limit (up to 5000 lines). Side effects are not mentioned, but likely none exist. It does not discuss rate limits or data persistence.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main purpose, and contains no extraneous text. Every sentence adds value.

  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 5 parameters, 100% schema coverage, no output schema, and no annotations, the description is fairly complete. It explains the content and ordering of logs, and mentions the buffer limit. It could be improved by clarifying session association (id parameter) or behavior when no logs exist, but overall it is adequate.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds some context about interleaving and default line count, but does not enhance individual parameter meanings beyond what the schema already provides. No per-parameter elaboration is present.

  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 it returns captured log lines (stdout+stderr interleaved) for a spawned process, and specifies typical content like main-process startup lines and backend/proxy output. This distinguishes it from siblings like get_ipc_log or get_console_messages.

  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 context by mentioning what the logs typically contain, but it does not explicitly state when to use this tool versus alternatives like get_ipc_log or clear_logs. No exclusions or when-not-to-use guidance is provided.

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

• list_electron_api_methodsA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavioral traits. It states the operation is a read-only listing (returns names), which is implicitly non-destructive, but does not explicitly mention safety, permissions, or side effects. The description is adequate for a simple listing but lacks explicit transparency.

  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 wasted words. The critical information is front-loaded and every sentence adds value.

  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 listing tool with no output schema, the description adequately explains what is returned (method names) and the role of the 'target' parameter (chosen renderer). It is complete enough for an AI agent to understand usage, though it could be slightly more explicit about the output format.

  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% with both parameters described. The description adds no extra meaning beyond the schema; it only explains the purpose of the return value. 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 explicitly states the tool returns method names on window.electronAPI. It uses a specific verb and resource, and distinguishes itself from sibling tools like invoke_electron_api by mentioning discovery before invocation.

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

  Usage Guidelines4/5

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

  The description provides clear scenarios: discovering IPC channels before calling invoke_electron_api and verifying preload changes. It implies when to use this tool over alternatives, but does not list explicit exclusions or 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.

• list_windowsA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It correctly indicates this is a read-only listing operation and explains that workers are included. However, it does not mention potential error conditions, session requirements, or limits on the number of targets.

  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 highly concise: two sentences that front-load the purpose, provide a critical output interpretation hint, and mention workers. 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?

  Given the tool has two parameters and no output schema, the description completes the picture by explaining output types and downstream usage. It could mention pagination or error cases but is adequate for the tool's simplicity.

  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 covers 100% of parameters with descriptions. The description adds semantic value beyond the schema by explaining how to interpret results (type field mapping to BrowserWindows) and how to use output ids for other tools. This enriches the parameter meaning.

  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 enumerates CDP targets from a session's debug port, distinguishes between 'page' types (BrowserWindows) and workers, and provides actionable guidance (passing ids to evaluate/navigate/screenshot). This differentiates it from sibling tools like 'list_apps' and action 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 description implicitly tells when to use this tool (to list targets before using evaluate/navigate/screenshot) but does not explicitly state when not to use it or compare with alternatives. No explicit usage boundaries or prerequisites are given.

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

• ping_inspectorA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden. It discloses that it opens the inspector and evaluates process.pid, returning the pid on success. However, it does not mention side effects (e.g., whether the inspector remains open), error scenarios, or authorization needs, making it adequate but not rich.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action, and then provides usage context. Every word earns its place with 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?

  Given no output schema and no annotations, the description is mostly complete for a simple ping-like tool. It explains the action, return value, and a usage condition. However, it lacks details on potential errors or whether the inspector is closed afterwards.

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

  Parameters3/5

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

  The input schema has 100% coverage with a single parameter 'id' described as 'Session id.' The description does not add any additional meaning or context beyond the schema, so a 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 clearly states the tool opens the Node inspector on the session's main process and evaluates process.pid, returning the pid. It is specific, uses a verb+resource structure, and differentiates from siblings by mentioning a specific use case (when get_app_paths times out).

  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 explicitly says to use this tool when get_app_paths times out to isolate if the inspector is the problem. This provides clear context and a conditional usage guide, though it does not mention when not to use or list alternatives beyond the sibling.

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

• screenshotA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description discloses use of 'Page.captureScreenshot' and that it returns base64, hinting at payload size. However, it lacks details on permissions, side effects, or whether it is read-only. Some behavioral context is given but not comprehensive.

  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 succinct sentences. First sentence states core action and method, second provides key tip. No unnecessary words. Perfectly front-loaded.

  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 description explains return format (base64) and hints at full-page mode, but does not cover all parameters or expected output beyond base64. Given no output schema and moderate parameter count, it leaves some gaps for an agent to infer, but is minimally viable.

  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 baseline is 3. The description adds value by noting that 'fullPage: false' is the default and preferred for quick-look, which goes beyond schema descriptions. It also mentions base64 return, aiding parameter comprehension.

  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 it captures a screenshot of a target renderer using specific verb 'Grab' and resource 'screenshot of a renderer'. It uniquely identifies the tool among siblings like 'list_windows' and 'evaluate'.

  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 practical guidance: prefer 'fullPage: false' for quick-look snapshots due to large payloads. This helps the agent decide when to use the default mode, though it does not explicitly exclude alternatives or state when not to use the tool.

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

• clear_logsA
  4.2/5.0
  Behavior3/5

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

  No annotations provided, so the description carries full burden. It correctly indicates a destructive action ('wipe') but does not disclose side effects, reversibility, or required permissions. Acceptable for a low-complexity 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 sentences with zero wasted words. Action is front-loaded ('Wipe...'). Every sentence adds value.

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

  Completeness4/5

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

  Given the tool's simplicity (2 params, no output schema), the description covers purpose, usage hint, and default behavior. Could mention that cleared data is irrecoverable, but overall 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?

  Schema covers both parameters with descriptions. The description adds the important default behavior ('Omit `kinds` to clear everything'), which is not in the schema and helps the agent understand invocation.

  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 ('Wipe session ring buffers') and resource, and explicitly distinguishes the tool from sibling read-only tools like 'get_main_logs' by framing it as a reset action ('set a zero point').

  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?

  Provides explicit when-to-use guidance ('useful to set a zero point before driving an action') and a clear default behavior note ('Omit `kinds` to clear everything'). Lacks explicit when-not-to-use or alternatives, but context implies it's for clearing vs. reading logs.

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

• invoke_electron_apiA
  4.2/5.0
  Behavior3/5

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

  Describes that the result is awaited if it's a promise, but does not disclose potential side effects or destructiveness. Since annotations are absent, the description could be more transparent about risks associated with invoking arbitrary methods.

  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 an inline example. Every sentence is informative and front-loaded with the main purpose.

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

  Completeness4/5

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

  Adequately describes input and return behavior. Could mention error handling or security considerations, but for a testing tool it is sufficient given the tool's simplicity.

  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 baseline is 3. The description adds value by giving specific method name examples and noting that args must be JSON-serialisable, which is not in the schema.

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

  Purpose5/5

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

  Clearly states it invokes any method on window.electronAPI and includes concrete examples like dbCheckConnectivity and getConfig. Distinguishes from sibling evaluate by focusing on pre-exposed bridge methods.

  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?

  Explicitly says 'Use to test IPC handlers directly', providing a clear use case. However, it does not mention when not to use it or how it compares to alternatives like evaluate.

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

• navigateA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses that it waits for the frame's `loadEventFired` before returning, which is a key behavior. No contradictions.

  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 that are front-loaded with the action, followed by usage context and behavior. No unnecessary words.

  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 4 parameters (2 required), full schema coverage, and no output schema, the description explains the main purpose and wait behavior. It could mention the `target` and `waitLoadTimeoutMs` parameters, but the schema covers them adequately.

  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 all 4 parameters. The description adds no parameter-specific details beyond mentioning URL types. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it calls `Page.navigate` on the target renderer, with specific verb and resource. It distinguishes from scripting button clicks, and no sibling tool does navigation, so 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 Guidelines4/5

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

  The description explains it's useful for driving the app into a specific view without scripting a button click, and gives URL examples. It implies when to use but does not explicitly state when not to or list alternatives beyond 'scripting a button click'.

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

• stop_appA
  4.2/5.0
  Behavior4/5

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

  Without annotations, the description carries the full burden. It transparently states behavior (close clients, kill process if launched by MCP, no-op if already stopped). It does not cover all possible side effects but provides sufficient detail for an agent.

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

  Conciseness5/5

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

  The description is concise with two sentences. It front-loads the essential action and includes a usage hint without unnecessary words.

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

  Completeness4/5

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

  Given the tool's low complexity, the description is reasonably complete. It covers the main behavior and safety. However, it does not specify the return value, which could be useful.

  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 description is not required to add parameter details. The description does not elaborate on the parameters beyond 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 states the tool's action: closing CDP clients and killing the process. It specifies the resource (debug session) and distinguishes it from sibling tools like launch_app and list_apps.

  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 use case: unconditional cleanup flows, and notes it is a no-op for already-stopped sessions. However, it does not explicitly mention when not to use or contrast with alternative tools.

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

• get_app_pathsA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses the inspector requirement, which is a key behavioral constraint. It also lists all returned values, providing good transparency for a read-only operation. No hidden side effects are mentioned, but none are expected.

  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, efficiently structured: first sentence enumerates outputs, second states prerequisite. No filler, front-loaded with key information.

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

  Completeness5/5

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

  The description fully explains what the tool returns and the prerequisite for successful execution. No output schema exists, but the listed items sufficiently cover expected results. Low complexity with a single parameter makes this complete.

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

  Parameters3/5

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

  The input schema has 100% description coverage for the one parameter ('id'). The description does not add additional meaning beyond 'Session id.' from the schema. Baseline of 3 is appropriate given full schema coverage, but no extra clarity is provided.

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

  Purpose5/5

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

  The description clearly states the tool returns Electron app paths and flags, listing specific paths and properties. It unambiguously distinguishes itself from sibling tools like 'get_console_messages' or 'get_ipc_log' by focusing on file system paths and app metadata.

  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 specifies when to use (to retrieve app paths) and includes a critical prerequisite (inspector must be attached). It doesn't explicitly state when not to use or offer alternatives, but the context is clear enough for an AI agent.

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

• launch_appA
  4.3/5.0
  Behavior4/5

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

  No annotations, so description carries full burden. It discloses the flags set (`--remote-debugging-port`, `--inspect`), default port ranges, and wait timeout. However, it lacks details on error behavior (e.g., if ports fail) or side effects.

  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, front-loaded with the primary action and flags, then the alternative tool mention. No wasted words.

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

  Completeness3/5

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

  With 8 parameters and no output schema, the description should cover what the tool returns. It does not mention return values or session handling, leaving a gap in completeness.

  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% with each parameter described. The tool description adds no additional parameter meaning beyond what's already in the schema, meeting the baseline expectation.

  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 clearly states it spawns an Electron app with specific debugging flags. It distinguishes from sibling 'launch_via_npm' by specifying the use case (apps not needing forge dev-server or packaged test builds).

  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?

  Explicitly tells when to use 'launch_via_npm' instead (electron-forge projects) and when this tool is appropriate (apps without forge dev-server or packaged test builds).

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

• attach_appA
  4.4/5.0
  Behavior4/5

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

  Discloses the key behavioral fact that stopping the session does not kill the process. However, without annotations, it could also mention error handling or side effects like port probing failure. Still, the description effectively conveys lifecycle ownership.

  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 sentences, front-loaded with purpose, efficient and without 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?

  Given no output schema, the description covers prerequisites, behavior, and lifecycle. It could mention what the tool returns or how sessions are referenced later, but overall adequate for a registration tool.

  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 descriptions cover all parameters (100% coverage) with clear explanations. The description adds no additional semantic value beyond restating the port roles.

  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 it registers an already-running Electron instance as a debug session, distinguishing it from launch_app and stop_app. Verb 'register' and resource 'debug session' are specific.

  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?

  Explicitly explains the prerequisite (app started with specific flags) and that the tool only probes ports, not starts the app. Also clarifies that stop_app doesn't kill the process, preventing misuse.

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

• evaluateA
  4.4/5.0
  Behavior4/5

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

  Without annotations, the description carries the full burden. It reveals the CDP mechanism, equivalence to the DevTools console, the need for IIFE for statements, and the return-by-value behavior. It does not cover potential side effects or error scenarios, but provides adequate behavioral context for typical use.

  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 extremely concise with two sentences. The first sentence defines the action and mechanism, the second provides usage examples and scope. No redundant information, and it is front-loaded with the core purpose.

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

  Completeness4/5

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

  Given the tool's complexity and absence of an output schema, the description explains the return behavior (by value) and gives practical examples. It does not detail the result structure or error handling, but for an advanced tool, the provided context is sufficient for most use cases.

  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?

  With 100% schema coverage, the baseline is 3. The description adds value beyond the schema by providing example expressions (document.title, localStorage.getItem) and the IIFE note for statements, which enhances understanding of the expression parameter. This pushes the score to 4.

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

  Purpose5/5

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

  The description clearly states the tool runs a JavaScript expression in the target renderer's main JS world via CDP Runtime.evaluate and returns the result by value. It provides specific examples (DOM inspection, state reads) and distinguishes it from sibling convenience tools like click/type, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description gives clear use cases (DOM inspection, state reads, automation beyond click/type). While it does not explicitly list when not to use or name alternative sibling tools, the context and examples effectively guide the agent on appropriate usage.

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

• get_network_requestsA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It discloses that multiple entries share requestId and must be joined, and explains the default filter behavior. This gives good insight into how the data is structured and filtered. It could be more explicit about whether the returned list is a snapshot or live, but overall it's 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 three sentences with no wasted words. It front-loads the core purpose, then adds key behavioral info. Every sentence serves a purpose, making it efficient and easy to parse.

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

  Completeness4/5

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

  Given the tool has 9 parameters and no output schema, the description covers the essential data lifecycle (joining requestId) and default filtering. It does not explain output structure, but that is acceptable without an output schema. It provides enough context for an agent to use the tool effectively, except possibly for edge cases like pagination or limits.

  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 baseline is 3. The description adds value beyond the schema: it explains the default filter and how to override it with resourceType, gives an example for urlContains, and clarifies the relationship of events via requestId. This extra context helps the agent understand parameter interplay.

  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 it returns CDP Network events (request/response/finished/failed) and explains the relationship between entries via requestId. It is specific about the resource (network events) and the action (returns). Among sibling tools, this is the only one retrieving network activity, making its purpose distinct.

  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 useful usage context: default filter omits static assets, so only XHR/fetch calls surface, and you can override with resourceType. It implies when to use (for API requests) but does not explicitly state when not to use or compare to alternatives. However, given the sibling list, this tool is the only network-related one, so the context is sufficient.

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

• list_appsA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It clearly states it returns a snapshot, implying a read-only operation, but could mention if there are any side effects or performance considerations.

  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?

  Single sentence of 18 words, front-loaded with the action and result. No unnecessary information.

  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?

  Given no parameters, no output schema, and no annotations, the description is complete. It covers what is returned and the scope (all tracked sessions including launched and attached).

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

  Parameters5/5

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

  No parameters exist, and schema coverage is 100%. Description adds value by specifying the exact fields returned (pid, ports, status, uptime, tracked window count).

  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?

  Clearly specifies verb 'Return' and resource 'snapshot of every tracked session (launched + attached)' with explicit fields. Distinguishes well from sibling tools like launch_app and attach_app.

  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?

  Implies usage for getting a summary of all sessions, but no explicit when-to-use or alternatives are given.

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