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 main behavior (navigating back) and the return value (page representation), which provides some context. However, it omits important edge-case details such as behavior when there is no history, whether it waits for page load, and the exact nature of the 'page representation,' leaving gaps in 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 two concise sentences, front-loading the action and then adding the return type. There is no filler, redundancy, or unnecessary detail; 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 one well-documented parameter and no annotations or output schema. The description covers the core purpose and return, which is largely sufficient. It could be improved by mentioning how the 'detail' parameter affects the returned representation or failure behavior with an empty history, but overall it is complete for a simple tool.

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

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

The input schema provides 100% coverage for the single optional 'detail' parameter, including its enum and description. The tool description adds no additional parameter information, but the baseline of 3 applies given the high schema coverage.

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

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

The description uses a specific verb ('Navigate back') and resource ('browser history'), clearly distinguishing this from sibling tools like charlotte_forward and charlotte_navigate. It also states the return value ('page representation after navigation'), leaving no ambiguity about its function.

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 by stating the action ('navigate back'), but it does not explicitly mention when to prefer this over alternatives (e.g., charlotte_forward, charlotte_navigate) or provide exclusions. There is no guidance on scenarios like empty history, but the action itself is a clear directive.

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 transparency burden. It does disclose that the tool returns a full page representation after the click, which is useful. However, it does not mention potential side effects like navigation, form submission, or waiting behavior, which are important for a click 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 two sentences, concise and front-loaded with the action and return value. Every word earns its place, with no fluff or repetition.

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 basic click tool, covering the action and return value. However, it lacks any mention of the sibling tool charlotte_click_at, does not explain what 'full page representation' entails, and omits potential side-effect warnings. More context is needed for full 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 provides descriptions for all three parameters (element_id, click_type, modifiers) with 100% coverage. The description itself adds no extra parameter context, so it relies on the schema, matching the baseline score.

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 clicks an interactive element on the page, which distinguishes it from scrolling, typing, and navigation. However, it does not explicitly differentiate from charlotte_click_at, which is a sibling tool likely for coordinate-based clicks, leaving the distinction implied through the word 'element'.

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 'interactive element' implies element-based clicking, which suggests using this tool over charlotte_click_at, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The guidance is implied rather than explicit.

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 responsibility for behavioral disclosure. It reveals that the click dispatches 'real CDP-level mouse events' and returns a 'full page representation' after the click. While it doesn't cover every edge case (e.g., out-of-viewport coordinates, waiting for navigation), it provides the core behavioral traits relevant to a coordinate 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?

Three sentences, each earning its place: action statement, usage context, and return behavior. No filler or redundancy. The structure is front-loaded with the core purpose.

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

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

The tool is simple (4 params, no output schema), and the description covers the return value ('full page representation') and the type of events dispatched. It doesn't mention prerequisites like page load state, but such details are likely unnecessary for a click tool with clear semantics. Overall, it is sufficiently complete for the tool's 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?

The input schema already documents all four parameters with clear descriptions, including enum values for modifiers and click_type (100% coverage). The description adds no additional parameter semantics beyond labeling x/y as 'page coordinates', so the 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?

The description clearly states the tool's function: 'Click at specific page coordinates' with a specific verb and resource. It also distinguishes itself from the sibling element-based click tool by noting it's for when elements are not in the accessibility tree (custom widgets, canvas, non-semantic interactive divs).

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 provides when-to-use guidance: 'Use when target elements are not in the accessibility tree...' This implies not to use it when elements are accessible, effectively differentiating it from alternatives like charlotte_click. The mention of CDP-level events preempts expectations about event orchestration.

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 transparency burden. It discloses the output type (structural diff with added/removed/moved/changed elements) and implies a read-only comparison, but it doesn't explicitly state that it is non-destructive or mention prerequisites like the existence of a previous snapshot. Some behavioral context is added, but not comprehensive.

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

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

