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 does not mention whether the tool waits for the element, scrolls it into view, or handles failures. This lack of detail leaves the agent without essential behavioral expectations.

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 very short and front-loaded, but it is under-specified. While it avoids unnecessary words, it sacrifices crucial information, making it less useful than a slightly longer but more informative description.

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

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

Given the lack of annotations, output schema, and parameter explanations, this one-sentence description is inadequate. It does not address return values, session requirements, timeout behavior, or error handling, leaving significant gaps.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only mentions the selector, leaving sessionId and timeoutMs undocumented. This is insufficient for correctly invoking the tool.

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

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

The description clearly states the action (click) and the target (an element) using a selector. It is specific and understandable, but it does not differentiate from sibling tools like fill or select_option that also interact with elements.

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

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

The description provides no guidance on when to use clicking versus alternatives, nor any prerequisites or exclusions. It only states the basic action without 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 full responsibility for disclosing behavior. It states the action but does not mention that closing is irreversible, whether it fails on non-existent sessions, or what side effects it has on resources. For a state-changing operation, this lacks transparency.

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

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

The description is a single sentence with zero wasted words. It is front-loaded with the action and resource, making it immediately understandable.

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

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

While an output schema exists and the tool is simple, the description omits essential context such as safety profile (no annotations) and clear usage boundaries. It does not mention prerequisites, idempotency, or relationships to other session tools, leaving it incomplete for an agent deciding whether to invoke 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 schema provides no description for sessionId, and the tool description only repeats the parameter name ('by sessionId') without explaining its origin or format. It does not compensate for the 0% schema coverage by linking the sessionId to outputs of create_session or list_sessions.

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 ('Close') and resource ('browser session') and explicitly identifies the input parameter ('by sessionId'). This clearly distinguishes it from sibling tools like create_session, get_session, and list_sessions.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any warnings about side effects such as invalidating the session for resume_session. The only contextual clue is 'by sessionId', which implies it should be used when you have a specific session ID, but this is 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, the description carries the full burden. It discloses only that a session is created and that authContextId can load saved login state. It does not mention session lifecycle, resource cleanup, or any side effects, leaving behavioral transparency weak.

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 a concise note on optional parameters. No wasted words.

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

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

For a create tool with no annotations, the description covers the core purpose and optional parameters but lacks richer context about session management and integration with sibling tools. The output schema likely provides return details, so this is acceptable but not fully complete.

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

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

The description explains startUrl and authContextId, adding meaning beyond the bare schema. It does not explain headless or browserType, but these are relatively self-evident from their names and defaults. Schema coverage is 0%, so this partial compensation warrants a middle 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 creates a new browser session, using a specific verb and resource. It distinguishes from siblings like get_session, list_sessions, and close_session by focusing on the creation action.

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

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

The description implies it is used when a new browser session is needed and mentions optional startUrl/authContextId for loading saved login state. However, it does not explicitly contrast with alternatives like load_auth_context or explain when to use this vs existing session 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?

The description discloses that deletion also removes the storage state file, which is useful behavioral context beyond the title. However, it does not state whether deletion is permanent or affects active sessions, and with no annotations available, the description carries the full burden without fully addressing these aspects.

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

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

The description is a single sentence of 11 words, front-loaded with the verb and object. Every word earns its place, 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 single-parameter delete operation, the description covers the core action and an important side effect (deleting the storage state file). The presence of an output schema covers return values. However, given the destructive nature and lack of annotations, a brief note on irreversibility or impact on existing sessions would make it more complete.

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

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

The input schema provides only 'authContextId' with no description, and schema description coverage is 0%. The tool description does not mention the parameter or explain how to obtain or use the authContextId, so it adds no meaning beyond the field name.

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 'Delete' and clearly identifies the resource as a 'saved auth context' and its 'storage state file'. This distinguishes it from sibling tools like save_auth_context, load_auth_context, and list_auth_contexts.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, situations where deletion is appropriate, or when to prefer other auth context 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 provided, the description fails to disclose behavioral details such as how the file is saved (local path vs. download), whether it overwrites existing files, or the nature of the return value. The only added context is 'latest,' which is minimal. This is a significant gap for an export 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?

