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

With no annotations, the description carries the full disclosure burden and does meaningful work: it reveals that clicks pass through a denylist then a local safety gate that may refuse, and that refusals are self-explanatory. It does not mention side effects like navigation or form submission triggered by the click, but the safety-gate disclosure is genuinely useful added 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 purpose is front-loaded in the first sentence, followed by a one-line prerequisite, a compact safety note, and a tight Args block. Each sentence carries information and nothing is redundant.

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 three-parameter tool with an output schema and no enums or nested objects, this is near-complete: all parameters, the prerequisite workflow, and refusal handling are covered. It only omits minor behavioral details, such as whether the click waits for navigation or other 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?

Schema description coverage is 0%, so the description must compensate, and it fully does: tab is explained as an index or URL/title substring, selector as a CSS selector, and index as the match selector with default 0. Every parameter receives meaning beyond its bare type.

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 'Click an element', a specific verb and resource, and the sibling list (find_elements, fill, navigate, run_js) makes the distinction immediate. 'Check it with find_elements first' reinforces that this is the action tool rather than the lookup tool.

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

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

It explicitly instructs the agent to verify the element with find_elements before clicking and to relay refusals verbatim rather than retrying. However, it does not state when NOT to use click in favor of fill, run_js, or navigate, so it stops short of full exclusion routing.

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 a critical behavioral trait: it uses the native setter and dispatches input/change events with bubbles: true. This goes beyond what annotations provide (none) and explains why the tool behaves differently from a simple value assignment. It also notes the consequence of not doing this (forms submit empty). However, it doesn't mention potential side effects like triggering validation or focus 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 concise and well-structured. It opens with a one-sentence summary, then explains the important behavioral detail about event dispatch, and finally lists parameters in a clear Args block. Every sentence earns its place, and the critical information about native setters and events 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 complete for a form-filling tool. It covers the key behavioral nuance (event dispatch), explains all parameters, and the output schema exists so return values don't need explanation. It could mention edge cases like non-interactive elements or disabled fields, but these are minor gaps given the tool's simplicity.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'tab' parameter as 'Tab index within window 1, or a substring of its URL or title,' which adds meaning beyond the schema's bare 'Tab' title. It also explains 'index' as 'Which match to fill when the selector hits several. Default 0.' The 'value' and 'selector' parameters are self-explanatory from their names, but the description adds context for the two less obvious ones.

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: 'Type a value into an input, textarea, or contenteditable element.' It uses a specific verb ('fill') and resource (form fields), and distinguishes itself from siblings like click and run_js by focusing on setting values with native setters and dispatching events.

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

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

The description explains why this tool is needed over a naive assignment, mentioning frameworks like React and Google Forms that require input/change events. It doesn't explicitly name alternatives, but the context about event dispatch implies when to use this tool versus simpler approaches. It could be improved by explicitly stating when not to use it (e.g., for clicking buttons, use click).

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 behavioral burden. It discloses that the tool returns JSON with per-match fields (tag, id, class, visible text, href, name, type, current value) and a default limit of 20. It could mention whether it has side effects, but as an inspection tool, its non-destructive nature is reasonably implied.

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 well-structured and front-loaded with the core purpose, followed by a brief usage note and a concise Args section. It avoids fluff, though the Args section slightly overlaps with schema titles.

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

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

Given the tool's moderate complexity and the descriptive return-value explanation, the description is largely complete. It could benefit from noting that it matches all elements matching the selector and does not alter state, but overall it provides the needed context.

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

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

Schema description coverage is 0%, so the description compensates. It explains tab as a tab index or substring of URL/title, selector as a CSS selector, and limit as max elements with default 20. This adds meaningful guidance beyond the bare 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 a specific verb and resource: inspect elements matched by a CSS selector. It differentiates itself by emphasizing pre-action validation and reading the index for click or fill, distinguishing it from sibling 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?

It explicitly says when to use: check that a selector hits the right elements and read the index to pass to click or fill. It does not name alternative tools, but the context is clear enough for an agent to decide.

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 behavioral burden itself. It discloses the addressing scheme (1-based index within window 1 or URL/title substring) and the exact one-line return format. It doesn't spell out side-effect-freedom or edge cases, but 'List' and the output format make the read-only behavior clear enough.

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 short, focused paragraphs with no filler. The main purpose is front-loaded, and each sentence adds a distinct piece of information: purpose, when to call it, handle format, and output format.

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

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

For a zero-parameter list tool with an output schema, the description is complete: it states scope, return format, and how the result should be used downstream. No critical information is missing for an agent to select and call it.

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 takes no parameters, so the empty schema is already complete. The description adds useful context about what the returned handle means, which is the closest analog to parameter semantics for this 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 opens with a specific verb and resource ('List every open Safari tab') and immediately explains what makes this tool distinct: it returns the handle needed by other tab-based tools. It differentiates from siblings by framing itself as the discovery/entry point.

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

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

