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

With no annotations, the description carries the full burden of behavioral disclosure. It conveys a read-only 'Get' operation and indicates what data is returned, but it does not mention side effects, limitations, or the structure of the returned tree. This is adequate for a read operation but not deeply 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?

Two sentences with no filler: the first front-loads the operation and resource, and the second adds a meaningful use case. It does not repeat schema information or waste 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?

The description plus fully-covered schema provides enough to invoke the tool: parameters are documented, and the description lists the key output categories even without an output schema. Minor gaps remain around tree structure and alternative tool selection, but they are not blocking for a simple read operation.

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 about `receipt`, `maxDepth`, or `selector` beyond what the schema already provides; it only clarifies the overall purpose of the returned data.

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 ('Get') with a precise resource—the accessibility tree—and lists its key contents (roles, ARIA labels, focusable elements, form states). It is clearly distinct in meaning from siblings like safari_snapshot, though it does not explicitly name an alternative to differentiate itself.

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?

'Essential for a11y auditing' provides a clear use context, and the content list implies when an agent would want this tool (checking roles, focus, and form states). It does not explicitly name alternatives or specify 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 bears full responsibility. It indicates a read-only operation by listing extracted data, but does not disclose potential performance impact, required permissions, or side effects. The description is adequate but lacks rich 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?

Two sentences with no wasted words. The first sentence immediately lists what the tool does, and the second provides a use case. Information 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 no output schema, the description lists the returned items adequately. However, it lacks details on the data format or structure, which would help an agent parse results. Still, for a parameterless tool, it is reasonably 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?

The tool has zero parameters, so per guidelines the baseline score is 4. The description adds value by listing the data fields returned, which compensates for the lack of an output schema. No parameter details are possible or 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 the tool performs a full page analysis in one call, listing specific elements (title, URL, meta tags, OG, headings, etc.). This distinguishes it from sibling tools that extract individual components, making its purpose unambiguous.

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 using this tool for comprehensive analysis instead of multiple calls (e.g., 'ONE call') and targets SEO/audit contexts. However, it does not explicitly mention when to avoid it or name alternative sibling 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?

With no annotations, the description carries the full burden. It discloses that the tool runs an audit and returns a checklist, without side effects or modifications. It adds useful behavioral context beyond 'audit' by listing checked items and output format.

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, front-loaded with key information (what it does, what it checks, output format). Every sentence is essential and there is 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 simple audit tool with no parameters and no output schema, the description is complete: it lists specific checks and states the output is a pass/total checklist. No additional context is needed.

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 zero parameters, so baseline is 4. The description adds meaning beyond the empty schema by explaining the tool's purpose and output, which is adequate for a parameterless tool.

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 audits for iOS 'Add to Home Screen' / PWA readiness, listing specific checks (apple-mobile-web-app-capable, icons, etc.). This distinguishes it from sibling tools like safari_webkit_compat or safari_doctor, which cover different audits.

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 PWA readiness checks but does not explicitly state when to use it versus other audit tools or when not to use it. No comparisons or exclusions 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 must disclose behavioral traits. It states that console messages are cleared, but does not mention scope (e.g., current tab only), irreversibility, or side effects. The action is simple, so it's 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?

The description is a single sentence, front-loaded, and contains no unnecessary words. It efficiently conveys 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 no parameters, the description is fairly complete. However, it lacks details about the return value or confirmation of success, which would be useful since there is no output schema. Still, it covers the essential behavior.

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 schema coverage is 100%. The description adds nothing beyond the schema, but given zero parameters, baseline is 4. The description 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 'Clear all captured console messages' uses a specific verb ('Clear') and resource ('captured console messages'), making it clear what the tool does. It is distinct from sibling tools like safari_get_console (read) and safari_console_filter (filter).

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 safari_get_console or safari_clear_network. There is no mention of prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects (e.g., does it trigger input/change events? Does it clear selection? Does it work on contenteditable? Does it require focus?). The description does not mention whether the operation is reversible or what the return value is. This is a significant gap for an action tool with zero annotation coverage.

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, unambiguous sentence with zero filler. It is appropriately sized for a simple action tool, front-loading the core purpose. 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 simple tool that clears an input, the description covers the essential action and the schema covers parameters. However, it omits behavioral details that could affect correct invocation, such as whether events are fired, whether it works on all input types, and what the tool returns. Given the tool's simplicity, this is a minor gap, but for an agent it could lead to incorrect assumptions about side effects.

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 already provides 100% coverage of both parameters: selector is described as 'CSS selector of the input' and receipt as 'Tab receipt from safari_new_tab — pins this call to that tab (survives reconnects/subagents)'. The description adds no additional meaning beyond what the schema states. With high schema coverage, 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 states a clear verb ('Clear') and a specific resource ('an input field'), making the tool's purpose obvious. It distinguishes itself from siblings like safari_fill (which sets a value) and safari_press_key (keyboard actions), but does not explicitly name alternatives. The intent is clear enough for an agent to select it for clearing fields, so it earns a 4 rather than a 5.

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 guidance on when to use this tool versus alternatives. It does not mention that it should be used to empty a field before typing, nor does it exclude cases like contenteditable elements or fields that require specific event firing. With many sibling tools like safari_fill, safari_type_text, and safari_press_key, the lack of any usage context leaves the agent to infer when clearing 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, and the description is brief. It discloses the primary action and effect but does not mention any side effects, idempotency, or prerequisites. For a simple tool with no parameters, this is adequate but not exhaustive.

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 purpose and effect without any unnecessary words. It is front-loaded with the core 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 the tool has no parameters, no output schema, and a straightforward purpose, the description is complete. It explains what the tool does and its 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 tool has zero parameters, and the schema coverage is 100%. The description does not add anything about parameters, but none is needed. Baseline for high coverage is 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?

