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

With no annotations, the description carries the behavioral burden, and it adds a genuinely useful trait: locator-based calls auto-wait for visibility while coordinate calls are a fallback. It doesn't describe timeout failure behavior or the 'humanized' nature implied by the name, but it does disclose the most important runtime distinction for an agent to invoke it correctly.

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

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

Two short sentences, front-loaded with the action, and every clause contributes information about target selection or waiting behavior. There is no duplication of schema fields or filler.

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

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

For an 11-parameter tool with no output schema, the combination of the description and the fully documented schema is sufficient to invoke the tool: target_id, timeout, button, click_count, and locator options are all described. The main remaining gap is non-critical behavioral detail (failure/return behavior), so it is complete rather than exhaustive.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real grouping semantics beyond the field descriptions: 'pass one of' establishes mutual exclusivity, 'role + optional name' defines a compound locator, and 'raw x+y coords as fallback' states precedence. This makes the parameter surface easier to reason about than the flat schema alone.

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

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

The description names a concrete action and object ('Click an element') and enumerates the accepted targeting strategies. That verb+resource statement is enough to tell it apart from sibling humanizer_type/move/scroll tools, and it is not a tautology.

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

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

The intended use is explicit: when a click is required, pass one of the listed locator forms or fall back to coordinates. It doesn't name sibling alternatives or exclusion cases, but the action is unambiguous and the locator-selection guidance is practical, meeting the 'clear context, no exclusions' bar.

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

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

No annotations are present, so the description carries the transparency burden. It discloses the synthetic nature ('simulate'), the exact behaviors (micro-jitter, occasional micro-scrolls), and the intended effect (avoiding idle detection). It could add caveats about visible cursor movement or detection limits, but the core behavior is clear.

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

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

Two short sentences with no wasted words. The first sentence front-loads the action and mechanism; the second gives the purpose. It is appropriately sized for the tool's complexity.

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

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

For a simple simulation tool, the description plus fully described schema is enough to select and invoke it correctly. The only minor gap is that with no output schema, it does not state whether the call blocks for duration_ms or returns immediately, but that is unlikely to block correct usage.

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

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

Schema coverage is 100% and each parameter already has a useful description, including the intensity enum's exact jitter ranges. The tool description adds no parameter-level meaning beyond restating the general behavior, so the baseline score applies.

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

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

The description states a specific verb and resource: simulate idle behavior, with concrete mechanisms (mouse micro-jitter and occasional micro-scrolls). This clearly separates it from sibling tools like humanizer_move or humanizer_scroll by framing the actions as idle-simulation rather than deliberate interaction.

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

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

The description gives an explicit context for use: keep the page 'alive' to avoid idle detection by bot-detection scripts. It does not, however, name alternatives or state when not to use it, so it stops short of full routing guidance.

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

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 only states the movement happens 'via the backend Playwright page' but does not say whether the movement is humanized/animated, whether it blocks until complete, or what happens on invalid coordinates or a missing browser target.

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

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

A single sentence with no filler; the action, object, and destination are all front-loaded. Every word contributes meaningfully.

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

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

For a straightforward pointer-move tool, the description plus fully documented schema is minimally viable. However, it leaves implicit the coordinate space (viewport vs page), the need for a previously launched browser, and any return/error behavior, which would be useful given there is no output schema or annotations.

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

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

Schema description coverage is 100%, so x, y, and target_id are already well documented. The description's 'target coordinates' phrase adds no new parameter detail beyond what the schema provides, 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.

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

The description uses a specific verb ('move') with a clear object ('mouse') and destination ('target coordinates'), making the action unambiguous. It is easily distinguishable from siblings like humanizer_click, humanizer_type, and humanizer_scroll, which involve different UI interactions.

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

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

No guidance is given about when to use this tool versus alternatives such as humanizer_click, which likely also involves mouse movement before clicking. Prerequisites, such as requiring an active Playwright page from interceptor_browser_launch, are not mentioned beyond the schema's target_id reference.

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

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

No annotations are present, so the description carries the disclosure burden, and it does disclose the key behavior: exactly one raw wheel event is dispatched, not a smooth multi-step scroll. It is honest about the primitive nature and does not oversell humanization.

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

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

Two short clauses with no filler; the core action is front-loaded and the 'raw ... single event' qualifier earns its place by setting expectations. It is appropriately sized for the tool's simplicity.

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

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

For a low-complexity event dispatcher with fully documented parameters, the description covers the essential context: what it sends, and that it is not a multi-step humanized sequence. It doesn't spell out return/error behavior, but that is minor at this complexity.

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

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

Schema coverage is 100%, with delta_x, delta_y, and target_id all described in the schema, so the description need not add parameter detail. The description itself adds no parameter-specific meaning beyond calling it a wheel event.

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

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

It states exactly what it does with a specific verb and resource ('Dispatch a wheel event') and adds that it is the raw page.mouse.wheel primitive rather than a multi-step action. This distinguishes it from the humanizer_move sibling, though it does not name the sibling explicitly.

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

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

There is no explicit guidance about when to use this tool instead of alternatives; 'single event, not multi-step' implies a contrast with higher-level scrolling but never names humanizer_move or states selection conditions. An agent is left to infer usage from the name and sibling list.

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

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

The description adds a useful behavioral detail: typing targets whatever element currently has focus and uses keyboard events via page.keyboard.type. Since no annotations are provided, this helps, but it does not state what happens when nothing is focused, whether existing text is replaced or appended, or what side effects typing may cause.

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

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

A single sentence that front-loads the action and no filler. It is minimal but every word contributes to the core behavior.

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

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

The tool is simple and the schema covers all parameters, so the basic call contract is visible. However, with no output schema and no annotations, the description omits return/error behavior and failure conditions such as missing focus or inactive browser.

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

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

Schema description coverage is 100%, so text, delay_ms, and target_id are already documented in the schema. The description adds only the 'focused element' context and no further parameter-level semantics.

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

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

States a concrete action ('type') and a resource ('focused element') plus the Playwright mechanism ('page.keyboard.type'). The verb distinguishes it from sibling humanizer_click/scroll/idle, though it doesn't explicitly name an alternative tool.

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

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

No guidance on when to choose this tool over humanizer_click/evaluate or how to prepare the element to receive focus. Use is only implied by the tool name and sibling set, not explicitly described.

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

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

With no annotations provided, the description carries the full burden and does so well. It explicitly warns that the tool injects a real DOM node visible to MutationObserver, document.scripts, and CSP, which is a critical behavioral trait an agent cannot infer from the schema.

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

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

The description is compact and front-loaded: the core action and Playwright mapping come first, followed by a high-value warning and sibling alternative. Every sentence earns its place with no redundant wording.

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

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