A single, grammatically complete sentence communicates the core function with no filler or redundancy. Perfectly concise.

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

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

The description is inadequate for a tool that triggers a file export. It does not address file destination, overwrite behavior, response format, or error conditions. The presence of an output schema is not leveraged in the description, and the minimal wording leaves the agent without sufficient 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 coverage is 0%, and the description only restates the source options ('table/form/text') without explaining format implications, file naming, or how 'latest' is determined. The enums are self-explanatory, but the description does not compensate for the lack of schema documentation in prose.

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 'Export' as a specific verb and identifies the resource as 'latest table/form/text extraction,' clearly distinguishing it from extraction tools like extract_table or extract_text. It states the action and target unambiguously.

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

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

The description establishes clear usage context: it exports the most recent extraction result to a file. While it does not explicitly mention alternatives, none of the sibling tools perform export functionality, so the intended use is clear. It lacks explicit when-not or prerequisite guidance, but the context is sufficient 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, but it only repeats the purpose. It does not mention whether selector limits to a single form, how hidden/readonly fields are treated, whether page must be loaded, or what happens when no form is found.

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

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

The description is a single, front-loaded sentence with no wasted words, but it is under-specified relative to the tool's complexity. It earns its place for stating purpose, but fails to convey necessary nuance.

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 minimal for a tool with two parameters, no annotations, and no output schema. It does not explain selector behavior, return format, error conditions, or practical use cases, leaving significant gaps for an agent to safely invoke 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?

Schema description coverage is 0%, and the description adds no meaning to the parameters. The optional 'selector' parameter is not explained, leaving its role and expected format entirely unspecified even though the tool's behavior likely depends on it.

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

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

The description clearly states the tool extracts form field schema from the page, using a specific verb ('Extract') and resource ('form field schema'). This distinguishes it from sibling tools like extract_text, extract_table, and get_interactive_elements.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any exclusions or preconditions. The description does not explain what to do with the extracted schema or how it relates to fill/select_option tools.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention return format, how pageLimit affects extraction, the outputFormat options, the need for a valid sessionId, or behavior when no table exists. The one-sentence description provides minimal behavioral insight.

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

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

The description is a single sentence that is concise and front-loaded with the action. It avoids fluff and is easy to parse. However, its terseness sacrifices useful context; still, as a concise statement it earns a reasonable score.

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 four parameters, an output format enum, and no annotations or output schema, the description is severely incomplete. It provides no information about return values, parameter usage, or prerequisites, making it insufficient for an agent to invoke the tool correctly in most scenarios.

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 lists four parameters with zero description coverage, and the tool description adds no parameter semantics. selector, pageLimit, sessionId, and outputFormat are entirely unexplained, leaving the agent to guess at their meaning. The description should compensate for the schema gap but does not.

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

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

The description clearly states the tool extracts table data from the page, using a specific verb and resource. It distinguishes itself from sibling tools like extract_text and extract_form by focusing on tables, though it could specify the type of table (e.g., HTML table) for complete 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?

Usage is implied: an agent would use this when needing table data from a page. However, there is no explicit guidance on when to prefer this over extract_text or extract_form, nor any mention of prerequisites like an active session. The context is thin but not misleading.

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 behavioral disclosure. It adds the important qualifier 'visible', indicating that only rendered text is extracted, not hidden or raw HTML. However, it does not address behavior for missing selectors, empty results, or whether the operation is purely read-only, leaving some gaps.

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

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