The description clearly states the verb 'remove', the resource 'network route mocks', and the scope 'all', and explains the effect 'restore real network behavior'. It differentiates from sibling tools like safari_mock_route.

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 provide explicit guidance on when to use this tool versus alternatives, such as indicating it should be called after mocking or that it resets network behavior. However, the simplicity of the tool makes usage obvious.

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 behavior. It states 'clear all captured network requests' but does not clarify what 'cleared' means (e.g., only displayed data or stored data?), whether the action is reversible, or if there are side effects on ongoing captures.

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 immediately conveys the action. No filler or redundant information is present.

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 (no parameters, no output schema, no annotations), the description is largely sufficient. However, adding a brief note on when this tool is typically used after network capture would enhance 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 tool has no parameters, and the schema coverage is effectively 100%. According to the rubric, 0 parameters yields a baseline of 4. The description does not need to add parameter meaning 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 'Clear all captured network requests' uses a specific verb ('clear') and clearly identifies the resource ('captured network requests'). It effectively distinguishes this tool from siblings like 'safari_network' and 'safari_network_details'.

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 such as 'safari_start_network_capture' or 'safari_network'. The description implies a clearing action but does not specify prerequisites or typical use cases.

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, and it does well: it explains the synthetic PointerEvent+MouseEvent sequence, the React Fiber fallback, that it never moves the user's real mouse, and that refs expire after snapshots. It stops short of describing return behavior or side effects like navigation waits, but the disclosed mechanism is substantial.

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 sentences, all information-dense: the action, the targeting flexibility, the technical behavior, and the critical ref-freshness caveat. Nothing is redundant or wasted, and the most important usage rule is 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?