For a relatively simple injection tool with fully documented parameters, the description provides the key behavioral warning and the main alternative. The absence of an output schema is acceptable here since the critical operational concern is the DOM-visible side effect, which is covered.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters and the enum values. The description adds little parameter-specific detail beyond identifying the underlying Playwright behavior, so the baseline 3 is appropriate.

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

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

The description begins with a specific verb and resource: 'Append a <script> element to the current page,' and grounds it in Playwright's page.addScriptTag. It clearly identifies what the tool does and distinguishes it from the sibling interceptor_browser_inject_init_script by highlighting the DOM-node difference.

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

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

It gives explicit usage guidance: avoid for anti-bot stealth and prefer interceptor_browser_inject_init_script when page-scope execution is needed. This directly routes an agent to the correct sibling tool and states the condition that should trigger the alternative.

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

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

No annotations are provided, and the description only states the action without revealing side effects or permissions. For a close operation, this is adequate but could be more transparent.

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

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

The description is a single concise sentence with no unnecessary words, effectively communicating the tool's purpose.

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

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

For a simple tool with one parameter and no output schema, the description provides all necessary context: what it closes and how to identify the instance.

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

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

The schema has 100% coverage, and the description adds context by specifying that target_id comes from interceptor_browser_launch, going beyond just repeating the schema.

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

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

The description clearly states the verb 'close' and the resource 'browser instance launched by interceptor_browser_launch'. It distinguishes from sibling tools by referencing the specific launch tool.

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

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

Implicitly indicates it is used to close a browser opened by interceptor_browser_launch, but no explicit alternatives 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.

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

With no annotations, the description carries the full burden. It discloses the isolated utility world, that reads are invisible, that mutations to shared prototypes/globals are observable, and that each call emits CDP traffic counted by behavioral scorers. It does not cover error handling or return format explicitly, but the schema hints at JSON-stringified results. This is above-average transparency.

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

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

The description is concise and front-loaded with the core purpose. Each sentence adds value: execution, wrapping, isolation, visibility, alternative, and rate-limit caution. It could be slightly trimmed, but nothing is wasteful.

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

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

Given the complexity of browser JS execution and the lack of an output schema, the description covers key aspects: isolation, return mechanism, and an important usage constraint (rate limiting). It doesn't detail error scenarios or exact return formatting, but the schema for value_max_chars implies JSON-stringified output. Overall, sufficient for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: the file body is wrapped in an arrow function and can return a value via `return`, and args are available as `__args`. These details explain how the parameters are used, exceeding the schema's basic descriptions.

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

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

The description states a specific verb+resource ('Execute a JS file in the page and return its result') and distinguishes itself from the main-world patching tool by naming interceptor_browser_inject_init_script as the alternative for that use case. It clearly identifies what the tool does and what it is not for.

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

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

The description explicitly directs the agent to use interceptor_browser_inject_init_script for main-world patching, which implies this tool is for the isolated utility world. It also warns about rate-limiting before reCAPTCHA. It doesn't cover all alternative tools (like add_script_tag), but the most relevant distinction is made.

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

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

No annotations, so description must disclose behavior. Mentions 'full value' and 'hard cap', but lacks details like truncation behavior, auth requirements, or rate limits.

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

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

Single sentence, front-loaded with verb and resource. No extraneous words.

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

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

No output schema; description mentions 'full value' but not structure. Adequate for a simple retrieval tool, but could specify return format or error handling.

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

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

Schema has 100% description coverage. Description adds little beyond restating the key parameters (cookie_id) and the cap concept. Baseline 3.

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

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

Clearly states action ('Get'), resource ('one cookie'), identifier ('by cookie_id'), and constraint ('hard cap'). Distinct from sibling tools like list_cookies.

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

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

Implicitly suggests usage after list_cookies (cookie_id from there). Mentions hard cap for output bounding, but no explicit when-not or alternatives.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Get', implying a read operation, but does not mention whether it requires prior capture, what happens if the field_id is invalid, or any side effects. The default max_chars is in schema but not described. Missing critical behavioral context.

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

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

A single sentence that is concise and front-loaded with the core purpose. No redundant or irrelevant information. Every word contributes to understanding the tool's function.

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

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

Without an output schema, the description should clarify the return format (e.g., string value, JSON). It mentions 'full header field value' but doesn't specify if it's the raw header line or just the value. Error scenarios are not covered. Adequate for a simple getter but could be more thorough given the tool's role in a complex proxy workflow.

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

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

The input schema has 100% coverage with descriptions for all parameters. The description adds no additional meaning beyond the schema; it does not explain what constitutes a 'full header field value' or how to interpret the returned value. Baseline 3 is appropriate as the schema already defines the parameters.

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

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

The description clearly states the verb 'Get' and the resource 'one full header field value from proxy-captured traffic', with the method 'by field_id'. This distinguishes it from sibling tools like interceptor_browser_list_network_fields which lists fields, and other tools that capture traffic. The purpose is specific and actionable.

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

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

No guidance on when to use this tool versus alternatives (e.g., when to get a single field vs. listing all fields). No mention of prerequisites, such as having captured traffic first, or when not to use this tool. The description is purely declarative without usage context.

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

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

No annotations provided. The description does not disclose behavioral traits such as whether the tool returns null for missing keys, errors on invalid storage type, or has side effects. With no annotations, the description carries the full burden but offers minimal transparency.

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

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

A single, front-loaded sentence that conveys the core action efficiently. No redundant words or filler. Every word contributes meaning.

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

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

Given 5 parameters and no output schema, the description is minimally adequate. It explains the resource and key parameter but omits return format, error conditions, or handling of optional parameters like origin or value_max_chars. Overall, functional but leaves room for exploration.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it only reiterates the item_id parameter. No parameter format, constraints, or dependencies are clarified beyond what the schema provides.

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

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

The description clearly specifies the verb 'Get', the resource 'one localStorage/sessionStorage value', and the key parameter 'item_id'. It distinguishes this tool from siblings like 'interceptor_browser_list_storage_keys' which lists keys rather than values.

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

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

No guidance on when to use this tool versus alternatives (e.g., when needing all keys or bulk values). No mention of prerequisites like a launched browser or storage context. The description lacks contextual cues for appropriate invocation.

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

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

With no annotations provided, the description carries the full behavioral burden and does it well. It discloses the isolated utility world execution, the absence of a DOM artifact, that prototype/global patches reach the main world via utility-world sharing, and the critical caveat that the current document is unaffected. This is rich, non-obvious behavior beyond what the schema reveals.

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

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

Three dense sentences with zero filler. The core action and timing are front-loaded, followed by the isolated-world behavior and the navigation caveat. Every sentence earns its place.

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

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