The description is composed of two short sentences that front-load the primary action and the return value. There is no redundant phrasing or filler, making it highly concise and well-structured.

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 two optional, well-documented parameters and no output schema, the description provides the core purpose and a high-level summary of return categories. It does not explain snapshot prerequisites or error behavior, but the combination of description and schema is sufficient for the tool's apparent 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?

The schema covers both parameters 100%, with scope enum descriptions and snapshot_id details. The tool description itself adds no additional parameter semantics beyond what the schema already provides, 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 uses the specific verb 'Compare' with a clear resource ('current page state to a previous snapshot') and states the return type ('structural diff showing added, removed, moved, and changed elements'). This distinguishes it from sibling tools that operate on the live page (e.g., click, type, observe) and makes the tool's 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 provides a clear context: use this tool when you need to see differences between the current page state and a previous snapshot. It doesn't explicitly list exclusions or alternatives, but the diff focus is obvious among the siblings, which are mostly navigation and interaction 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 full burden and discloses important behaviors: selector reaches non-accessibility-tree elements, results return durable Charlotte element IDs re-resolved against the live DOM, and output_file writes to a file with a confirmation. It omits details on behavior when no filters are provided or whether hidden elements are included, leaving minor gaps.

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

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

The description is well-structured: lead purpose statement, filter list, selector explanation, then output_file behavior. Every clause adds functional detail without redundancy or fluff.

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 covers the main search use case, the unique selector capability, and output_file output, but does not specify the return format for inline results or behavior when no criteria are supplied. This is a minor gap 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 coverage is 100%, so baseline is 3. The description adds meaning beyond the schema for selector (durable IDs, re-resolution, works with fill_form) and output_file (confirmation with path and size, use for broad selectors), justifying a score above baseline.

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 'Search for elements matching criteria' with specific filters (text, role, type, spatial proximity) and highlights the selector parameter for DOM access. This distinguishes it from sibling action tools like click, type, and navigate by focusing on search/find.

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 recommends using the selector parameter to find elements not in the accessibility tree, providing clear contextual guidance. However, it does not explicitly state when not to use the tool or compare it to alternatives, so it stops short of full exclusionary usage advice.

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 return behavior ('Returns page representation after navigation'), but does not specify edge cases like what happens when there is no forward history, or how 'page representation' is structured. This is adequate but minimal.

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 concise sentences with no wasted words. It front-loads the primary action and then describes the return value, making it easy to scan.

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

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

The tool is simple (one optional parameter, no output schema), and the description covers the essential purpose and return behavior. It could mention edge cases, but given the low complexity, 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?