The description is adequate for a click tool but has gaps: no mention of return value or confirmation (there's no output schema), no parameter precedence when multiple locators are given, and no routing guidance relative to the many click siblings. The schema covers parameters, but the description alone doesn't fully equip an agent to handle ambiguous or failing clicks.

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 all six parameters already have descriptions. The tool description adds some context by grouping the targeting modes (ref, selector, text, x/y) and warning about ref expiry, but it doesn't clarify precedence or interaction when multiple targeting params are supplied. 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 opens with a clear verb-resource pair ('Click element') and lists the four targeting modes (ref, selector, text, x/y). It also conveys a specific technical scope (React/Airtable/virtual DOM apps), but it doesn't explicitly name a sibling like native_click for contrast, so it falls short of a 5.

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

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

The description gives concrete usage guidance, especially the fresh-snapshot requirement for refs and the statement that it uses pure JS without touching the user's mouse. It does not explicitly state when to choose this over alternatives like safari_native_click or safari_click_and_read, so it lacks 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?

The description discloses key behavioral aspects: it returns the updated page and handles both client-side (React Router) and full page navigations. It does not mention waiting or error conditions, but the core behavior is transparent. Since there are no annotations to supplement, this is a reasonable level of 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 two sentences, highly concise, and directly to the point. Every word adds value: it states the action, the result, the efficiency gain, and the navigation coverage. There is no fluff or redundancy.

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 description gives enough context for a typical use case: clicking an element and getting the resulting page. It notes that it handles both React Router and full page loads, which is important for correctness. It does not explain failure modes or return format, but the tool's purpose is sufficiently scoped for an agent to call it appropriately.

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 description does not add any extra meaning to the parameters beyond what is already provided in the schema (e.g., x, y, text, selector). It does not clarify how parameters interact or which are mutually exclusive, but the schema itself is complete with per-parameter descriptions. Thus, the description provides no additional semantic value.

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: clicking an element and returning the updated page. It also highlights the efficiency benefit (saving a round-trip) and mentions specific navigation scenarios it handles, making the purpose unambiguous.

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

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

The description implicitly guides usage by comparing to a separate click+read_page and stating the advantage, which helps the agent decide when to use this tool. It also mentions handling React Router navigation and full page loads, which is a relevant criterion for selection. However, it does not explicitly state alternative tools for other scenarios (e.g., when only clicking 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, the description carries the full burden. It discloses the combined click-and-wait behavior but lacks details on failure modes (e.g., element not found, timeout exceeded) and does not specify how the waiting condition is selected between page load and element wait.

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, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and usage recommendation.

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, 4 parameters with full schema descriptions, and no output schema, the description is mostly complete. However, it omits explanation of which parameter is required (though none are marked as required, leading to ambiguity) and default behavior when waitFor is not provided.

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 new meaning to the parameters beyond what the schema already provides; it only reiterates the general 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 tool performs a click followed by waiting for a result (page load or element). It explicitly distinguishes itself from separate click and wait actions, differentiating from siblings like safari_click and safari_wait_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 directly advises to use this tool instead of separately calling click and wait_for, providing a clear usage guideline and context for when to choose it over 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 carries the full burden. It states it reads text from the clipboard but does not disclose potential side effects (e.g., permission requirements) or behaviors when the clipboard is empty or contains non-text data.

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 necessary information without any fluff. It is concise 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?

For a zero-parameter, no-output-schema tool, the description is mostly adequate. However, it could mention fallback behaviors (e.g., empty clipboard or non-text content) to be fully 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?

The tool has no parameters, and the input schema is empty. Schema description coverage is 100%. With zero parameters, the description does not need to add parameter information; a baseline 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 clearly states the action (read), the resource (clipboard content), and the format (text). It implicitly distinguishes from the sibling tool 'safari_clipboard_write' which performs the opposite operation.

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. However, the tool's function is straightforward (reading clipboard), and usage is implied by its name and description. No exclusions or context for alternatives 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?

No annotations are provided, and the description does not disclose side effects (e.g., overwrites clipboard) or requirements (e.g., permissions). With no annotations, the description fails to provide necessary 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?

The description is concise (one sentence) and immediately conveys the core function. However, it could be slightly more structured with additional context 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?

For a simple tool with one parameter and no output schema, the description is minimally adequate. However, missing context about clipboard behavior (e.g., cross-tab effects) makes it less complete than ideal.

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 clear parameter description ('Text to copy to clipboard'). The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the action (write) and the resource (text to the system clipboard). It is specific and distinguishes from sibling tools like safari_clipboard_read.

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., reading clipboard) or prerequisites. The description lacks context on limitations or appropriate 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?

With no annotations, the description carries the full behavioral burden. It clearly discloses the action and the receipt requirement after restart, but it doesn't mention irreversibility, error behavior, or what happens if no receipt is available. The core behavior is clear, though the destructive nature is only implicit.

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 efficient sentences: the first states the action, the second covers the key edge case. No filler or redundant restatement of the schema.

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 tab-closing tool, the description covers the primary non-obvious condition (receipts after restart) and flags the deprecated parameter. It lacks explicit error/return behavior and a direct warning about destructiveness, so it is slightly shy of fully 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 the baseline is 3. The description adds value by explaining that 'receipt' is opaque, ties it to safari_new_tab/safari_list_tabs, and notes the 'url' parameter is deprecated. This gives the agent practical guidance beyond the schema text.

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: 'Close the current tab.' This clearly distinguishes the tool from tab-related siblings like safari_new_tab, safari_switch_tab, and safari_list_tabs.

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 a concrete usage condition: after a daemon/session restart, pass the opaque receipt from safari_new_tab or safari_list_tabs. It doesn't enumerate alternatives or when-not conditions, but no close-specific sibling exists, so the context provided is sufficient.

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 explains the filtering action but omits details like whether the console is cleared after, or the response format (e.g., array of messages). The behavior is partially transparent but lacks completeness for a tool with no output 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, efficient sentence that conveys both the action and a key prerequisite. No redundant words, 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?

Given the simplicity (1 param, no output schema), the description is adequate but could be more complete by specifying the return format (e.g., array of messages) or behavior (e.g., returns new messages only). It meets minimum viability but leaves room for improvement.

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 a clear enum description for the 'level' parameter. The description merely restates 'filtered by level', adding no new meaning beyond the schema. 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 console messages with a level filter. It also distinguishes itself from siblings like 'safari_get_console' (likely unfiltered) by mentioning the prerequisite, making the purpose specific and unambiguous.

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

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

The description explicitly states a prerequisite ('must call safari_start_console first'), guiding the agent on proper usage. However, it does not explicitly indicate when to use this over 'safari_get_console' or other related tools, though the filter hint implies differentiation.

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 it 'analyzes' and 'shows' but does not disclose whether it is read-only, whether it modifies the page, or any other behavioral traits (e.g., performance impact, auth needs).

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 with key information front-loaded: purpose and output. 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?

For a zero-parameter read analysis tool, description covers purpose and output. However, lacks mention of any side effects or performance considerations. No output schema to compensate.

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 is 100% (empty schema). Baseline of 4 applies since description need not add param info, and it correctly omits any.

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?

Clear verb ('analyze'), specific resource ('CSS coverage'), and explicit outcome ('find unused CSS rules', 'shows coverage percentage'). Distinct from all siblings, none of which analyze CSS coverage.

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?

Implied usage: when you need to find unused CSS rules. No explicit when-to-use or when-not-to-use, and no mention of alternatives (though no direct sibling exists).

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 fails to disclose that cookie deletion is irreversible, only affects the current page, or may impact session state. For a destructive action, this is insufficient 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 a single sentence that is perfectly concise and front-loaded with the key action and parameters. No superfluous 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 tool's simplicity and lack of output schema, the description is minimally adequate but could mention that cookies are for the current page and deletion is permanent. It provides enough context for basic use.

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 value by mapping the 'name' parameter to specific cookie deletion and 'all' to deleting all cookies. This clarifies the semantic distinction beyond the 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?

The description explicitly states the tool deletes cookies, specifying two modes: specific cookie by name or all cookies for the current page. This clearly distinguishes it from sibling tools like safari_set_cookie and safari_get_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?

The description does not provide guidance on when to use this tool versus alternatives. It only states what it does, leaving the agent to infer usage context. No exclusions or conditions 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?

The description discloses the destructive nature (delete/clear all) but lacks details like irreversibility, scope (per-origin), or potential side effects. With no annotations provided, the description carries full burden and 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?

The description is a single, efficient sentence with no unnecessary words. It is front-loaded and directly communicates the tool's functionality.

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 optional param and no output schema, the description is almost complete. It explains both delete and clear-all modes. However, it could clarify that it operates on the current page's localStorage (implied but not explicit).

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 covers 100% of parameters with descriptions. The description adds 'omit key to clear all', which is already in the schema description, so it adds marginal new 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 tool deletes a localStorage key or clears all localStorage. It uses a specific verb ('Delete') and resource ('localStorage'), and distinguishes itself from sibling tools like safari_set_local_storage and safari_local_storage by the delete 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 context is clear: use when you need to remove localStorage data. However, no explicit when-not-to-use or alternatives are mentioned. The distinction between deleting a specific key vs clearing all is implied but not guided further.

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 states the basic behavior (delete key or clear all) but does not disclose consequences such as what happens if key does not exist, whether the operation is immediate or requires page reload, or any side effects.

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

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

The description is a single, clear sentence with no unnecessary words. It is front-loaded with the action and resource, making it efficient and easy to understand.

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 optional parameter and no output schema, the description is fully informative. It covers both use cases (delete key or clear all) without missing any essential information.

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 'key' having a description that matches the tool description. The description adds no additional meaning beyond what the schema already provides, so 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 the tool deletes a specific sessionStorage key or clears all if key is omitted. The verb 'Delete' and resource 'sessionStorage' are explicit, and it distinguishes itself from sibling tools like 'safari_session_storage' (read) and 'safari_set_session_storage' (write).

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 deleting sessionStorage entries but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. It lacks exclusions or context about 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 exist, so the description carries full burden. It clearly states detection and output details but does not explicitly confirm read-only nature or absence of side effects.

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

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

Two sentences, no fluff, front-loaded with core action and output. Every word 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 zero parameters and no output schema, the description adequately covers what the tool does and returns, though output format details are missing. Still sufficient for most agents.

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 (0 params, 100% coverage), baseline from guidelines is 4. Description adds no param info, but none 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 the tool auto-detects all forms on the page with details on fields, types, selectors, and submit buttons, distinguishing it from form-filling tools like safari_fill_form.

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 suggests use for automated form filling but lacks explicit when-not-to-use or alternative comparisons. The context of siblings provides implicit 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. It describes what the tool checks and that it returns a pass/fail checklist with fixes. It does not explicitly state whether the tool is read-only or has side effects, but 'diagnose' implies no modifications. More could be said about potential side effects (e.g., does it modify permissions?).

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, front-loaded with the core purpose. It is concise and every sentence adds value. Minor improvement could be made by breaking the first long sentence into two for readability.

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 there are no parameters or output schema, the description explains the output (pass/fail checklist with fixes) and the scope of diagnosis. It is adequate for understanding what the tool does and what to expect.

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 parameters, schema coverage 100%). According to the rules, baseline is 4 when no parameters. The description adds no param info because none is 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 uses specific verbs ('Diagnose') and resources ('macOS permission + daemon chain', 'Safari running', 'Apple Events/Automation', etc.), clearly distinguishing this tool from siblings like native_click or screenshot by focusing on diagnosing permission issues rather than performing actions.

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 states 'Run this FIRST when clicks/screenshots/startup "don't work even with permissions granted"', providing clear when-to-use guidance. It doesn't explicitly mention when not to use, but the context is strong enough to imply it's a diagnostic first step.

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 states the action and targeting method but does not mention side effects, return value, timing, or behavior when both selector and coordinates are supplied. For a simple action this is a minor gap, but it still lacks transparency about execution details.

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 verb and target, and includes a helpful example in parentheses. Every word earns its place, and it is appropriately sized for the action'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 simple double-click action with full schema coverage, the description is adequate but not complete. It lacks guidance on when to use this over sibling click tools, and it does not mention the receipt parameter's role in targeting a specific tab, though that is documented in the schema. The absence of annotations and output schema leaves the agent with limited context beyond the basic 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?