For a two-parameter action with no output schema, the description provides everything an agent needs to invoke it correctly: target_id and script_path are covered by the schema, and the description explains when it runs, where it runs, and the key limitation about the current document. No critical operational detail is missing.

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

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 reinforces the meaning of script_path by explaining when it executes, but it does not add parameter-specific semantics beyond what the schema already states. target_id is adequately documented in the schema as coming from interceptor_browser_launch.

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

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

The description states a specific verb and resource ('Inject a JS file as an init script') and clarifies the exact execution timing. It effectively distinguishes this tool from one-off injection/evaluation tools like interceptor_browser_add_script_tag and interceptor_browser_evaluate by emphasizing it runs on every subsequent navigation/frame and not the current document.

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

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

The description clearly conveys when to use the tool: when a script must run before page scripts on every future navigation/frame. It also gives an exclusion by noting it does not affect the currently loaded document and instructs to navigate again to apply. It stops short of explicitly naming sibling alternatives, but the context is clear.

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

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

With no annotations, the description carries the burden. It discloses behavioral aspects: launching with proxy and SPKI trust, source-level fingerprint patches, humanize mode, and Playwright driving. However, it lacks details on side effects, prerequisites (e.g., proxy setup), error conditions, or return value.

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

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

The description is exceptionally concise: two sentences (40 words) with no filler. Every word adds value: first sentence states purpose and key features, second clarifies technical driver and subsequent tool usage. It is front-loaded and efficient.

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

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

Given the lack of output schema and annotations, the description should cover return values and setup dependencies. It mentions Playwright and locator tools but does not specify what the tool returns (e.g., browser session ID) or prerequisites (e.g., proxy configuration). This is adequate but has clear gaps.

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

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

Input schema has 100% description coverage for all 8 parameters, each with defaults and one enum. The description does not add additional 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.

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

The description clearly states the tool 'launch[es] cloakbrowser (stealth Chromium)' with specific features (proxy flags, SPKI trust, fingerprint patches, humanize mode). It differentiates from sibling tools like interceptor_camoufox_launch by specifying the browser type and mentioning Playwright-driven locator tools.

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

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

The description implies the tool is for launching a stealth browser for tasks requiring fingerprint protection and humanization, but it does not explicitly state when to use this tool versus alternatives (e.g., interceptor_camoufox_launch) or mention scenarios where it should not be used.

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

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

No annotations provided. Description mentions 'buffered since browser launch' but does not disclose whether reading clears the buffer, any side effects, or other behavioral traits beyond listing. Full burden falls on description; significant gaps.

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

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

Single sentence plus type enumeration. Extremely concise and front-loaded with purpose. Every piece of information earns its place.

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

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

Adequate for basic understanding of purpose. Missing return format details (no output schema) and no explanation of pagination or filtering behavior beyond parameter descriptions. Could be more complete given five parameters.

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

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

Schema coverage is 100%, and the description adds minor value by listing example console types (log, info, warning, debug) beyond schema. However, no additional semantics are provided for other parameters beyond schema descriptions.

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

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

Description clearly states it lists console messages buffered since browser launch and enumerates types. Name and description align well. Among siblings like interceptor_browser_list_cookies, it distinguishes by resource (console) but does not explicitly differentiate usage.

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

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

No guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., needing a launched browser), when not to use, or relationship to other list tools. Usage context is only implied.

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

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

With no annotations, the description carries full burden but only discloses pagination and truncated value previews. It does not explicitly state that the operation is read-only or that it requires an active browser context, though the target_id parameter implies the latter.

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

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

The description is a single sentence that is front-loaded with the core action and key features. It contains no unnecessary words, making it highly concise.

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

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

Given 9 parameters and no output schema, the description is insufficient. It omits details about filtering parameters (url_filter, domain_filter, name_filter), sorting, and any information about the response format. The agent would need to infer too much from the schema alone.

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

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 context by mentioning pagination and truncated value previews, which relates to parameters like offset, limit, value_max_chars, and full. This provides meaning beyond the schema's individual parameter descriptions.

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

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

The description clearly states it lists cookies from the browser context, which is a specific verb+resource. It also mentions pagination and truncated value previews, but does not explicitly distinguish from the sibling tool 'interceptor_browser_get_cookie' which retrieves a single cookie.

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

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 like 'interceptor_browser_get_cookie' or other filtering tools. The description does not mention when to use this for bulk listing versus single retrieval.

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

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

No annotations exist, so the description carries full burden. It discloses read-only behavior (listing), pagination, and value truncation. It does not mention side effects, but since it's a list operation, none are expected. The description is transparent about scope and features.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and key features. No redundant words or information.

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

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

Given the tool's complexity (10 parameters, multiple filters, no output schema), the description provides a high-level summary but omits details like filter combination logic, result ordering, and behavior when no results match. Schema covers parameter semantics, but behavioral completeness could be improved.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds context about pagination and truncation, but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it lists request/response header fields from proxy-captured traffic since browser launch, with pagination and truncation. This distinguishes it from sibling tools like interceptor_browser_get_network_field and proxy_list_traffic.

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

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

The description provides no guidance on when to use this tool versus alternatives like interceptor_browser_get_network_field or proxy_list_traffic. It does not mention prerequisites or exclusion criteria, leaving the agent to infer context from the name alone.

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

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

No annotations provided, so the description must bear the full burden. It discloses read-only behavior and the truncation feature but omits potential errors, permission requirements, or performance impact. Schema already covers parameters.

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

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

Single sentence that efficiently conveys the core purpose and key features. No redundant or extraneous information.

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

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

Given 7 parameters and no output schema, the description explains the main goal (list keys with truncated values) but does not specify the output format (e.g., list of key-value objects). However, the schema and inference from similar tools fill most gaps.

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

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 a summary of pagination and truncation, but does not provide additional meaning beyond what the schema already describes for each parameter.

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

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

The description explicitly states the action (list), resource (localStorage/sessionStorage keys), context (current origin), and notable features (pagination, truncated value previews). It clearly distinguishes from sibling tools that get a single value or list other storage types.

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

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 interceptor_browser_get_storage_value. The schema implies a prerequisite (target_id from interceptor_browser_launch) but the description does not mention it.

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

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

With no annotations, the description carries the burden but only mentions navigation and optional proxy wait. It omits details on error handling, side effects, or idempotency.

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

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

Single sentence, concise and front-loaded with the main action, but could benefit from slight restructuring to highlight key information.

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

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

Given 6 parameters and no output schema, the description lacks context on behavior, error handling, and parameter interplay, leaving gaps for the agent.

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

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