Schema description coverage is 100% for the single optional 'detail' parameter, with enum values and descriptions. The tool description does not add parameter information, but the schema fully documents it, 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 'Navigate forward in browser history', using a specific verb and resource. It distinguishes itself from sibling tools like charlotte_back (backward navigation) and charlotte_navigate (URL 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 clearly implies when to use this tool (when the user wants to go forward in browser history). It doesn't explicitly mention alternatives or exclusions, but the context is clear enough given the sibling tool names.

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

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

No annotations are present, so the description carries the full transparency burden. It discloses that the tool returns a page representation, specifies the default minimal detail contents (landmarks, headings, interactive element counts), and mentions the 'summary' option for more detail. While it doesn't cover failure modes, it provides meaningful behavioral context beyond a simple 'navigate' statement.

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 main action, and every phrase earns its place. It efficiently communicates the primary function, return type, default output detail, and an alternative tool reference without any fluff.

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 navigation tool with no output schema, the description adequately explains the return representation and the effect of the 'detail' parameter. It also names an alternative for element location. Minor gaps exist around failure behavior and exact output semantics of the 'summary' vs 'full' detail levels, but the schema fills in parameter specifics.

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 parameters are already well-documented. The description adds context about the default detail behavior and what the returned representation includes, which supplements the 'detail' parameter. However, it doesn't add new meaning for url, timeout, or wait_for beyond what the schema provides, keeping this at baseline 3.

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

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

The description opens with a specific verb+resource ('Load a URL in the active page') that clearly defines the tool's core function. It distinguishes itself from sibling navigation tools (back, forward, reload) by focusing on URL loading, and also clarifies its relationship to charlotte_find.

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

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

The description explicitly directs users to charlotte_find for locating specific elements, providing a clear alternative. It also explains when to use the 'summary' detail level, giving context on how to adjust output. It doesn't explicitly state when not to use navigate, but the alternative guidance is strong enough for a 4.

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 of behavioral disclosure. It states 'without performing any action' (non-mutating), explains cost trade-offs ('cheapest', 'still much cheaper than minimal JSON'), and reveals output behavior for output_file ('Returns only a confirmation with the file path and size'). This provides meaningful context beyond the schema, though it omits potential error conditions or page-load requirements.

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 dense but well-structured: it leads with the main purpose, then explains optional parameters in a logical flow. Each sentence adds operational value without filler. Slightly longer than ideal, but the complexity of 5 parameters and absence of annotations justify the length.

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 params, no output schema, no annotations), the description covers the essential aspects: purpose, parameter behaviors, alternatives, and cost considerations. It lacks explicit return format details for the default view, but for a read-only observation tool, the provided information is sufficient for an agent to select and 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?

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining detail level semantics (minimal/summary/full), view trade-offs (tree vs tree-labeled with cost estimates), and output_file resolution ('relative paths resolve against output_dir'). This goes beyond the bare enum names and provides actionable guidance for parameter selection.

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: 'Get current page state without performing any action.' The verb 'get' and resource 'page state' precisely convey the read-only nature, distinguishing it from action-oriented siblings like charlotte_click and charlotte_type. Mentioning charlotte_find and observe variants further differentiates it from element-finding 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?

Explicitly directs when to use alternatives: 'use charlotte_find to get specific elements with actionable IDs' and 'or observe({ detail: "summary" }) to see all elements.' Recommends view: 'tree' as the 'cheapest orientation tool,' giving clear context on when to choose this tool 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?

With no annotations, the description carries the behavioral disclosure burden. It does state that the tool returns a page representation after reload, which is valuable. However, it does not mention potential side effects such as losing unsaved form state, and the 'hard' parameter's cache-bypass behavior is only in the schema, not the 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?

One concise sentence that immediately states the action and outcome. Every word earns its place with no filler 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?

For a simple reload action with two fully documented optional parameters and no output schema, the description provides adequate context: it says what the tool does and what it returns. Slightly more detail on how 'detail' affects the returned representation could improve it, but the schema already covers that.

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%: both 'hard' and 'detail' already have meaningful descriptions in the input schema. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Reload') with a clear resource ('current page') and explicitly states the return value ('Returns page representation after reload'). It is distinct from sibling navigation tools like charlotte_navigate, charlotte_back, and charlotte_forward.

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 usage context is implied: reload the current page when a refresh is needed. However, there are no explicit guidelines on when to choose this over alternatives like navigate or back/forward, nor any exclusionary conditions.

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 transparency burden. It adds useful context about the persistent behavior of save:true and the tool's fallback role. However, it does not disclose the default return format (e.g., inline base64), whether the operation has side effects beyond saving, or that it is a read-only action. These are notable omissions for an unannotated tool, but the provided behavior hints (persistence, fallback) prevent a lower score.

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

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

The description is two sentences long, front-loaded with the primary verb behavior ('Capture a visual screenshot'), then a use-case clause, then a targeted parameter tip. Every sentence earns its place; no filler or redundant restatement of the tool name.

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

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

Given the tool has 6 parameters, no output schema, and no annotations, the description does more than a minimal effort by establishing purpose and usage guidance. However, it leaves important contextual gaps: the default return format (base64) is not mentioned, and there is no hint about how to later retrieve saved artifacts (e.g., charlotte_screenshot_get). This is adequate but not fully complete for an agent making an uninformed 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 the schema already documents all six parameters with meaningful descriptions. The description adds a bit of extra context for 'save' (persisting as a file artifact) but largely repeats what the schema explains. It neither contradicts nor significantly enhances the schema's parameter documentation, so the 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?