The description is a single, tightly worded sentence that front-loads the action and target. 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 simple extraction tool with an output schema available, the description adequately covers the core functionality and scope. It does not explain error handling or edge cases, but the presence of an output schema handles return format, and the tool's simplicity keeps the description sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the two modes ('page' or 'selector') and implies the selector parameter is for the selector mode. Yet it does not specify selector syntax or the exact relationship between mode and selector, so parameter semantics are only partially clarified.

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 'Extract' and identifies the resource as 'visible text', with clear scope of 'page or selector'. This distinguishes it from sibling tools like extract_table and extract_form, which target different content types.

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

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

The description clearly indicates when to use the tool: to get visible text from either the entire page or a specific selector. This provides clear context without explicit exclusions or alternative tool references, but the intent is unambiguous.

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 adds one useful trait ('Value is not logged') but omits important details about side effects (e.g., replacing existing text), return value, error behavior, and whether it waits for element visibility.

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

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

The description is extremely concise: two sentences with zero redundancy. The first sentence states the action, and the second adds a valuable privacy note. Every word earns its place.

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

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

Given the tool has 4 parameters, no annotations, no output schema, and 25+ siblings, the description is insufficiently complete. It lacks guidance on return values, failure modes, timeout behavior, and parameter semantics, leaving the agent to infer too much from the schema alone.

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

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

Schema coverage is 0%, so the description must compensate for parameter documentation. It implicitly references 'selector' and 'value', but does not explain sessionId or timeoutMs, nor does it define the expected format for selector or value. Only partial compensation.

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 'Fill' and the resource 'an input' with the method 'by selector'. It is specific enough to distinguish from siblings like click or select_option, though it could explicitly mention form fields or text inputs.

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

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

The description provides no guidance on when to use this tool versus alternatives like select_option or extract_form. There is no mention of prerequisites, exclusions, or typical use cases.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention prerequisites (e.g., a prior extraction must exist), error behavior, or the read-only nature of the operation. This is a significant gap for a tool with no annotation support.

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 front-loads the action verb and resource. It contains no redundant words and is appropriately concise for a simple utility 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?

The tool has a simple structure with two enum parameters and an existing output schema, so a minimal description might suffice. However, it lacks any mention of prerequisites, session context, or error handling. Given the absent annotations, the description is barely adequate.

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

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

Schema description coverage is 0%, so the description must compensate. It does mention both parameter concepts ('TypeScript/Zod/JSON' corresponding to format and 'table or form extraction' corresponding to source), but it does not explain deeper semantics like what 'latest' means or differences between formats. This is partial compensation.

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 'generate' with a clear resource ('TypeScript/Zod/JSON schema') and source ('latest table or form extraction'). This distinguishes it from sibling tools like generate_playwright_script and generate_page_object, which generate different 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?

Usage is implied by referencing 'latest table or form extraction,' suggesting the tool is used after an extraction. However, there is no explicit guidance on when to choose this tool over alternatives like export_extraction_result or generate_playwright_script, nor any exclusions.

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

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

No annotations are present, and the description does not disclose side effects, whether it modifies the browser state, or the nature of the generated class beyond a name. 'From current page' implies reading but lacks explicit behavioral details.

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

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

A single, front-loaded sentence with no unnecessary words. It is appropriately concise for a tool with one parameter.

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?

Even with an output schema, the description lacks usage context, parameter semantics, and behavioral disclosure. As a result, the agent has insufficient information to confidently select and correctly invoke this 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 only parameter, sessionId, has no schema description, and the description does not mention it. With 0% schema coverage, the description should compensate but does not, leaving the parameter's role implicit.

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 'Generate' and identifies the resource 'page object class' from 'current page', clearly distinguishing it from sibling tools like generate_playwright_script and generate_data_schema.

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

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

No guidance is provided on when to use this tool versus alternatives, prerequisites, or typical scenarios. The description only states what it does, not when to choose it over siblings.

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

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

With no annotations, the description must disclose behavior. It adds minimal context by saying 'from current session', but it does not explain what the script contains, how the session is used, whether there are side effects, or any limitations. The tool's behavior remains largely opaque.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It is concise and immediately communicates the core function.

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

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