Schema description coverage is 100%, so each parameter is already documented in the schema. The description adds a minor clarification that targeting can be by CSS selector or x/y coordinates, but this is already implied by the schema fields. No additional semantic meaning is provided 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 (double-click), the target (element), and the two targeting methods (CSS selector or x/y coordinates). It also gives a concrete example ('to select a word in text'), making the purpose unambiguous and distinguishing it from sibling tools like safari_click and safari_right_click.

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 an example use case ('to select a word in text') that implies when to use it, but it does not explicitly state when not to use it or name alternatives such as safari_click for single clicks. The agent must infer that this is for double-click interactions, with no explicit routing 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?

No annotations provided, and the description only mentions the basic action without disclosing behavioral traits like whether it performs a real drag-and-drop, waits for drop targets, or handles async 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?

Two sentences with no redundancy. The description is front-loaded with the core action and then provides parameter usage hints.

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 drag operation with 6 parameters and no output schema, the description is too minimal. It lacks details on expected behavior after drag, potential errors, or how to ensure the drop target is detected.

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 general guidance about using selectors or coordinates but does not provide additional semantics 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 verb 'Drag', the resource 'an element', and the target 'another element or position', distinguishing it from sibling tools like click, hover, or scroll.

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 vs alternatives (e.g., click and drag, scroll). No when-not-to-use instructions 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 carries the full burden. It states the tool resizes the window and sets the user agent, which covers the main behaviors. It does not mention other aspects like viewport scale or touch simulation, but the parameter list adds some 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 extremely concise, consisting of just two sentences with no unnecessary information. Every word contributes to clarity, and it is well structured for quick agent comprehension.

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 covers the essential actions (resize, set user agent) and provides device examples. It is sufficient for an agent to select and invoke the tool correctly, though it could optionally mention scale behavior.

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, so the description adds only moderate value by grouping devices and noting custom options. It does not elaborate on parameters like scale or userAgent 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 emulates a mobile device by resizing window and setting user agent. It lists specific device names and mentions custom width/height options, making the purpose unambiguous and distinct from sibling tools like safari_resize.

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 clear examples of when to use the tool (with specific devices or custom dimensions). However, it lacks explicit guidance on when not to use it or alternatives like safari_resize for simple resizing, but the context of siblings provides sufficient distinction.

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 behavior. It mentions execution engine (extension-first, AppleScript-fallback) and lack of focus steal. However, it does not disclose potential side effects, error handling (e.g., file not found), or return value behavior, which are important for a file-execution 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?

Three sentences: first defines action and benefit, second explains engine, third gives a key use case. No wasted words, each sentence contributes essential 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?

Provides good background on engine and use cases but lacks details on return values (what happens after execution?), error conditions, and whether the execution is synchronous or asynchronous. For a tool with no output schema, this gap reduces 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 coverage is 100%, so the schema already describes the path parameter. The description adds value by explaining the file must be a .js file and the contents are executed, and provides a concrete use case (binary upload). This enriches understanding 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?

Clearly states it executes JavaScript from a file path, distinguishing from inline execution (safari_evaluate). The description also mentions specific use case (binary upload via base64), making the tool's purpose unmistakable.

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?

Explicitly states when to use (avoid huge scripts inline, upload binary via base64) and the same engine as safari_evaluate. Does not explicitly exclude inappropriate use cases but provides sufficient context to guide the 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?

No annotations provided, so the description carries full burden. It discloses that a returned Promise is awaited, that fetch/timers work in background tabs but requestAnimationFrame never fires, and that it automatically falls back to AppleScript under CSP restrictions. This is rich, non-obvious behavioral context that an agent needs to predict behavior accurately.

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?

Every sentence earns its place: core action, behavioral quirks, fallback, and routing to alternatives. Well front-loaded with the essential purpose, then efficient supporting details. No 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?

Given the complexity of executing JS (async behavior, fallback, environment quirks), the description covers key aspects. However, it doesn't explicitly state what the tool returns (e.g., the serialized result of the evaluated expression) or how errors are surfaced. With no output schema, this is a minor gap but not critical 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 description coverage is 100%, so both parameters are already documented in the schema. The description does not add extra meaning about parameter usage beyond the schema, but the baseline 3 is appropriate when the schema fully covers them. No additional semantic value 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?

States a specific verb and resource: 'Execute JavaScript in the current page' with concrete details about Promise awaiting and background tab behavior. Clearly differentiates from siblings like safari_read_page, safari_snapshot, and safari_click/fill.

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?