The description opens with a specific verb+resource phrase ('Capture a visual screenshot'), clearly stating the tool's core function. It further distinguishes the tool from siblings by framing it as a 'fallback for when structured representation isn't sufficient,' referencing complex visualizations, canvas elements, and images—which implicitly contrasts with observation-oriented siblings.

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 explicit when-to-use context: 'Fallback for when structured representation isn't sufficient' and gives concrete example cases (complex visualizations, canvas elements, images). It also offers conditional parameter guidance ('Use save: true to persist as a file artifact'). It stops short of naming a specific alternative sibling tool or outright saying 'do not use for simple text/structured content,' so it earns a 4 rather than 5.

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 disclosing side effects. It explicitly states 'Removes the file from disk,' which conveys the destructive, persistent nature of the operation. It does not detail error handling or permissions, but for a simple delete operation, this is substantial 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 short sentences, front-loads the core action, and contains no filler or repetition. Every word contributes meaning.

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

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

For a simple deletion tool with one parameter and no output schema, the description adequately covers the action and its effect. It does not mention how to obtain the ID or that the deletion is permanent, but the essentials are present, and the simplicity of the tool reduces the need for further 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?

The input schema already has 100% coverage, documenting the single 'id' parameter as 'Screenshot artifact ID to delete.' The description adds little beyond restating 'by its ID,' so the schema carries the semantic weight. This matches the baseline for high schema coverage.

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

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

The description uses a specific verb ('Delete') and clearly identifies the resource ('saved screenshot artifact') and the required identifier ('by its ID'). It is unambiguous and distinguishes this tool from sibling tools like charlotte_screenshot_get, which retrieves rather than deletes.

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 a saved screenshot artifact needs to be deleted—but gives no explicit guidance about when not to use it or alternatives. It does not mention that this is the only tool for deletion or that retrieval tools should be used for other purposes.

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. The verb 'Retrieve' clearly implies a non-destructive read-only operation, and 'Returns the image data and metadata' sets expectations for the output. No side effects or special requirements are mentioned, but for a simple retrieval tool this is sufficient.

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 states the action, the target resource, and the return value without any redundant wording or filler.

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

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

The tool has only one parameter and no output schema, so the description needs to explain the outcome, which it does ('Returns the image data and metadata'). For a simple getter, this is fully complete and requires no additional 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?

The input schema covers the only parameter 'id' with a clear description and format example. The tool description adds only 'by its ID', which reinforces the schema without adding new semantic meaning. Given 100% schema coverage, the 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?

The description uses a specific verb ('Retrieve') and resource ('saved screenshot artifact by its ID'), making the operation clear. It also distinguishes from sibling tools like charlotte_screenshot (which likely captures a new screenshot) and charlotte_screenshot_delete (which deletes) by focusing on retrieval.

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 context that this tool is for previously saved screenshots, implying it should be used when an artifact ID is already available. It does not explicitly name alternatives or exclusions, but the sibling tool names and the phrase 'previously saved' give practical 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 burden. It discloses that the tool returns metadata (not image contents), which is useful. However, it doesn't mention pagination, limiting, ordering, or whether the list spans multiple sessions. The read-only nature is implied by 'List' but not explicitly stated. There is no contradiction with annotations since none exist.

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 consists of two short sentences that are direct and information-dense. Every word contributes: 'List', 'all saved screenshot artifacts', and the specific metadata fields. 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?

Given the tool's simplicity (no parameters, no output schema), the description is largely complete. It clearly states the tool lists all saved artifacts and specifies the metadata fields returned. It does not explain edge cases like empty lists or error scenarios, but for a list operation with no inputs, the provided information is sufficient for an agent 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 tool has zero parameters and the schema coverage is 100% (empty properties). The description adds no parameter details, but none are needed. By the rubric, zero params gives a baseline of 4, and the description does provide additional context about what the returned metadata includes (ID, filename, page URL, timestamp) which is helpful.

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 action ('List all saved screenshot artifacts') and the resource (saved screenshots). It distinguishes from sibling tools like charlotte_screenshot (capture) and charlotte_screenshot_get (fetch one) by focusing on listing all saved artifacts.

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

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