While an output schema exists, the description is too sparse for a generation tool with complex behavior. It does not explain the generation logic, the role of the session, or the differences between target options. Given no annotations and minimal detail, the description is insufficient for an agent to fully understand the tool's capabilities and limitations.

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%, and the description does not mention either parameter. The 'target' parameter's enum values (login_flow, current_page, extraction_flow) are completely unexplained, and 'sessionId' is only implied by 'current session'. The description adds no semantic value beyond the raw schema.

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

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

The description clearly states the verb 'Generate' and resource 'Playwright test script', with the source 'current session'. It distinguishes itself from sibling generation tools like generate_page_object and generate_data_schema by naming the specific output type.

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

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

No guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites, context (e.g., after navigating), or exclusions. The single sentence simply states what it does without any 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?

With no annotations provided, the description carries the full burden of disclosing behavior. 'Check' implies a read-only operation, but the description does not clarify possible side effects, error behavior for invalid sessions, or how this relates to pause/resume states. It is minimally adequate but lacks depth.

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

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

The description is a single sentence of eight words, immediately stating the purpose. There is no redundant wording, and the structure is optimally front-loaded.

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

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

For a simple one-parameter query tool with an output schema, the description is reasonably complete. However, it omits any behavioral nuances such as what constitutes 'waiting for human action' (e.g., pending dialog, paused session) or how the returned state should be interpreted. The presence of an output schema mitigates some gaps, but the description alone is minimally sufficient.

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

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