Explicitly tells when to prefer alternatives: 'For reading data, prefer safari_read_page or safari_snapshot. For interactions, prefer safari_click/fill with refs.' Also notes the AppleScript fallback when CSP blocks execution, giving clear context on when this tool is used over others.

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 discloses the export as JSON and mentions the storage types included, but does not specify side effects (e.g., read-only, no deletions), behavior on empty storage, performance considerations, or potential size limits. Basic transparency is present but could be more comprehensive.

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 action and purpose. Every word adds value, and there is no redundancy or unnecessary detail.

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 covers the essential information: what is exported, the format, and a common use case. It is clear about the scope (cookies + localStorage + sessionStorage, excluding IndexedDB, which has separate sibling tools). However, it could be more complete by mentioning that the operation is non-destructive and whether it works on the current page's storage only.

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 0 parameters and the schema is empty (100% coverage). The description adds value beyond the schema by explicitly listing what is exported (cookies, localStorage, sessionStorage), which clarifies the scope. Per the calibration baseline for 0-parameter tools, a 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 clearly states the action (Export), the resource (all storage state: cookies, localStorage, sessionStorage), and the output format (JSON). It distinguishes itself from granular sibling tools like safari_get_cookies and safari_local_storage by offering a bulk export, and includes a use case (saving and restoring login 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 a use case ('useful for saving and restoring login sessions') but does not explicitly state when to use this tool versus alternatives like individual storage getters or when not to use it. There is no mention of prerequisites or excluded 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?

With no annotations, the description must disclose behavior but only lists extracted fields. It does not clarify whether it extracts all images in DOM or only viewport-visible, performance impact, or if it triggers network requests, leaving significant ambiguity.

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 covers the core functionality without unnecessary words, though it could benefit from slightly more detail on scope.

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 description lacks output schema information (e.g., return format), and does not address edge cases like lazy-loaded images or empty results. Given the simplicity, it is somewhat complete but has 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?

The only parameter 'limit' has its description in the schema, and the tool description reiterates it with a default value, adding useful context 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 tool extracts images and lists specific attributes (src, alt, dimensions, etc.), distinguishing it from sibling extract tools like safari_extract_links and safari_extract_meta.

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 extracting image metadata but provides no explicit guidance on when to use it versus alternatives, nor any 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 the full burden. It discloses that it extracts multiple attributes, implying a read operation, but does not mention any behavioral traits such as side effects, rate limits, or whether it is purely read-only. It is not contradictory.

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 tool's purpose and output attributes without any unnecessary words. It is appropriately concise 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 no output schema, the description hints at the return fields (href, text, rel, target, external/nofollow detection), which is moderately complete. However, it does not specify the format or structure of the returned data, leaving some gaps for an 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?

Schema coverage is 100%, with both parameters (limit, filter) described in the schema. The description adds marginal value by indicating 'all links' but does not provide additional semantic meaning beyond the schema. 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 action (extract) and resource (all links with specific attributes like href, text, rel, target, external/nofollow detection). It is specific and avoids tautology, but does not explicitly differentiate from siblings like safari_extract_images or safari_extract_meta.

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 link extraction is needed (e.g., for scraping or analyzing links), but provides no explicit guidance on when to use this tool versus alternatives, nor any 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?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only lists extracted items without mentioning side effects, performance impact, or whether the operation is read-only (likely, but not stated).

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, one line, and front-loaded with the verb 'Extract'. It lists the key items without 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?

Given no output schema and no annotations, the description does not specify the output format or structure, leaving the agent uncertain about how the extracted meta tags will be returned (e.g., as a JSON object or text list).

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 baseline is 4. The description does not need to add parameter information since there are none.

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 'Extract all meta tags' and lists specific types (title, description, canonical, OG tags, Twitter cards, JSON-LD, alternate languages, RSS feeds). This distinguishes it from sibling tools like safari_extract_images or safari_extract_links.

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 extracting metadata from a page but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention 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 implies a read-only operation but does not explicitly state idempotence or side effects. Sufficient for a simple extraction 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?

Two short sentences, zero waste. Front-loaded with verb+resource. Every word 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 two simple parameters and no output schema, the description provides sufficient context for the tool's purpose and usage. Could mention exact output JSON structure, but not necessary for a straightforward extraction.

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% (selector and limit already described). Description adds no additional meaning beyond schema, so baseline 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 states it extracts HTML tables as structured JSON with headers and rows. Distinguishes from sibling extraction tools (extract_links, extract_images, extract_meta).

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?

States 'Perfect for scraping data tables' which implies a specific use case, but no explicit when-not-to-use or alternatives. Nevertheless, the context is clear enough for 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?

No annotations are provided, so the description carries the behavioral burden. It discloses that the tool replaces existing values, automatically handles React/ProseMirror/Draft.js/Closure editors, and that refs expire after new snapshots. This is strong transparency, though it does not mention event side effects or failure behavior.

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

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

The description is compact and front-loaded with the core action and target. Every sentence earns its place: scope, framework handling, alternative routing, and the critical snapshot warning.

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 mutation tool with no annotations and no output schema, it covers the essential information: supported element types, framework compatibility, replacement semantics, sibling-tool routing, and a critical ref-expiry caveat. An agent has enough to invoke 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?

The schema already describes all four parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the lifecycle and freshness requirement of the ref parameter, which is not captured 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 opens with a specific verb and resource: fill/replace a value in an input, textarea, select, or contenteditable. It also distinguishes itself from code-editor tools and character-by-character typing tools, making its scope immediately clear.

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 explicitly says to use safari_replace_editor for code editors and safari_type_text for character-by-character typing, and frames safari_fill as the SETTING action that replaces existing content. The snapshot freshness warning also gives critical operational context for when this tool can be safely invoked.

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 full burden. It discloses the auto-detection behavior but lacks details on side effects (e.g., navigation, error handling) or what happens if no submit button is found.

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 directly convey the core functionality and a key behavior. No redundancy or unnecessary details, 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 simple combined action with two parameters and no output schema, the description adequately explains the tool's purpose and unique auto-detection. Slight improvement could be mentioning potential page navigation, 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% with descriptions for both parameters. The description confirms the auto-detection of submit selector but adds no new semantic information 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 the tool combines filling a form and submitting it in one operation, with automatic detection of the submit button. This distinguishes it from sibling tools like safari_fill, safari_fill_form, and safari_click.

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 cases requiring both fill and submit, but it does not explicitly state when to use it over alternatives like separate fill-then-click operations. No exclusion criteria or alternative tool names 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 are provided, so the description carries the full burden of behavioral disclosure. 'Fill' implies a write operation, but the description does not say whether existing field values are overwritten, whether events are triggered, whether the page is submitted, or what happens if a selector does not match.

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, front-loaded sentence with no filler or redundancy. Every word contributes to the core meaning, making it highly efficient even though it is brief.

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 unannotated mutation tool with no output schema, the description is too sparse to fully guide an agent. It lacks usage alternatives, side effects, edge-case behavior, and any context about why this tool exists alongside safari_fill and safari_fill_and_submit.

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 fields, selector, value, and receipt. The description adds little beyond the word 'multiple' and 'at once,' which loosely aligns with the array-shaped fields parameter but does not add meaningful semantic detail.

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: 'Fill multiple form fields at once.' This clearly describes the bulk-fill action and distinguishes it from single-field fill tools like safari_fill, though it does not explicitly name sibling alternatives.

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 'multiple form fields at once' implies the tool is meant for batch filling, which provides some usage context. However, it gives no explicit guidance about when to choose this tool over safari_fill, safari_type_text, or safari_fill_and_submit, and it does not mention 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?

Description implies a read-only operation but does not disclose details like whether it works on hidden elements, returns values or computed CSS text, or if pseudo-elements are supported. With no annotations, more behavioral context would be beneficial, but the simplicity partly compensates.

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: two short sentences with no superfluous words. Front-loaded action verb. 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?

The description lacks details about the return format (e.g., object of property-value pairs), and does not mention limitations or special cases. Given no output schema, some completeness is missing, but the tool is simple enough that a 3 is fair.

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 both parameters described in the schema. The description adds no new meaning beyond restating the filtering capability, so 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 the tool retrieves computed CSS styles for an element, which is a specific and unambiguous action. It differentiates from siblings like get_element or query_all by focusing solely on computed styles.

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., get_element, evaluate). No when-not-to-use information. The phrase 'optionally filter specific properties' hints at usage but does not set context among siblings.

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?