The description clearly indicates when to use the tool: when you need to list all saved screenshot artifacts. It doesn't explicitly mention exclusions or alternatives, but the context is unambiguous given the sibling tool names. A minor gap is lack of guidance on when to use this vs. charlotte_screenshot_get or charlotte_screenshot_delete, but the primary use case is evident.

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 does disclose that the tool returns a full page representation after scrolling, which is useful behavioral context. However, it does not mention any potential side effects, prerequisites, or the nature of the scroll (e.g., instant, smooth). The safety/read-only nature is inferred 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 two concise sentences: one for the action and one for the return value. There is no redundant or filler content, and the key 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?

The tool is relatively simple with 3 parameters, all well-documented in the schema. The description covers the action and explicitly mentions the return value, which is important since there is no output schema. However, 'full page representation' is a bit vague, and the lack of annotations leaves safety assumptions implicit. Overall, it is reasonably complete for a scroll 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%, with each parameter (amount, direction, element_id) already described. The description adds little beyond the schema, only hinting at element_id via 'specific container'. Since the schema does the heavy lifting, 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 uses a specific verb ('Scroll') and a resource ('page or a specific container'), which clearly differentiates it from sibling tools like charlotte_navigate or charlotte_observe. It also states the outcome ('Returns full page representation after scrolling'), 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?

No explicit guidance is given about when to use this tool versus alternatives. The usage is implied by the action itself (scrolling), but there is no mention of exclusions or alternative tools, such as using navigation for moving between pages. This is a minimum viable level of 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool returns a full page representation after selection, which is useful, but it does not mention side effects, prerequisites (e.g., element visibility), or event triggering. This is a basic but not comprehensive behavioral 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 two short sentences that immediately state the core function and the return behavior. It is front-loaded with the action, contains no fluff, and is appropriately sized for the tool's simplicity.

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

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

For a simple two-parameter tool with no output schema, the description covers the essential points: what it does and what it returns. It could be marginally improved by noting that it is specifically for dropdowns, but the description and schema together provide sufficient context for an agent to use it correctly.

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

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

The input schema already covers 100% of parameters with clear descriptions ('Value or text of the option to select' and 'Target select element ID'). The tool description adds no additional semantics beyond restating the purpose, so the schema is the primary source of parameter meaning.

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 ('Select an option') and the target resource ('select/dropdown element'), making it distinct from sibling tools like charlotte_click or charlotte_type. It also notes the return behavior, further clarifying its function.

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 interacting with select/dropdown elements, which provides context on when to use it. However, it does not explicitly contrast it with alternatives like charlotte_click or charlotte_toggle, nor does it mention scenarios where it should not be used.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state the return value ('Returns full page representation after submission'), which is useful. However, it does not disclose that submitting a form is a mutating action with potential side effects (e.g., data changes, navigation, or irreversible submissions). The description mentions a 'clicking' method without clarifying whether it simulates a user click or requires the button to be visible, which is a behavioral gap.

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

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

The description is concise at two sentences, with the primary action front-loaded. The second sentence adds return information without excessive detail. The 'Can submit by form ID or by clicking its submit button' clause is somewhat ambiguous but does not significantly bloat the description. Overall, it is appropriately sized for a simple 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 tool with one parameter and no output schema, the description covers the core action and return value, which is fairly complete. However, it omits prerequisites (e.g., needing to be on a page with a form, ensuring the form_id is valid) and does not clarify the 'clicking' method. The mention of an alternative submission method without explaining how to invoke it via the schema reduces completeness. Given the tool's simplicity, a score of 3 is appropriate.

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 covers the single parameter 'form_id' with a description ('Form ID from page representation'), giving a baseline of 3. However, the description introduces an alternative submission method ('or by clicking its submit button') that is not represented in the schema, making the parameter semantics confusing. It doesn't add meaningful detail about how form_id is used or obtained, and the alternative method could mislead the agent into expecting an additional 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 clearly states the tool's purpose: 'Submit a form.' This specifies the action (submit) and the resource (form), distinguishing it from sibling tools like charlotte_click or charlotte_type. However, the added 'Can submit by form ID or by clicking its submit button' introduces ambiguity about how submission is performed, detracting from full clarity.

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 explicit guidance on when to use this tool versus alternatives like charlotte_click. It mentions two submission methods (by form ID or clicking the submit button) but does not explain when one should be preferred, nor does it contrast with sibling tools that could also perform similar actions. This leaves the agent without clear selection criteria.

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 disclosure burden. It adds useful context beyond the action itself: if the closed tab was active, it switches to the first remaining tab. This discloses a side effect that an agent would not otherwise know.

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 with no redundant words. It front-loads the core action and then adds one key behavioral detail, making it easy to parse quickly.

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

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