It gives an explicit directive ('Call this first') and explains why, stating that other tools take a tab argument and need the handle this tool provides. This tells an agent when to invoke it relative to every sibling.

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 behavioral disclosure burden and does it well: it says the tool waits for load completion, returns the final URL after redirects, and automatically percent-encodes characters Safari would otherwise reject. It does not describe timeout or failure behavior, but adds substantial useful 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 compact, front-loaded with the core action, and uses a clear Args block. Every sentence adds value: behavior, return value, encoding quirk, and parameter semantics are all covered 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?

For a two-parameter navigation tool, the description is complete: it defines tab addressing, URL handling, load-waiting behavior, and redirect awareness. The output schema exists, and the description already provides the important return meaning. No critical calling 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 0%, so the description must explain the parameters. It does: 'tab' gets rich semantics (index within window 1, or substring of URL/title), and 'url' receives context from the percent-encoding note. 'Where to send it' is minimal, but the overall description compensates well.

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: 'Point an existing tab at a URL and wait for the load to complete.' It clearly distinguishes itself from siblings like open_tab by emphasizing 'existing tab,' and from read_page by focusing on 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 when to use the tool (when you need an existing tab to navigate to a URL), but it never explicitly names alternatives or states when not to use it. The 'existing tab' wording hints at the distinction from open_tab, but the guidance is left to inference.

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 cover behavioral aspects. It discloses that the tool waits for the page to finish loading, which is a significant behavioral trait, and explains that the final URL may differ due to redirects, adding valuable context. However, it doesn't mention potential side effects like affecting the tab list or requiring network permissions, which could be relevant but not essential.

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

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

The description is concise and well-structured: the first line states the primary action, followed by usage guidance, then a note about the return value. Each sentence serves a purpose, and the argument documentation is minimal but adequate. 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?

With a single parameter, a clear output schema (returning tab handle and final URL), and no annotations, the description covers the essential use case and key behavior. It could go into more detail about error handling (e.g., invalid URLs) or if simultaneous tabs are supported, but for a tool of this simplicity, it is sufficiently complete for an agent to invoke correctly.

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

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

Schema coverage is effectively 0% (no description in the schema), so the description must compensate. It explains that parentheses and spaces in the URL are encoded automatically, which goes beyond the schema's minimal type definition. It doesn't elaborate on the URL format (e.g., must be fully qualified), but the provided handling of special characters is useful and relevant.

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 opens a URL in a new Safari tab and waits for loading, with a specific verb ('Open'), resource ('URL'), and context ('new Safari tab'). It also distinguishes itself from the sibling 'navigate' by noting that it preserves the user's current page, avoiding ambiguity.

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 advises to prefer this tool over 'navigate' when starting a task, citing the benefit of leaving the user's current reading untouched. This provides clear when-to-use guidance and names the alternative, leaving no inference needed.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses that the tool returns rendered innerText reflecting what a person sees rather than raw markup, which is valuable behavioral context beyond the tool's name. It does not discuss side effects or failure modes, but the read-only nature is strongly implied.

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 well-organized: a one-line summary, a concise rationale for preferring this tool, then a compact Args block. Every sentence earns its place, and the most decision-relevant guidance ('prefer it over screenshots') 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?

All three parameters are explained sufficiently for correct invocation, and the output schema likely covers return details. Minor gaps remain—what happens when selector matches multiple elements, and how read_page compares to find_elements—but the core usage context is complete 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 description coverage is 0%, so the description fully compensates. It explains tab as an index within window 1 or a URL/title substring, defines selector as optional CSS that defaults to the whole page, and clarifies max_chars truncation with its 8000 default. This adds meaning far beyond the bare 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 states a specific verb ('read') and resource ('visible text of a tab, or of one element inside it'), and explicitly contrasts itself with screenshots and raw markup ('rendered text (innerText)... rather than raw markup'). This makes the tool's purpose unmistakable and differentiates it from siblings like find_elements and run_js.

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

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

It gives clear invocation guidance: prefer this over screenshots, omit selector to read the whole page, and use selector to target a specific element. It does not explicitly say when not to use it or directly name sibling alternatives like find_elements, but the context is sufficient for an agent to route correctly.

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 behavioral disclosure burden. It usefully explains that code runs as a function body, requires `return`, and that results are JSON-encoded (so return plain data, not DOM nodes). It does not mention error handling or side effects, but it discloses the key execution semantics an agent 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?

The description is tightly organized: a one-line purpose, a short usage hint, two behavioral sentences, and two bullet-style parameter explanations. Every sentence earns its place and the most important information 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?

For an arbitrary-JS tool with no annotations and a minimal schema, the description covers tab targeting, code execution, and return-style expectations. It could add notes on error behavior or async handling, but it contains enough to call the tool correctly in typical cases.

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 0%, so the description fully compensates. It explains `tab` as a tab index within window 1 or a URL/title substring, and `code` as JavaScript to execute with `return` for results. Both parameters gain meaning beyond their bare string type.

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 ('Run arbitrary JavaScript in a tab') and immediately differentiates itself from siblings with 'The escape hatch; prefer the others.' An agent can tell exactly what it does and how it relates to the other 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?

Provides clear usage context by labeling itself an escape hatch and advising to prefer the other tools, which implies using it only when the dedicated siblings do not cover the need. It does not name specific alternative conditions, but the guidance 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.