Without annotations, the description carries full burden. It only mentions the prerequisite but does not disclose whether the call is destructive (e.g., clears messages), if it can be called multiple times, or what happens if start_console was not called. Missing these details reduces 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 a single sentence of 8 words, extremely concise. It front-loads the purpose and includes the essential prerequisite. No unnecessary 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?

For a tool with no parameters and no output schema, the description is adequate but could be improved by stating the return format (e.g., list of strings) or behavior on repeated calls. It covers the prerequisite but leaves some ambiguity about output.

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 and schema description coverage is 100%. The baseline is 4; the description does not need to add parameter information. It correctly omits any param details.

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 function: 'Get captured console messages'. It specifies the resource (console messages) and the verb (Get). The prerequisite differentiates it from sibling tools like safari_clear_console or safari_console_filter, which have distinct 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 description explicitly states a prerequisite: 'must call safari_start_console first'. This provides strong usage guidance. It implies that the tool should only be used after starting console capture. However, it does not explicitly mention when not to use it or suggest alternatives, though the sibling list shows 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, but tool has no parameters and is read-only. Description does not disclose return format or behavior when no cookies exist. Adequate but not rich.

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

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

Single sentence, no redundant words. Front-loaded 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 read tool with no params and no output schema, description covers what it does. Could mention return format but 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?

No parameters, so schema coverage is 100%. Baseline for 0 params is 4; description adds no parameter info but none 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?

Description uses specific verb 'get' and resource 'cookies' with scope 'for the current page'. Clearly distinguishes from siblings like safari_delete_cookies and safari_set_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 explicit guidance on when to use vs alternatives like safari_delete_cookies or safari_set_cookie. Usage is implied but not stated.

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 of behavioral disclosure. It lists output categories but does not state whether the operation is read-only, whether it waits for the element to exist, what happens on selector mismatch (null vs error), or whether it can auto-scroll or trigger side effects. No annotation contradiction exists, but the behavioral disclosure is thin.

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, front-loaded sentence that states the verb, target, and key output fields in a compact parenthetical list. There is no filler, redundant phrasing, or schema repetition. Every part contributes to understanding what the tool does.

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 read tool, this is minimally viable: the agent knows what the tool targets and roughly what it returns. However, with no output schema and no annotations, the description still leaves gaps around result shape, failure behavior, and how this tool differs from similar element-inspection siblings. It is adequate but not 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?

The input schema already describes both parameters (selector and receipt) with 100% coverage, so the description does not need to repeat them. The description adds no parameter-level meaning beyond the schema's own documentation, which is the baseline case where 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 operation ('Get detailed info') and the target resource ('an element'), and enumerates the specific data categories returned (tag, text, rect, attributes, visibility). This makes it reasonably distinguishable from page-level tools like safari_read_page or safari_snapshot, though it does not explicitly contrast itself with sibling element-inspection tools such as safari_get_computed_style or safari_query_all.

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 guidance on when to use this tool versus alternatives like safari_query_all, safari_get_computed_style, or safari_accessibility_snapshot. The description gives no exclusions, prerequisites, or conditions that would help an agent choose this tool over similar siblings. Usage context is only implied by the purpose statement.

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 that the operation is read-only, any permission requirements, or details about pagination or record format.

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, front-loaded sentence with no redundant words. However, it is slightly under-specified, missing useful context without being 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 3 parameters and no output schema; the description does not explain what the tool returns (e.g., array of records), usage prerequisites, or how it relates to other storage 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?

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema provides 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 uses a specific verb 'Read' and resource 'records from an IndexedDB database store', clearly distinguishing it from sibling tools like safari_list_indexed_dbs which lists databases.

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 would be helpful to mention that safari_list_indexed_dbs should be used to discover database names first.

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. It only states 'Get HTML source' without detailing permissions, performance implications, or whether the source is raw or rendered. The lack of extra context reduces 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 a single, front-loaded sentence. It is concise, though it could be slightly expanded with no loss of conciseness. 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?

Given the absence of an output schema, the description should clarify what is returned (e.g., raw HTML string, or structure). It does not mention return format, error cases, or pagination. For a simple tool, this is a notable 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 description coverage is 100% (maxLength has a description). The tool description does not add meaning beyond the schema, which is acceptable for a single optional parameter. 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 action (get) and resource (HTML source of the current page). It distinguishes from siblings like safari_read_page (likely reads rendered text) and safari_snapshot (captures visual snapshot), but could be more explicit about the exact output 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?