For a single-parameter tool with no output schema, the description is largely complete. It could benefit from mentioning where the tab_id comes from (e.g., from charlotte_tabs), but the sibling context and clear action make this a minor gap.

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

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

Schema coverage is 100% because the only parameter is tab_id with a clear description. The description's 'by its ID' merely restates the schema, adding no additional semantic detail about the parameter's format or source.

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 the specific verb 'Close' and resource 'browser tab', clearly distinguishing this tool from siblings like charlotte_tab_open and charlotte_tab_switch. The addition 'by its ID' specifies the exact input needed.

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

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

The description makes the usage context obvious: use this when you want to close a browser tab. It doesn't explicitly mention alternatives, but sibling tool names (tab_open, tab_switch) provide enough differentiation to infer when this tool 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?

With no annotations, the description carries the full burden. It effectively discloses the key behavioral traits: a new tab is created, optional navigation occurs, and the new tab becomes active. For a simple tool, this is sufficient, though it could mention that the previous tab remains open.

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 concise sentences, with key information front-loaded. Every word earns its place, avoiding 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?

For a single-parameter tool with no output schema, the description fully covers the purpose and behavior. It is complete enough for an agent to select and invoke the tool 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 100% with the url parameter already described as 'URL to navigate to (default: blank page)'. The description does not add significant new semantics beyond repeating the optionality, 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 uses a specific verb ('Open') and resource ('browser tab'), clearly stating the action. It also distinguishes itself from sibling tools like charlotte_tab_switch and charlotte_tab_close by focusing on opening a new 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?

The description provides clear context: opens a new tab and optionally navigates to a URL, with the new tab becoming active. However, it does not explicitly mention when to use this tool instead of charlotte_navigate (which likely navigates the current tab), leaving a slight gap in alternative 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?

With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates a read-only listing operation and the content of the results. It does not mention pagination or ordering, but for a zero-parameter tool with straightforward behavior, this is adequately 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 that front-loads the action and resource. Every word adds value, with no redundancy or filler.

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

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

For a zero-parameter, no-output-schema tool, the description fully specifies what the tool does and what information is returned. There are no missing details that would prevent an agent from using 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 tool has zero parameters, and the schema coverage is 100% (vacuously). Baseline for zero parameters is 4. The description adds no parameter-specific detail because none exists, which 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 uses the specific verb 'List' and clearly identifies the resource as 'all open browser tabs', while also specifying the fields returned (URLs, titles, active status). This distinguishes it from sibling tools such as charlotte_tab_open, charlotte_tab_switch, and charlotte_tab_close.

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 obtaining an overview of tabs, but it does not explicitly contrast with alternatives or state when to use this tool versus opening, switching, or closing tabs. Usage context is present but not explicit.

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 burden of disclosure. It does reveal an important behavioral aspect: the tool returns the page representation of the activated tab. However, it does not mention what happens if the tab ID is invalid, whether focus changes, or any side effects beyond the switch. This is 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?

The description is two short sentences, no filler, and front-loads the action. Every word contributes to understanding the tool's purpose and return 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?