The input schema has one required parameter, sessionId, with 0% description coverage. The description does not add any meaning beyond the schema, such as expected format (e.g., UUID), where to obtain the session ID, or how it is used. Although the parameter name is self-explanatory, the description fails to compensate for the lack of schema documentation.

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 'Check if a session is waiting for human action' clearly states a specific action (check) and resource (session's human wait state). It distinguishes itself from siblings like get_session, pause_for_human, and resume_session by focusing specifically on the wait-state query.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_session or pause_for_human. It does not mention common workflows, prerequisites, or exclusions, leaving the agent to infer usage context purely from the name.

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 only says 'summary' without specifying whether it returns visible elements, disabled elements, counts, or full details. It does not mention if it waits for page load, whether it scrolls, or if it includes hidden elements. This is a significant gap for a tool that could be used to decide subsequent actions.

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

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

The description is a single sentence, front-loaded with the core action, and lists example element types. Every word earns its place; there is no redundant or filler content.

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?

This is a simple read-only tool with one parameter and an output schema, so the description does not need to explain return values. However, it lacks guidance on when to use it versus snapshot or other extraction tools, and the vagueness of 'summary' leaves room for misinterpretation. For such a basic tool, the description is sufficient 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?

The only parameter is sessionId, which is self-explanatory and required. The description does not add any detail about it, and schema coverage is 0%. However, since sessionId is a standard identifier across sibling tools and the schema provides type and required status, the parameter is unlikely to confuse an agent. The description could have mentioned that the session must be active, but this is more of a usage guideline.

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 summary of interactive elements (buttons, links, inputs) on the page.' It uses a specific verb ('get'), identifies the resource ('interactive elements'), and enumerates element types. This distinguishes it from sibling tools like snapshot or extract_text, though it does not explicitly name a differentiating sibling.

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

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

The description implies usage when interactive elements are needed, but it does not explicitly state when to prefer this over alternatives like snapshot or extract_form. There are no exclusions or contextual hints about prerequisites (e.g., active session). The provided context is minimal but not misleading.

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. The description only says 'Get metadata' without specifying what metadata is returned, whether the session must be active, error behavior for invalid sessionIds, or whether the operation is read-only. This is minimal disclosure for an operation with no output schema.

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

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

The description is a single, front-loaded sentence that directly states the tool's purpose with no filler. It is appropriately concise for a simple get operation.

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

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

Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'metadata' means (e.g., fields like browser version, session status), the return format, or error handling for invalid session IDs. For a tool with one parameter and no output schema, more context is needed to ensure correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the parameter semantics. However, it merely restates 'by sessionId' without adding meaning about the expected format, how to obtain a sessionId, or any constraints beyond what the schema already shows (type: string, required). The description adds no value beyond the schema.

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

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

The description clearly states the action (Get metadata) and the resource (browser session) with a specific parameter (sessionId). It distinguishes from sibling tools like list_sessions (which lists all sessions) and create_session/close_session by focusing on retrieving metadata for a single session.

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

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

The description implies usage when you have a sessionId and need metadata, but it does not explicitly state when to use this tool versus alternatives like list_sessions or how to obtain a sessionId. There is no exclusion guidance or alternative tool reference.

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

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

No annotations are provided, so the description carries the full burden. It mentions the tool affects the 'next native dialog,' implying a one-time effect, but it does not explain what 'handled' means (e.g., auto-accept or dismiss), whether the setting persists, or what happens if no dialog appears. This lack of behavioral disclosure is a gap.

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

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

The description is a single, tightly worded sentence: 'Set how the next native dialog (alert/confirm/prompt) will be handled. Call before the action that triggers the dialog.' It communicates the core purpose and timing without extra 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 tool is stateful and requires understanding of parameter semantics and side effects. While the description gives a key usage hint and there is an output schema, it omits details about how `accept` and `promptText` behave, and whether the handler is invoked for only one dialog or persists. This makes the description incomplete for reliable use.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It does not define `accept` (boolean), `promptText`, or the role of `sessionId`, relying on the parameter names for inference. This is insufficient for an agent to set parameters correctly, especially since `promptText` is only relevant to prompt dialogs.

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: 'Set how the next native dialog (alert/confirm/prompt) will be handled.' It uses a specific verb and resource, and it stands out from sibling tools which focus on navigation, clicks, and sessions rather than dialog handling.

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 timing guidance: 'Call before the action that triggers the dialog.' This clarifies when to use the tool in the workflow. It does not discuss alternatives, but no sibling tool addresses dialogs, so the guidance is sufficient.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention any constraints like requiring at least one saved context. It is minimally transparent but not misleading.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates exactly what the tool does, making every word earn its place.

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

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

For a zero-parameter list tool with an output schema defined, the description is sufficient. It fully specifies the tool's operation without needing to detail return values (covered by the output schema) or parameters (none). The tool's simplicity and the presence of sibling tools that share the 'auth context' resource make the context complete.

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

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

The tool has zero parameters, so the input schema is trivially complete with 100% coverage. The description does not need to explain parameters, and the baseline score of 4 is appropriate for this case.

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

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

The description clearly states the action ('List') and the resource ('saved auth contexts'), with an explicit scope ('all'). This distinguishes it from sibling tools like save_auth_context, load_auth_context, and delete_auth_context, making the tool's purpose immediately evident.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of typical use cases, prerequisites, or relationships with save/load/delete_auth_context operations. A user would have to infer usage from the tool name alone.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It accurately indicates a read-only listing operation and qualifies sessions as 'active', but does not explain what defines an active session, whether closed sessions are excluded, or any other behavioral nuances. The description is not misleading, but it is 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?

A single, clear sentence that front-loads the action and scope. There is no wasted text, and the description is appropriately sized for a simple list operation.

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

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

For a parameterless tool with an output schema, the description sufficiently states the tool's purpose and scope. The term 'active' introduces slight ambiguity, but given the tool's low complexity, the description is otherwise complete.

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

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

The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies because no parameters exist and the schema confirms an empty object.

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 action ('List') and resource ('all active browser sessions'), and the word 'all' differentiates it from sibling tools like get_session. It is specific and directly matches the tool name.

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 by specifying 'all active browser sessions', which implies use when a full list is needed rather than a single session. However, it does not explicitly mention alternatives like get_session or state when not to use this tool.

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 behavior. It implies a mutation to the current session's auth state but does not explain effects (e.g., whether it replaces or merges existing auth), failure modes, or prerequisites. This is a significant gap for a tool that loads saved data.

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

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

The description is a single, concise sentence with no redundant words. It is front-loaded and clearly communicates the core action without wasted effort.

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 two required parameters, no annotations, and an output schema (whose contents are unknown), the description is severely incomplete. It lacks usage context, behavioral details, parameter explanations, and any mention of prerequisites or side effects. For a tool that modifies session state, this is inadequate.

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 provides minimal mapping: 'saved auth context' → authContextId and 'current session' → sessionId, but it does not clarify parameter formats, allowed values, or how the two relate. This adds only marginal value beyond the raw 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 uses a specific verb ('load') and resource ('auth context') with a clear target ('current session'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools like save_auth_context, list_auth_contexts, and delete_auth_context through the 'load' action.

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

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

The description gives no guidance on when to use this tool versus alternatives, no prerequisites (e.g., existing session or saved auth context), and no exclusions. It merely states what the tool does without any contextual 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 full responsibility for disclosing behavior. It does not mention side effects (e.g., clearing current page state), timeout behavior, or what happens if the URL is malformed. The one-sentence description adds little beyond the tool name.

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, very concise and free of fluff. It communicates the essential purpose without redundancy. However, it is under-specified, which slightly reduces the value of its conciseness—it's compact but not information-rich.

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

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

Given the absence of annotations and an output schema, the description should explain more about the tool's context. It does not address what happens after navigation (e.g., whether it waits for the page to load, whether it returns a status), making it incomplete for an agent to fully understand the tool's behavior.

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

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

Schema coverage is 0%, so the description must explain parameters. It implicitly clarifies 'url' as the destination but does not explain 'sessionId' (which session to navigate) or 'timeoutMs' (how long to wait). The description adds minimal meaning beyond the schema's parameter names.

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: 'Navigate the browser session to a URL.' This identifies a specific verb and resource, distinguishing it from sibling tools like click or fill. However, it lacks detail about what 'navigate' entails (e.g., page load behavior), so it's clear but not deeply descriptive.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that navigation is typically the first step before interacting with elements, nor does it reference other tools like wait or snapshot. There are no explicit 'when to use' or 'when not to use' instructions.

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

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

With no annotations, the description carries full burden. It discloses that the session is paused and waits for human, but omits details like potential timeouts, how the pause is reflected, or that it can be resumed. The core behavior is clear, yet lacks depth for an agent to fully anticipate side effects.

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

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

The description is a single, front-loaded sentence that conveys the action and purpose with zero wasted words. It is 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?

The tool is simple, but with 3 required parameters and no parameter descriptions in the schema, the description is somewhat incomplete. It does not explain the workflow (e.g., that get_human_wait_state can check status or resume_session can continue), leaving gaps in contextual guidance.

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 should compensate. It does hint at the 'reason' parameter via examples (LOGIN_REQUIRED, MFA_REQUIRED, CAPTCHA_REQUIRED), but it does not explain 'sessionId' or 'instructions' (e.g., that instructions are the message shown to the human).

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: 'Pause the session and wait for human' with concrete examples (login, MFA, captcha). It uses a specific verb and resource, distinguishing it from sibling tools like resume_session and wait.

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 examples of login/MFA/captcha strongly imply when to use this tool—whenever human intervention is required. However, it does not explicitly mention alternatives or when not to use, such as comparing to browser.wait or automatic handling.

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 only states when to resume, but does not disclose what 'resume' entails (e.g., side effects, failure modes, whether it validates the session state, or what happens if the session is not paused). This is a significant gap.

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

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

The description is a single, front-loaded sentence stating the action, resource, and trigger condition. Every word earns its place with no redundancy.

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

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

The tool is simple with one parameter and an output schema, which helps. However, the description does not explain the sessionId parameter or provide any error-handling or prerequisite details beyond the human action. It is adequate but leaves gaps that the schema and annotations do not fill.

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

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

The single parameter sessionId has no schema description, and the description does not explain it. The phrase 'a session' implies the sessionId refers to the session to resume, but the description adds no explicit meaning beyond the schema's type and name.

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 'Resume' and the resource 'a session', with the specific condition 'after human has completed the required action'. This distinguishes it from sibling tools like pause_for_human and get_session.

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: after a human has completed a required action, likely following a pause_for_human call. It does not explicitly name alternatives or exclusions, but the context is clear enough.

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 disclosure. It mentions saving storage state ('cookies etc.') but does not disclose whether existing named contexts are overwritten, what permissions are required, whether session storage includes all browser storage types, or any side effects. As a write operation, this lack of detail is a significant gap.

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

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

The description is a single sentence that is front-loaded with the action ('Save') and resource ('current session storage state'). Every word contributes to the meaning without unnecessary detail or repetition. This is appropriately concise.

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

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

The tool has 4 parameters, no output schema, and no annotations. The description only provides high-level purpose and leaves the meanings of domain and environment undefined. It also omits behavior around overwriting or naming collisions. This is insufficient for an agent to confidently invoke the tool correctly in all 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 description coverage is 0%, so the description must compensate. It only implies the meaning of sessionId (current session) and name (named context), but gives no explanation for domain or environment. These parameters remain ambiguous, and the description does not mention the domain scope or when environment should be specified.

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 saves the current session's storage state (cookies etc.) as a named auth context for reuse. It uses a specific verb ('save') and resource ('session storage state'), and the phrase 'for reuse' distinguishes it from sibling tools like load_auth_context, list_auth_contexts, and delete_auth_context.

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

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

The description implies when to use this tool: after establishing a session you want to persist for later reuse. It does not explicitly name alternatives or exclusions, but the contrast with load_auth_context and the 'for reuse' phrase provide clear context. No explicit 'use instead' guidance, so it doesn't earn a 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain side effects, precedence among x/y/selector/scrollIntoView, or whether scrolling is instant or smooth. This is a significant transparency gap for a tool with no annotations.

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 one sentence, concise, and front-loaded with the verb. It avoids unnecessary words, though it sacrifices essential detail. It is appropriately sized for a simple scroll action but under-specified for the schema.

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

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

With 5 parameters, 0% schema coverage, no annotations, and no output schema, the description must compensate heavily. It does not explain parameter semantics, return values, or usage context. This is far below the minimum viable for a tool with this complexity.

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

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

Schema description coverage is 0%, and the description does not mention any parameter. The phrase 'page or element' vaguely maps to x/y for page and selector for element, but scrollIntoView and sessionId are entirely unexplained. The agent cannot infer how to set the parameters correctly.

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 scrolls a page or element into view, using a specific verb and resource. It distinguishes this from navigation and clicking, though it does not explicitly reference sibling tools. The ambiguity about what 'page' means (top/bottom, coordinates) is minor.

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

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

No guidance is given on when to use this tool versus alternatives like click or navigate. It does not mention prerequisites (e.g., session), scenarios (e.g., after locating an element), or exclusions. The agent is left without context for invoking this tool 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 full burden of behavioral disclosure. It fails to mention any behavioral traits such as whether it selects multiple options, how it handles missing values, or if it waits for the element to be ready. The description provides no extra context beyond the basic action.

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

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

The description is a single sentence that is direct and free of fluff. It is appropriately sized for the tool's apparent simplicity, though this brevity comes at the cost of detail addressed in other dimensions.

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

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

Given the lack of annotations, absence of output schema, and 4 parameters, the description is too sparse. It fails to explain how the tool operates in context, such as whether it requires a page to be loaded, how values are matched, or what happens on failure. The description is not complete enough for an agent to use the tool reliably.

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 must compensate. The phrase 'option(s)' hints that the 'values' parameter accepts one or more options, which adds some meaning. However, it does not explain the 'selector' or 'sessionId' parameters, leaving most of the parameter semantics unexplained.

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: 'Select option(s) in a select element.' It uses a specific verb ('select') and resource ('select element'), which distinguishes it from sibling tools like click or fill. This is a precise and unambiguous definition.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The description simply states what the tool does without explaining scenarios where it is the appropriate choice over other browser actions.

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?

Annotations are absent, and the description only states the action without disclosing any behavioral traits. It does not say whether the tool is read-only, what fields the snapshot contains, or how detailLevel affects the output, leaving the agent to infer basic behavior.

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

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

The description is a single concise sentence that front-loads the key action and resource. Every word adds value, and there is no unnecessary 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 no annotations or output schema, the description carries the full burden but provides minimal context. It does not explain the structure of the snapshot, the impact of detailLevel, or what the agent should expect in the response, making it incomplete for a tool with an adjustable parameter.

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%, and the description does not explain the purpose of sessionId or detailLevel. While the enum for detailLevel provides some hints, the description adds no extra meaning to the parameters.

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

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

The description uses a specific verb 'Get' and resource 'structured snapshot of the current page' which clearly states the tool's function. It distinguishes from sibling extraction tools by emphasizing 'structured' and 'LLM consumption', signaling a comprehensive page representation rather than targeted extraction.

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

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

No guidance is provided on when to use this tool versus alternatives like extract_text or get_interactive_elements. There is no mention of preferred scenarios, prerequisites, or exclusions.

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

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

With no annotations provided, the description must carry the burden of disclosing behavioral details. It only states the action without revealing whether it captures the viewport or full page, whether it saves to the 'path' parameter or returns image data, or whether it blocks until the page is stable. The description adds no behavioral context beyond the bare operation.

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

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

The description is a single short sentence, which is structurally concise and front-loaded. However, it is so sparse that it borders on under-specification, lacking any detail that would aid the agent. It earns a middle score for being appropriately brief but not sufficiently informative.

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

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

This is a simple tool, but the description omits crucial context such as the need for an existing session (implied by the required sessionId), the behavior of the optional path parameter, and the nature of the output (there is an output schema, but the description doesn't mention how the screenshot is delivered). The description is incomplete for an agent to safely invoke the tool without additional information.

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

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

The input schema has two parameters (sessionId, path) with 0% schema coverage (no descriptions in the schema). The tool description does not mention either parameter, leaving the agent without any semantic understanding of 'path' (e.g., is it a file path to save the screenshot?) or how 'sessionId' relates to the current page. The description fails to compensate for the missing 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 action ('Take a screenshot') and the resource ('current page'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like browser.snapshot by specifying a screenshot (visual capture) rather than a DOM snapshot or text extraction.

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

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

No guidance is provided regarding when to use this tool versus alternatives. There is no mention of prerequisites (e.g., active page, loaded session) or exclusions, leaving the agent to infer usage from context alone.

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

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

No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states the waiting action without revealing side effects, blocking behavior, session requirements, or return values. This is nearly tautological and provides no meaningful 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 a single, concise sentence that directly states the action. It is not bloated or verbose, though it is underinformative. It earns a high score for conciseness due to its brevity, but it could be more structured with additional context.

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

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

Given the absence of annotations, no output schema, and two required parameters, the description is too sparse to be complete. It lacks information about return behavior, whether the wait blocks the session, and how this wait relates to other browser operations. The tool is simple, but the description still leaves significant gaps.

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

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

The schema has no descriptions for the two parameters, and the description adds minimal value by implying that timeoutMs is the number of milliseconds to wait. It does not explain sessionId at all, and with 0% schema coverage, the description should compensate more for the lack of parameter documentation.

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 'Wait for a number of milliseconds' clearly states the action and the unit of time, making the core purpose understandable. However, it does not differentiate this tool from sibling tools like browser.pause_for_human, which may also involve waiting, so it lacks sibling distinction.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or situations where this wait is preferred over other waiting mechanisms, leaving the agent without decision support.

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