No guidance on when to use this tool versus alternatives such as safari_read_page or safari_snapshot. No mention of prerequisites or limitations. The description provides no 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 are provided, so the description carries the full burden of behavioral disclosure. It only says 'Go back in browser history' and does not explain side effects such as whether it mutates the active tab, whether navigation waits for page load, or what happens if history is empty. This is a significant transparency gap for a state-changing navigation 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 a single compact sentence with no filler or redundancy. It delivers the essential purpose immediately and 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?

The tool is simple with only one optional parameter, and the schema covers that parameter well. However, with no annotations and no output schema, the description leaves gaps around tab targeting behavior, expected side effects, and edge-case behavior like navigating back from the first page, so it is adequate but not fully 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 description coverage is 100%, with the schema fully documenting the optional 'receipt' parameter as a tab identifier that survives reconnects and subagents. The description itself adds no parameter-level detail, but the schema already handles that responsibility, so the baseline 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 states a specific action ('Go back') and a resource ('browser history'), making the tool's core purpose clear. It does not explicitly contrast with siblings like safari_go_forward or safari_navigate, but the directionality of 'back' is enough to distinguish it from forward navigation.

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 this tool should be used when an agent needs to move to the previous page in browser history, which offers some usage context. However, it does not explicitly state when to prefer this over safari_navigate or safari_go_forward, and no exclusions or prerequisites 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and does not explain what happens when there is no forward history, whether it affects the current tab or the one specified by the receipt, or any failure behavior. The parameter is only described in the schema, not the tool description.

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 fluff, front-loading the core action. It is appropriately concise for a simple command, though it borders on being too terse given the lack of supplementary 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 large sibling set and the absence of annotations or output schema, the description is incomplete. It does not explain when to use forward versus back or navigate, does not mention tab targeting (though the schema does), and does not address edge cases like empty history. For a tool with a single optional parameter and no output schema, more context is expected.

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 description coverage is 100%, with the 'receipt' parameter fully documented in the input schema. The tool description itself adds no parameter-related information, so the baseline of 3 is appropriate since the schema carries the burden.

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 'Go forward in browser history' states a specific verb and resource, and clearly distinguishes from sibling tools like safari_go_back and safari_navigate. It is unambiguous and immediately 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 is provided on when to use this tool versus alternatives such as safari_go_back or safari_navigate. There is no mention of prerequisites (e.g., requiring a forward history entry) or context like after navigating back. The agent is left to infer usage 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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Set up handler' without explaining that the handler is one-time, that it automatically consumes the next dialog, or what happens if no dialog appears. An agent is left uncertain about side effects and lifecycle, which is critical for a setup action.

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, front-loaded sentence that uses the verb 'Set up' immediately. It is efficient and contains no wasted words. However, it is minimal to the point of lacking depth, but that is more a completeness issue than conciseness.

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 description does not explain the necessary sequence: that this must be called before a dialog appears and that it applies only to the next dialog. Without this, an agent might call it after a dialog has already shown or expect it to handle multiple dialogs. The schema's receipt parameter hints at pinning, but the overall behavioral context is insufficient for a setup tool with no 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?

The schema has 100% description coverage, with each parameter clearly documented (text for prompt dialogs, action with enum and default, receipt for tab pinning). The tool description adds no additional parameter context beyond what the schema already provides. This meets the baseline for high 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 'Set up' and the resource 'handler for the next alert/confirm/prompt dialog'. It is unambiguous and distinctly different from all sibling tools, which focus on navigation, clicking, reading, or extraction. No other sibling handles dialog interactions, so this tool's purpose is immediately clear.

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 preparing to handle a dialog that will appear, but it does not explicitly state when to call it (e.g., before triggering an action that may cause a dialog). It also does not mention alternatives because there are none among siblings, but the timing requirement is left to inference. This is a common gap for setup 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 are provided, so the description carries the full burden of behavioral disclosure. It only restates the action ('Hover over element') and does not explain side effects such as triggering CSS hover states, waiting for visibility, scrolling into view, or whether this is an OS-level vs page-level hover.

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 short sentences with no filler. The core action comes first and the targeting options follow, making it efficiently scannable for an agent.

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 hover action with fully documented parameters, the description is minimally adequate. However, it lacks any clarification of behavior, return value, or selection guidance relative to closely related siblings like safari_native_hover, so some context 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 schema already documents all parameters. The description's 'Use ref, selector, or x/y' groups the targeting modes but adds no new meaning beyond the schema, and it omits mention of the 'receipt' 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 states a specific verb and resource ('Hover over element') and lists the three targeting modes (ref, selector, x/y). It is clear, but it does not explicitly distinguish this from the sibling 'safari_native_hover', so it falls short of full differentiation.

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 guidance on when to use safari_hover instead of alternatives such as safari_native_hover or safari_click. The phrase 'Use ref, selector, or x/y' only describes parameter choice, not tool-selection context 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 disclose behavior. It states the tool restores storage but omits critical details: does it overwrite existing data? Are there side effects? Is it destructive? This gap could lead to unintended state changes.

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 efficiently conveys the main purpose. It is front-loaded and wastes no words. However, it could benefit from slight restructuring to separate usage context from 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?