All parameters have schema descriptions (100% coverage), so the description adds little extra meaning beyond restating the tool's purpose.

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

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

Description clearly states the action (navigate) and resource (browser target's page) using Playwright, and distinguishes from sibling browser tools like close or screenshot.

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

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

Description implies usage context (after browser launch, using target_id) but does not explicitly state when to use vs. other tools or conditions that may affect behavior.

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

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

No annotations are provided, so the description carries the burden. It discloses the key behavioral trait: saving to file or reporting byte count. However, it does not mention if the tool waits for page load, timeouts, or whether it is destructive (though screenshots are generally read-only). The term 'bound page' is somewhat ambiguous.

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

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

Two sentences with no wasted words. The most important information (action, conditional behavior) is front-loaded. Every sentence adds value.

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

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 the return behavior (byte count) but lacks details on error handling, page load waiting, or differentiation from sibling interceptor_browser_snapshot. The complexity is low, so it is adequate but not thorough.

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

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

Input schema has 100% coverage for all 5 parameters, so baseline is 3. The description adds value by explaining the conditional role of file_path, but does not elaborate on format, full_page, or quality beyond what the schema already provides.

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

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

The description clearly states the action ('take a screenshot'), resource ('bound page'), and conditional behavior (file path or byte count). It is specific and distinct from sibling tools like interceptor_browser_navigate or interceptor_browser_evaluate.

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

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

The description implies usage after launching a page but does not provide explicit guidance on when to use this tool versus similar alternatives like interceptor_browser_snapshot. No when-not-to-use or exclusion criteria are given.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It describes the output format but does not mention any side effects, permissions required, rate limits, or potential destructiveness. The description implies a read-only operation but lacks explicit statements.

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

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

The description is a single sentence that conveys the core purpose and value proposition without any fluff. It is appropriately sized and front-loaded with the key action and output format.

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

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

Given the low complexity (3 simple parameters, no nested objects, no output schema) and full parameter descriptions in the schema, the description is fairly complete for the tool's purpose. However, it lacks behavioral transparency and usage guidelines, leaving some gaps for an agent to fully understand context.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters (target_id, selector, mode). The description adds no additional meaning beyond the schema; it only mentions the output format. Hence baseline score of 3 is appropriate.

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

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

The description clearly states the tool takes an 'ARIA accessibility snapshot' and outputs a 'YAML-formatted role tree'. It distinguishes from sibling tools like interceptor_browser_screenshot (visual) and interceptor_browser_evaluate (JS execution) by specifying the accessibility focus and format.

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

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

The description provides usage context ('Great for LLM-driven page understanding without parsing HTML') but does not explicitly state when to use or when not to use this tool compared to alternatives. No exclusions or alternative recommendations are given.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It clearly states this is a destructive, broad-stroke operation: stopping all browser instances, killing spawned processes, and cleaning Docker. This is more transparent than most tool descriptions.

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

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

The description is two sentences long, front-loads the critical action and scope, and contains no filler. Every phrase adds relevant information about what the tool does and its impact.

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

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

For a zero-parameter destructive cleanup tool, the description adequately covers what will be affected and why it should be used. It does not explain what happens after execution (e.g., whether state is recoverable), but that is a minor gap given the explicit emergency-cleanup framing.

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

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

The tool has zero parameters and the schema is empty, so there are no parameter semantics to clarify. The baseline of 4 applies because no parameter documentation is needed; the description's focus on scope and effects is sufficient.

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

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

The description states a specific verb ('Kill'), a clearly bounded resource ('ALL active interceptors across all types'), and the broader scope ('browser instances, spawned processes, Docker'). This distinguishes it from sibling tools like interceptor_kill and interceptor_status, which target individual interceptors or query state.

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

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

It identifies an explicit use case: 'Emergency cleanup', which signals the appropriate trigger for invoking this tool. It does not explicitly name alternatives or state when not to use it, but the context of an emergency cleanup is clear enough to guide selection.

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

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

With no annotations, the description carries the burden of disclosure. It correctly indicates the tool modifies the container (injecting env vars and CA cert), and the 'restart' mode stops and restarts the container. However, it doesn't mention potential side effects, permissions required, or success/failure signals, which would enhance transparency.

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

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

The description is concise: two sentences that front-load the core purpose and then detail the two modes. No redundant or unnecessary text.

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

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

Despite having no output schema, the description does not mention return values, error conditions, or what happens after injection (e.g., container remains running?). This lack of contextual information for a mutation tool is a notable gap, reducing completeness.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds minimal value beyond schema: it rephrases the enum descriptions but does not explain what values to use or constraints. Baseline of 3 is appropriate as schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: injecting proxy env vars and CA certificate into a Docker container. It distinguishes two modes ('exec' vs 'restart'), making it easy to understand the core operation and differentiate from siblings like interceptor_docker_detach.

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

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

The description explains the two modes and their basic behavior, but lacks guidance on when to choose one over the other or prerequisites (e.g., container must be running). No explicit 'when not to use' or alternative tools are mentioned, leaving some ambiguity.

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

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

No annotations, so description carries burden. It discloses the removal and cleanup actions, but doesn't specify side effects, permissions, or prerequisites.

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

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

Single sentence, no unnecessary words, front-loaded with action.

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

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

Given low complexity (one parameter, no output schema), the description is sufficient for understanding purpose and parameter origin. Minor omission: specifics of proxy configuration or files cleaned.

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

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

Schema coverage is 100% with description 'Target ID from interceptor_docker_attach'. Description does not add further meaning beyond the schema.

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

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

Description clearly states the tool removes proxy configuration and cleans up injected files from a Docker container, distinguishing it from sibling interceptor_docker_attach which presumably adds such configuration.

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

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

No explicit guidance on when to use or alternatives. Implies use after attach, but no exclusions or context provided.

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

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

No annotations provided, so description bears full responsibility. It discloses the key behavioral trait of retrieving final stdout/stderr output, which goes beyond a simple kill. However, it does not mention error handling or what happens if the target ID is invalid.

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

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

Two short, front-loaded sentences with no extraneous words. The first sentence states the primary action, the second adds important context. Excellent brevity.

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

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

Given the simplicity of the tool (one parameter, no output schema), the description covers the main functionality adequately. It mentions output retrieval. Minor gaps include no mention of return format or behavior on invalid target ID, but overall sufficient.

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

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

Schema coverage is 100% and the parameter 'target_id' already has a clear description. The description adds no further semantic value beyond restating 'by target ID.' Baseline score of 3 is appropriate.

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

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

Description clearly specifies the action: 'Kill a spawned process by target ID.' It also adds a side effect of retrieving final stdout/stderr. This distinguishes it from sibling tools like interceptor_spawn (creates) and interceptor_list (lists).

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

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

The description implies usage for terminating a process and retrieving its output. It references the target ID from interceptor_spawn, but does not explicitly state when not to use it or suggest alternatives. Still, the context is clear enough for an agent.

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

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

With no annotations, the description carries the full behavioral burden. It states it lists availability and active targets, which implies a read-only operation, but it does not explicitly confirm it is non-destructive or disclose any potential side effects, permissions, or output details. For a simple list tool, this is adequate but not thorough.

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

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

Two concise sentences with no redundancy. The key information (lists all interceptors, shows availability and targets, names the interceptor types) is front-loaded. Every word earns its place.

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

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

For a zero-parameter listing tool with no output schema, the description is fairly complete: it names the tool's action, the scope (all interceptors), and the data shown. It could explicitly state the return format or confirm it is read-only, but given the simplicity, the gap is minor.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty properties). The description adds value by specifying what will be listed (availability, active targets, and interceptor types), which compensates for the absence of parameter details. Since there are no parameters, the baseline is 4, and the description meets it.

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

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

The description clearly states the verb 'List', the resource 'all interceptors', and specifies what it shows (availability and active targets). It also names the specific interceptors (Browser, Terminal, Docker), which helps distinguish it from sibling tools like interceptor_status or interceptor_deactivate_all. However, it does not explicitly contrast with a close sibling, so it misses the top score.

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

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. There is no mention of 'use for an overview' or 'instead of interceptor_status'. The description only explains what it does, not when to select it over other interceptor-related tools.

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

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

No annotations provided, so description carries full burden. It discloses that traffic routes through MITM proxy, but lacks details on command execution behavior (e.g., synchronous vs asynchronous, output handling) and required proxy state.

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

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

Two sentences, no fluff. First sentence front-loads the core purpose; second adds key behavioral context. Highly efficient.

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

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

Given 4 parameters and no output schema, description covers the basic purpose and one behavioral aspect, but omits critical details like return value, error handling, and dependency on proxy being active. Adequate but incomplete.

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

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

Input schema provides full coverage for all parameters. Description adds value by listing specific env variables (HTTP_PROXY, HTTPS_PROXY, etc.) and indicating there are more, enhancing parameter understanding beyond schema.

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

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

Description clearly states it spawns a command with proxy env vars pre-configured. It distinguishes itself from sibling tools by focusing on running arbitrary commands with proxy settings, unlike browser or Android specific tools.

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

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

No explicit when-to-use or when-not-to-use guidance. It implies usage for running commands through the proxy, but does not mention alternatives or prerequisites like ensuring the proxy is running.

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

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

With no annotations, the description carries the full burden. It discloses some return behavior ('including all active targets and their details'), which is genuinely useful. However, it does not address what happens for an unknown/inactive interceptor_id, whether the operation is read-only in practice, or any error/edge cases, so an agent cannot predict failure modes.

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

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

One front-loaded sentence with zero filler. 'Get detailed status' leads immediately, and the 'including...' clause adds valuable return-content context without bloating the description.

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

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

For a simple one-parameter read-style tool with no output schema, the description covers the essentials: what it does and roughly what it returns. Minor gaps remain – behavior on invalid IDs, prerequisites such as the interceptor being active, and a richer description of the 'details' returned – but the core information an agent needs to invoke it correctly is present.

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

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

Schema description coverage is 100% – the single parameter interceptor_id is already documented with type and concrete examples ('browser', 'terminal', 'docker'). The tool description adds little beyond the schema, only reinforcing the 'specific interceptor' notion. Since the schema does the heavy lifting, the baseline 3 applies.

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

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

The description states a specific verb+resource ('Get detailed status of a specific interceptor') and clarifies scope via 'specific' and 'including all active targets and their details.' This distinguishes it from sibling tools like interceptor_list, but the differentiation is implicit rather than explicit – it never names an alternative tool, so an agent must infer the boundary from tool names.

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

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

No usage guidance is provided. The description does not say when to use this tool versus interceptor_list, interceptor_spawn, or the interceptor_browser_* actions, nor does it state any prerequisites (e.g., the interceptor must be active or spawned first). Usage context is only implied by the word 'specific.'

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

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

With no annotations, the description must disclose behavioral traits. It mentions evaluation order (priority ascending, first match wins) which is useful. However, it does not discuss side effects, limits, or idempotency, which would be expected for a creation tool.

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

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

The description is brief (two sentences) and front-loaded with the main action. However, it could be structured more clearly, perhaps listing the required components separately. Still, it is not verbose.

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

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

The tool has complex nested parameters and no output schema. The description is minimal and does not explain what the tool returns (e.g., rule ID) or how it handles duplicate descriptions or priority conflicts. More context is needed for an agent to use it correctly.

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

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 no extra meaning beyond the schema; it just mentions 'matcher and handler' which are already defined in detail in the schema.

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

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

The description clearly states the action (add), the resource (interception rule), and its components (matcher and handler). It also mentions evaluation order (priority ascending, first match wins), distinguishing it from sibling tools like proxy_update_rule or proxy_remove_rule.

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

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

No guidance on when to use this tool versus alternatives. For example, it does not say to use proxy_update_rule for modifying existing rules or proxy_test_rule_match for testing. The description only states what the tool does, not when it is appropriate.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It states the tool checks readiness without sending traffic, indicating safety, but it omits details such as whether the check is idempotent, what 'readiness' entails, any required preconditions, or possible side effects. This is insufficient for a mutation-related backend feature.

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

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

A single, front-loaded sentence that effectively communicates the tool's core function. No extraneous words; every part earns its place.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description is minimal. It states the action but does not explain what 'readiness' means or how the result is structured. For a simple check tool, this is adequate but could be more helpful by clarifying the outcome.

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

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

The input schema has no parameters (0 params, 100% coverage). Per the baseline rule, a score of 4 is appropriate because the description adds no extra parameter information but does not need to compensate for schema gaps. The description could have explained the concept of 'fingerprint runtime' but is not required to.

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

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

The description clearly specifies the verb 'check', the resource 'fingerprint spoofing backend readiness', and adds the distinguishing detail 'without sending traffic'. This differentiates it from sibling tools like proxy_set_fingerprint_spoof or proxy_list_fingerprint_presets, which have different purposes.

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

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

The phrase 'without sending traffic' implies a non-disruptive read operation, but no explicit guidance is given on when to use this tool versus alternatives like proxy_set_fingerprint_spoof. It doesn't specify prerequisites or expected context, leaving the agent to infer usage.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It merely says 'disable' but does not explain side effects, reversibility, state changes, or whether it affects other proxy settings. This lack of detail is insufficient for a tool that modifies proxy behavior.

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

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

The description is a single short sentence with no filler, making it very concise. However, it lacks any structure beyond that, such as separation of concerns or additional helpful context.

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

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

Given the tool has no parameters and no output schema, the description is adequate for a simple toggle action, but it does not address potential side effects or the broader context within the proxy toolset. It misses opportunities to explain what fingerprint spoofing is or how to revert the action.

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

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

There are no parameters (0 params, 100% schema coverage), so the description does not need to add parameter details. According to the rubric, 0 params yields a baseline score of 4.

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

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

The description 'Disable fingerprint spoofing' clearly states the action (disable) and the resource (fingerprint spoofing). The name includes 'ja3_spoof', which is a type of fingerprint, making the purpose very specific and distinguishable from sibling tools like proxy_set_ja3_spoof.

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

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 its siblings, such as proxy_set_ja3_spoof or proxy_check_fingerprint_runtime. The description does not mention prerequisites, alternatives, or contextual triggers for disabling spoofing.

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

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

Minimal disclosure beyond the verb 'clear', which implies destruction but lacks details on side effects, reversibility, or impact on other tool states. No annotations to supplement.

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

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

Extremely concise single sentence that communicates the core function with no waste.

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

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

For a zero-parameter tool, the description is adequate, though it lacks behavioral nuance. Could mention that traffic is permanently cleared, but not necessary for basic understanding.

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

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

No parameters exist, so the description does not need to add parameter semantics. Baseline score of 4 is appropriate.

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

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

The description specifies a clear action ('clear') and resource ('captured traffic from the buffer'), distinguishing it from sibling tools like proxy_list_traffic or proxy_export_har.

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

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

No guidance on when to use this tool versus alternatives. Does not mention prerequisites, side effects, 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.

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

No annotations provided. Description states effect (traffic goes directly) but no side effects or prerequisites. Adequate for a simple clear operation.

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

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

Two concise sentences, front-loaded with action. No wasted words.

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

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

Minimal but covers primary action. Lacks mention of return value, error conditions, or relationship to proxy_set_upstream. Adequate for simple tool.

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

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

No parameters; schema coverage 100%. Description adds no parameter info, which is acceptable as no parameters exist.

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

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

Description uses clear verb 'Remove' and specifies 'global upstream proxy', distinguishing it from siblings like proxy_set_upstream and proxy_remove_host_upstream.

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

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

Implies usage when removing global upstream proxy, but no explicit guidance on when to use vs alternatives like proxy_remove_host_upstream.

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

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

States deletion from disk, implying permanence, but lacks details about behavior if session is active, whether it's safe to call while proxy is running, or any side effects. No annotations to supplement, so description carries burden but is incomplete.

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

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

Single sentence with no redundant or extraneous information. Efficiently communicates core action and resource.

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

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

While simple, the description omits preconditions (e.g., session must be stopped) and postconditions (e.g., session data cannot be recovered). For a destructive operation, more context would help an agent avoid errors. Output schema not present, so description could provide more return value context.

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

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

Input schema has 100% description coverage with 'Session ID' for the single parameter. The tool description adds no additional meaning beyond what the schema already provides, so baseline score of 3 applies.

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

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

Specific verb 'Delete' and resource 'recorded session from disk' clearly indicates purpose. Distinguishes from sibling tools like proxy_get_session, proxy_list_sessions, and proxy_session_start which perform different operations.

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

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

No guidance on when to use this tool versus alternatives like proxy_session_stop (which stops but doesn't delete) or proxy_session_start (which creates). Does not mention prerequisites (e.g., session must be inactive) or that deletion is irreversible.

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

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 notes that the rule is not removed, implying nondestructive behavior. However, it does not specify side effects, reversibility, or whether the action affects active sessions. Basic transparency is present but could be richer.

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

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

The description is a single, focused sentence that conveys the essential action without extraneous words. It is well-structured and front-loaded.

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

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

Given the low complexity, single parameter, and no output schema, the description covers the core functionality. However, it could benefit from slightly more context (e.g., relation to enable/remove) but is sufficient for the tool's simplicity.

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

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

Schema coverage is 100% with one parameter (rule_id) adequately described. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the verb 'disable' and the resource 'interception rule', and adds specificity 'without removing it' which distinguishes it from proxy_remove_rule. Sibling tools like proxy_enable_rule and proxy_remove_rule further differentiate the action.

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

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

The description does not explicitly state when to use this tool versus alternatives like proxy_remove_rule or proxy_enable_rule. While the context of sibling tools implies usage scenarios, the description itself lacks guidance on exclusions or prerequisites.

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

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

No annotations are provided, so the description carries full burden. It only states the basic action without disclosing behavioral traits (e.g., reversibility, idempotence, what happens if already enabled). This is minimal disclosure.

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

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

The description is a single sentence with no superfluous words, achieving maximum conciseness while conveying the core purpose.

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

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

For a simple one-parameter tool, the description is adequate but lacks contextual completeness. It does not mention that the rule must be disabled first, nor does it hint at the relationship with proxy_disable_rule.

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

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

The single parameter (rule_id) is already described in the input schema with 100% coverage. The description adds no additional meaning beyond the schema.

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

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

The description clearly states the action 'enable' and the resource 'a disabled interception rule', making the tool's purpose immediately obvious. It distinguishes well from siblings like proxy_disable_rule and proxy_update_rule.

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

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

The description implies usage (enable a rule that is disabled) but provides no explicit context about when to use this tool versus alternatives. No mention of prerequisites or scenarios.

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

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

No annotations are present, so the description carries the full burden. It explains the effect (intercept outgoing TLS, extract negotiated parameters) but does not disclose potential side effects like performance impact or how captured data is stored/retrieved.

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

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

Two concise sentences that front-load the action and then describe the effect. No unnecessary words; every sentence is informative.

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

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

For a simple toggle tool with one parameter, the description is nearly complete. It explains what capture does but could mention that extracted data is accessible via other proxy tools (e.g., proxy_get_tls_fingerprints). Minor gap.

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

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

Schema coverage is 100% with a well-described boolean parameter. The description adds the concept of 'toggling' but no additional meaning beyond what the schema already provides. Baseline score of 3 applies.

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

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

The description uses specific verb 'Toggle' and resource 'server-side JA3S capture', clearly distinguishing it from sibling tools like proxy_set_ja3_spoof. It states exactly what the tool does.

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

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

The description implies usage context (enable to intercept TLS connections) but does not explicitly state when not to use it or mention alternatives. It provides clear context for when to toggle capture.

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

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

No annotations are provided, and the description does not disclose important behavioral traits like whether it overwrites existing files, file size limits, or side effects on the session. This leaves the agent uninformed about critical behavior.

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

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

The description is concise at one sentence, but it is too terse given the complexity of the tool. It could benefit from a brief additional sentence on the filtering capability.

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

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

Given the high parameter count and lack of output schema, the description is incomplete. It does not explain optional filters, output format details, or prerequisite steps, leaving gaps for the agent.

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

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

With schema description coverage at only 27%, the description should compensate but merely mentions 'filtered subset' without explaining any of the 11 parameters. It adds no value beyond what the minimal schema provides.

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

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

The description clearly states the tool exports a recorded session to HAR format. However, it does not explicitly differentiate from sibling tools like proxy_import_har beyond the direction (export vs import).

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

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, such as proxy_import_har or proxy_list_traffic. The description lacks context for decision-making.

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

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

No annotations provided, so description carries full burden. It describes a read operation ('Get'), which is transparent. But no mention of permissions, side effects, or error conditions, leaving some gaps.

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

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

Single sentence, no redundant words, front-loaded with action and resource. Perfectly concise.

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

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

For a simple one-parameter getter with no output schema, the description is complete: it tells what, why, and the format options are clear from schema. Siblings indicate it fits into proxy setup workflow.

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

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

Schema covers format parameter 100% with enum and default. Description does not add extra meaning beyond 'PEM and SPKI fingerprint'. Baseline 3 applies due to high schema coverage.

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

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

The description clearly states the specific verb 'get' and the resource 'CA certificate PEM and SPKI fingerprint', with clear purpose 'for installing on the target device'. This distinguishes it from sibling tools like proxy_set_* or proxy_start.

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

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

The phrase 'for installing on the target device' provides usage context, indicating this is a setup step. However, no explicit guidance on when to use vs alternatives (e.g., proxy_check_fingerprint_runtime) is given.

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

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

No annotations provided, so description carries full burden. It only states the tool returns full details with headers and body previews, but omits behavioral traits like whether the tool is read-only, any size limits, or response truncation.

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

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

Single sentence, 12 words, front-loaded with key information. Every word contributes to the purpose.

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

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

Adequate for a simple retrieval tool with one parameter, but lacks details on what 'full details' entails (e.g., whether body previews are truncated) and no output schema is provided. Gaps remain.

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

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

Schema coverage is 100% with the parameter exchange_id described as 'Exchange ID from proxy_list_traffic'. Description adds 'full details' but no additional meaning beyond schema; baseline 3 is appropriate.

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

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

Description clearly states the verb 'get', the resource 'details of a captured HTTP exchange', and what is included ('headers and body previews'), distinguishing it from sibling tools like proxy_list_traffic.

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

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. The prerequisite (exchange_id from proxy_list_traffic) is implied by the schema but not stated, and no when-not-to-use or exclusion criteria are provided.

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

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

Since no annotations are available, the description bears full responsibility for behavioral disclosure. It mentions a read operation ('Get') but provides no details about side effects, authentication requirements, rate limits, or other behavioral traits.

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

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

The description is a single, concise sentence with no filler. However, it could be slightly expanded to include usage hints without becoming verbose.

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

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

The tool is simple (one parameter, no output schema), and the description adequately conveys its purpose. However, given the absence of an output schema, some indication of what the response contains would improve completeness.

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

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

The input schema includes one parameter (session_id) with full description coverage (100%). The tool description adds no additional meaning 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.

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

The description clearly states the tool retrieves manifest or details for a specific recorded session, using a specific verb and resource. It distinguishes itself from siblings like proxy_list_sessions (which lists sessions) and proxy_get_session_exchange (which gets individual exchanges).

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

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 such as proxy_get_exchange or proxy_get_session_handshakes. The description does not specify context, prerequisites, or exclusions.

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

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

With no annotations, the description must fully disclose behavioral traits, but it only states 'get one exchange'. It does not indicate whether the operation is read-only (likely), what happens if the exchange is not found, or any side effects. The description adds no behavioral context beyond the schema.

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

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

The description is a single, well-structured sentence of 10 words that conveys the core purpose efficiently. It contains no unnecessary information and is front-loaded with the action and resource.

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

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

Given the tool has 4 parameters, no output schema, and no annotations, the description is minimally adequate. It explains the basic retrieval function but lacks context on what an 'exchange' is, how sessions work, or typical use cases. With full schema coverage, it meets the minimum but leaves gaps.

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

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 no additional meaning beyond the schema; it merely restates that identification is by seq or exchange ID, which is already evident from the parameter descriptions. No extra constraints or relationships are provided.

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

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

The description clearly states the tool retrieves one exchange from a recorded session, specifying the identification methods (by seq or exchange ID). This verb+resource combination is specific and distinguishes it from sibling tools like proxy_get_exchange which likely operates without session context.

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

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. There is no mention of prerequisites, context, or exclusions. The description merely states what it does, leaving the agent to infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries full burden. It does not disclose read-only nature, side effects, authentication needs, rate limits, or return format. The word 'summarize' hints at non-destructive behavior, but no details are given.

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

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

The description is a single concise sentence that front-loads the primary purpose. No wasted words, but it could be slightly more structured with additional details.

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

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

For a tool with 6 parameters, no output schema, and no annotations, the description is insufficient. It does not describe the output format or the meaning of the summary, leaving agents underinformed.

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

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

Schema description coverage is 50%, leaving limit, offset, and sort undocumented. The description adds no parameter information, failing to compensate for the gap. It does not explain how these parameters affect the summary.

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

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

The description clearly states the tool summarizes TLS handshake/fingerprint availability (JA3/JA4/JA3S) for session exchanges, which distinguishes it from sibling tools like proxy_get_tls_fingerprints and proxy_get_session_exchange. However, it does not define 'availability' precisely.

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

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

No guidance on when to use this tool versus alternatives. The description lacks prerequisites, use-case context, or exclusions. With no annotations, the description must provide this, but it does not.

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

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

With no annotations, the description carries the full burden. It correctly indicates a read operation ('Get'), implying no side effects. No contradiction, but could add details like return format or prerequisites.

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

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

A single, front-loaded sentence that efficiently communicates the tool's purpose. No unnecessary words.

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

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

For a simple getter tool with no parameters and no output schema, the description is adequate. It could be enriched with details about the returned configuration, but it is sufficient for an AI agent to understand the basic function.

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

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

The tool has no parameters, so the schema fully covers them. The description adds no additional semantic detail, but none is needed. Baseline 4 is appropriate.

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

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

The description clearly states the tool gets the current TLS capture and spoofing configuration, with a specific verb and resource. It distinguishes from sibling tools that modify or manage proxies and TLS settings.

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

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

The description makes the purpose clear (retrieving config), providing implicit guidance for usage. However, it lacks explicit when-to-use or when-not-to-use instructions, and does not mention alternatives.

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

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. However, it only states the function (get fingerprints) without mentioning any side effects, required permissions, or output details. For a read-only operation, this is minimal but could be improved by noting that it is non-destructive.

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

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

The description is a single, concise sentence that conveys the core functionality without any unnecessary words. It is front-loaded with the action and resource, making it easy to parse quickly.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is reasonably complete. However, it lacks information about the return format (e.g., object with fingerprint strings) or prerequisites (e.g., the exchange must exist). An output schema or brief note on output structure would improve completeness.

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

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

The input schema has 100% description coverage, with the parameter 'exchange_id' already described as 'Exchange ID from proxy_list_traffic'. The tool description does not add any further semantic meaning to the parameter beyond what the schema provides, 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.

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

The description clearly identifies the tool's purpose: retrieving JA3, JA4, and JA3S fingerprints for a specific captured exchange. The verb 'Get' and the specific resource types (client and server fingerprints) differentiate it from sibling tools like proxy_list_tls_fingerprints (which lists all fingerprints) and proxy_list_traffic (which lists exchanges).

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

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

The description implies that the tool should be used when you have a specific exchange_id from proxy_list_traffic, but it does not explicitly state when to use it versus alternatives. For example, it could clarify that proxy_list_tls_fingerprints might be used first to get an overview, or that this tool provides details for a single exchange. No exclusion criteria are provided.

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

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 lacks disclosure of behavioral traits such as whether existing sessions are overwritten, error handling for malformed HAR files (though 'strict' parameter hints at this in schema), or details about session persistence. For a mutation tool, more behavioral context is needed.

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

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

The description is a single sentence that fronts the action and outcome, containing no unnecessary words. It is concise and structured efficiently.

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

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

Given the tool's complexity (5 parameters, no output schema), the description provides the high-level purpose but lacks details about return values (e.g., session ID) and edge cases. It is adequate but not fully comprehensive.

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

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 additional meaning beyond the schema; it does not elaborate on parameter nuances like session naming or storage directory behavior.

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

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

The description clearly states the action (import), the resource (HAR file), and the destination (new persisted session). It also indicates the purpose (querying, findings, replay), distinguishing it from sibling tools like proxy_export_har or proxy_list_sessions.

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

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

The description implies usage when a HAR file needs to be imported into a session, but does not provide explicit guidance on when to use this tool versus alternatives, nor when not to use it. No exclusions or alternatives are mentioned.

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

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

No annotations provided, so description must cover behavioral traits. It discloses it's a passthrough rule with header transforms but omits side effects like rule activation timing, overwrite behavior, or permission requirements. Lacks full transparency.

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

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

Two succinct sentences, front-loaded with main purpose, no redundant words. Every sentence adds value.

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

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

Given the tool's moderate complexity and high schema coverage, the description captures the essence and differentiates from siblings. Lacks mention of return behavior but no output schema expected. Still sufficiently complete.

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

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

Schema coverage is 100%, so schema already documents all parameters. Description adds minimal extra context (e.g., 'passthrough rule'), which warrants a baseline 3. No significant additional explanation beyond schema.

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

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

Description clearly states verb 'Add or overwrite headers' and resource 'matching traffic', and specifies it creates a passthrough rule. This distinguishes it from sibling tools like proxy_add_rule or proxy_rewrite_url.

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

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

Description implies usage for header injection on matching traffic but lacks explicit guidance on when to use this vs alternatives like proxy_add_rule with transforms. No when-not-to-use or prerequisites mentioned.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It only says 'list available', with no mention of side effects, permissions, or state changes. For a read-only listing tool, the absence of any explicit statement about non-destructiveness is a gap.

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

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

The description is a single, clean sentence with no extra words. It front-loads the action and purpose, making it highly efficient.

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

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

For a parameterless listing tool with no output schema, the description provides the basic purpose. However, it lacks details about what the output looks like (e.g., list of strings, objects) and any usage context, making it minimally adequate.

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

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

The input schema has no parameters, so the baseline is 4. The description does not add further meaning, but since there are no parameters, no additional information is strictly needed.

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

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

The description clearly states 'List available browser fingerprint presets', specifying the verb 'list' and the resource 'browser fingerprint presets'. It also indicates the purpose 'for use with proxy_set_fingerprint_spoof', distinguishing it from sibling tools that set or check fingerprints.

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

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

The description only hints at usage with proxy_set_fingerprint_spoof but does not provide explicit guidance on when to use this tool or when to avoid it. No alternatives are mentioned, and with many sibling tools, more context is needed.

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

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

With no annotations provided, the description carries the full burden. It states it lists all rules sorted by priority, implying a read-only operation. While it doesn't explicitly confirm no side effects, the verb 'list' strongly suggests safe behavior.

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

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

The description is a single concise sentence of 7 words that perfectly captures the tool's function with no superfluous information. It is front-loaded and efficient.

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

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

Given the tool's low complexity (no parameters, simple list operation), the description is complete. It covers what the tool does and the ordering. No output schema exists, but the behavior is straightforward enough that further detail is unnecessary.

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

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

The tool has zero parameters, so the schema coverage is 100%. Per guidelines, baseline for 0 parameters is 4. The description adds no parameter information because none exist.

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

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

The description uses a specific verb ('List') and resource ('interception rules'), and clearly states the ordering by priority. This distinguishes it from sibling tools that add, remove, or modify rules.

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

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

The description implicitly indicates this tool is for reading rules, but does not provide explicit guidance on when to use it versus alternatives (e.g., proxy_get_session for sessions). No when-not-to-use or alternative mentions are given.

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

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

With no annotations, the description carries full burden. It only states 'list recorded sessions' with no behavioral details such as whether the list includes metadata, supports pagination, or how sessions are ordered. Minimal disclosure beyond the core purpose.

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

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

At six words, the description is highly concise and front-loaded. However, slightly more context about the nature of 'sessions' could improve understanding without bloating the text.

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

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

Given the lack of an output schema and the presence of many sibling session-related tools (e.g., 'proxy_list_traffic', 'proxy_get_session'), the description fails to explain what information is returned (e.g., session IDs, timestamps) or how this tool differs from similar listing tools.

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

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

There are zero parameters and schema coverage is 100% (empty schema). The description need not add parameter details, and the baseline for no parameters is 4. No param information is required.

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

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

The description clearly states the verb 'list' and the resource 'recorded sessions', making the purpose unambiguous. It also distinguishes from sibling tools like 'proxy_get_session' (individual session retrieval) and 'proxy_delete_session' (deletion).

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