For a simple tool with one parameter and no output schema, the description provides the essential information: what it does and what it returns. Some details like error cases are not covered, but the tool's simplicity makes the description sufficiently complete for an agent 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 provides 100% coverage for the single parameter tab_id with the description 'ID of the tab to switch to'. The tool description adds minimal extra meaning beyond restating 'by its tab ID', so it does not improve on the schema. Baseline 3 is appropriate given high schema coverage.

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

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

The description uses a specific verb ('Switch') and resource ('different browser tab') with the input identifier ('by its tab ID'). It clearly distinguishes itself from sibling tools like charlotte_tab_open and charlotte_tab_close by focusing on switching to an existing tab, and it also specifies the return value.

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

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

The description makes the basic usage clear (switch to a tab by ID) but does not explicitly state when to prefer this over alternatives like charlotte_tabs or charlotte_tab_open. There are no exclusions or prerequisites mentioned, so guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the burden. It discloses the return format ('full page representation') and implies a state change by using 'toggle', but it does not detail behavior in edge cases (e.g., if already checked), potential side effects, or whether it waits for 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 sentence that states the action, the target element type, and the return behavior. It is concise with no redundant 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 one-parameter browser automation tool, the description adequately covers its purpose and return value. It lacks explicit prerequisites like visibility or interactability, but those are likely implied by the platform context and the simple nature of the action.

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

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

Schema description coverage is 100%, and the only parameter 'element_id' is described in the schema. The tool description adds no semantic detail beyond that, 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 clearly identifies the tool's action as toggling a checkbox or switch element and specifies the return value (full page representation). This distinguishes it from siblings like click, select, and submit by focusing on checkbox/switch toggle behavior.

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 the target element is a checkbox or switch. However, it does not explicitly contrast it with the click tool or state exclusions, so it stops short of full 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?

With no annotations, the description carries the burden of disclosing behavior. It explains that disabled tools don't appear and that enabling groups is needed to use their tools. It also defines the scope of each group. It could mention persistence or side effects, but for a visibility toggle this is sufficient.

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 appropriately sized. The first sentence states the purpose, the second explains behavior, and the rest enumerates groups efficiently. Every sentence provides useful information with 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?

For a simple tool with two parameters, no output schema, and no annotations, the description thoroughly covers purpose, behavior, and parameter semantics. It gives enough context for an agent to select the right group and 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 coverage is 100% with enums, so the baseline is 3. The description adds significant value by describing what each group contains (e.g., 'interaction' for form filling/clicking) and clarifying the default 'list' action, which goes beyond the generic 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 clearly states the verb+resource: 'Manage Charlotte tool visibility' and immediately explains the list/enable/disable actions. It is easy to distinguish from sibling tools, which perform specific browser actions like clicking or navigating.

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 when to use the tool: to list groups/status and to enable or disable groups. It also clarifies the consequence (disabled tools don't appear) and that enabling is required to access tools. It does not explicitly mention alternatives or exclusions, but the context is clear.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states the return type (full page representation) but does not disclose that typing may clear existing content by default, can trigger events, or requires the element to be visible/interactable. The default clearing behavior (clear_first: true) is only discoverable through the schema, not the 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 two concise sentences with no wasted words. It front-loads the primary purpose and adds a useful behavioral note about the return representation, fitting the appropriate structure for a simple 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?

Despite having 6 parameters and no output schema or annotations, the description is minimal but sufficient to understand the core action. The schema covers parameter semantics, and the description states the return type. However, it lacks context about default behaviors (e.g., clearing the field, pressing Enter) that would help an agent anticipate side effects, making it adequate but not comprehensive.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself does not add meaning beyond the schema, but the schema parameters are well-documented with descriptions for each field. Since the description does not need to repeat schema details, a 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 a specific verb ('Type') and resource ('input element'), and explicitly notes it returns the full page representation after typing. This distinguishes it from sibling tools like charlotte_click, charlotte_select, and charlotte_submit, which perform different 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 implies the tool should be used when text needs to be entered into an input element, but it does not explicitly discuss when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. No guidance is given for distinguishing between typing and using charlotte_submit or charlotte_click for form interactions.

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