Given the simple single-parameter schema and no output schema, the description is adequate but not complete. It lacks details on return behavior, potential failure modes, and whether the operation is reversible. More context 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 covers 100% of parameters with a description. The tool description adds 'from safari_export_storage' to clarify source, but this is minimal enhancement. Baseline 3 is appropriate as schema does most of the work.

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: importing storage state from JSON, and specifies what is restored (cookies, localStorage, sessionStorage). It also names the complementary export tool, making it distinct from siblings like delete or set storage 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 usage after safari_export_storage but lacks explicit when-to-use or when-not-to-use guidance. It does not mention prerequisites, potential overwrites, or alternatives, which would help an AI agent decide between this and 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 are provided, so the description carries the full burden. It accurately describes the tool's behavior (validation and return of issues) and implicitly indicates a read-only operation by the verb 'inspect'. However, it could explicitly state that the tool does not modify the page.

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, well-structured sentence that front-loads the purpose and includes key details (checks, return format). Every part is necessary and there is no redundancy.

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 no output schema, the description adequately describes the return structure (parsed attributes + severity-tagged issues). The tool has no parameters and a straightforward function, making the description sufficient for an agent to understand its behavior and output.

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 is empty (0 parameters), and the description correctly implies no input is required. Schema coverage is 100%, so the benchmark is met with a baseline of 4 for 0-parameter tools.

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 validates the viewport meta tag against iOS Safari best practices, listing specific checks (width=device-width, initial-scale, disabled-zoom, viewport-fit=cover) and describing the return value (parsed attributes + severity-tagged issues). This distinguishes it from sibling tools like safari_analyze_page or safari_accessibility_snapshot.

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 viewport validation, but does not explicitly state when to use this tool versus alternatives or provide any exclusions. With many sibling tools, more explicit guidance would improve clarity.

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 needs to disclose behavioral traits. It states a read operation but does not cover edge cases (e.g., empty list, page without IndexedDB support) or return format. Adequate for a simple action 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 redundant information. It is front-loaded with the key 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 simplicity (no parameters, no output schema), the description is mostly adequate. However, it does not hint at the return format (e.g., an array of database names), which would help the agent interpret results.

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 meaning beyond what the schema provides. 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 clearly states the action ('List') and the resource ('all IndexedDB databases') with a specific context ('on the current page'). It effectively distinguishes this tool from the sibling 'safari_get_indexed_db' by indicating it returns a list rather than a single entry.

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 (listing vs. getting specific db) but lacks explicit guidance on when to choose this over alternatives like 'safari_get_indexed_db'. No exclusions or prerequisites 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?

With no annotations provided, the description carries the full burden. It discloses the output scope (includes user's own tabs), the cost (verbose), and the receipt feature ('Tabs this session owns carry a receipt'), which is genuinely useful behavioral context. It doesn't explicitly state read-only/non-mutating behavior, though 'list' strongly implies it.

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 zero waste. Purpose is front-loaded, the verbosity warning earns its place as a cost signal, and the receipt note adds actionable guidance without padding. Appropriately sized for a 0-parameter tool.

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, no-schema tool with no output schema, the description is complete: it states what is returned, the scope, the cost, and the preferred alternative. Nothing an agent needs to invoke or interpret this tool correctly 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?

The tool has zero parameters and schema coverage is trivially 100%, so the baseline is 4. The description adds no parameter meaning, and none is needed — there is nothing for an agent to misconfigure.

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 specific verb and resource ('List every tab in this session's Safari window') and specifies the return content (titles + URLs). It also distinguishes itself from siblings by noting it includes the user's own tabs, which separates it from tab-management tools like safari_switch_tab and safari_close_tab.

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?

Provides clear context that the tool is 'verbose and rarely needed' and explicitly names an alternative ('Prefer keeping the receipt from safari_new_tab over listing'). However, it lacks an explicit positive condition for when to use it (e.g., 'use when you need to enumerate all tabs or recover a lost receipt'), so it stops short of full when/when-not 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 provided. Description states it gets data but does not disclose read-only nature or any other behavioral traits. Minimal but sufficient for a simple read 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?

Single sentence, no filler. Every word 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?

Simple tool with one optional parameter, no output schema. Description explains core behavior adequately. The schema clarifies that omitting key returns all data.

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 100% of the one parameter with a description. The tool description adds no additional meaning 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?

Description uses verb 'Get' and resource 'localStorage data' with scope 'for the current page'. It clearly differentiates from sibling tools like safari_set_local_storage and safari_delete_local_storage.

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 that for setting or deleting, sibling tools should 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 are provided, so the description carries the full burden. It explains that the tool intercepts network requests and works with fetch/XHR, but does not detail side effects (e.g., whether it persists across page loads, if it can be overridden, or how to clear it). The presence of safari_clear_mocks suggests mocks are removable, but the description does not mention this.

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 with two sentences, front-loading the core purpose. Every sentence adds value without redundancy.

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 does not explain what the tool returns (e.g., confirmation or the mocked response). It also omits details about multiple mocks, error handling, or scope. While adequate for a simple tool, it could be more complete for full self-containment.

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 schema already documents both parameters and the nested response object. The description adds no additional parameter-specific meaning beyond what the schema provides (e.g., URL pattern format, response structure). The behavioral note about fetch/XHR is not parameter-related.

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 function: intercept network requests and return a mock response. It specifies compatibility with fetch and XHR, and distinguishes it from siblings like safari_clear_mocks (which removes mocks) and safari_start_network_capture (which captures 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 clear usage context, stating it is useful for testing API error states, offline behavior, or replacing API responses. However, it does not explicitly state when not to use it or mention alternative tools, though the sibling list makes differentiation possible.

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?

Discloses key behaviors: produces trusted events, bypasses WAF, moves cursor, requires visible window. Lacks detail on double-click behavior and error handling, but overall sufficient for a click 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?

Four sentences, no fluff, front-loaded with key benefit and use case. 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?

Covers purpose, use cases, trade-offs, parameter hints, and a prerequisite. No output schema, but return behavior is implied. Slightly incomplete on double-click and failure outcomes, but adequate for the 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 covers all 6 parameters with descriptions. The description adds valuable context: recommends using ref from fresh snapshot, and explains that coordinates move the cursor. Provides usage hints not in 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 it's an OS-level mouse click via macOS CGEvent that produces trusted events, differentiating it from regular clicks. It specifies the resource and action unambiguously.

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?

Explicit use case: when regular safari_click fails with 405/403 errors or blocked form submissions. Also mentions trade-off (physical cursor movement, window visibility) and a prerequisite (use fresh snapshot).

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 shoulders the burden of disclosing behavioral traits. It details that the tool moves the real cursor, dwells for dwellMs to allow tooltips to render, restores the original cursor position by default, and requires a visible window. This covers all key aspects of tool 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?

The description is three sentences, starting with the core functionality, then usage context, then dwell/restore details. It is front-loaded with the most critical information and contains no extraneous words. Every sentence 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?