WebRun Browser Automation

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

Annotations identify the tool as destructive and open-world, but the description adds substantial concrete context: it may navigate, fill forms, and submit data on third-party websites. It also explains the session lifecycle (creates, runs, auto-terminates), giving agents a clear picture of external side effects beyond the annotation flags.

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 four concise sentences with no filler. It front-loads the action, then covers lifecycle, use case, and side-effect warnings in a logical order; every sentence earns its place.

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

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

For a complex tool with 15 parameters and a comprehensive schema, the description covers the core execution model and the main safety warning (may submit data on third-party sites). It doesn't enumerate advanced options like proxy, output schema, or webhooks, but those are fully documented in the schema, and the high-level context is sufficient for tool selection.

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 all 15 parameters, so the schema already provides rich parameter-level semantics. The description itself adds no parameter-specific meaning, leaving the baseline at 3 as appropriate.

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

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

The description clearly states it executes a browser automation task in a real Chrome browser running in a WebRun cloud environment, giving a specific verb and resource. It also distinguishes itself from sibling tools by noting that it creates a session, runs the task, and auto-terminates, positioning it as a one-off task runner.

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 says 'Best for simple one-off tasks,' which provides clear context on when to use this tool. However, it does not name alternatives or offer explicit when-not-to-use 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?

The description complements the annotations by adding behavioral context: it creates a persistent session, runs in a real Chrome browser, and may act on third-party websites immediately with an initial task. It avoids contradicting the annotations and adds meaningful context about side effects, though it does not detail cleanup or termination 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 three sentences, front-loaded with the core action, and every sentence adds value: purpose, environment, return value, and an important side-effect warning. 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?

Given the high complexity (9 parameters, nested objects) but complete schema coverage and existing output schema, the description provides the essential high-level context: session persistence, multi-step workflow utility, return of sessionId, and the potential for immediate external actions. This is sufficient for an agent to select and begin using 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?

With 100% schema description coverage, the baseline is 3. The description adds extra meaning to the task parameter by warning that an initial task may trigger immediate actions on third-party websites, which goes beyond the schema's simple field 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 uses a specific verb and resource: "Create a persistent session in a real Chrome browser running in a WebRun cloud environment." It clearly states the return value (sessionId) and distinguishes the tool's role from sibling tools like browser_task or send_task by emphasizing session creation for multi-step workflows.

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 for when to use the tool: "for multi-step workflows" and "Returns a sessionId for subsequent commands." It implies this is the entry point for a session-based workflow, though it does not explicitly mention alternatives 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?

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'Read-only: reports on the task without affecting it'. It adds unique behavioral context about polling for completion and detecting guardrails, going beyond the annotations. No contradictions 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 two sentences, with the main action front-loaded and every word earning its place. It is concise yet informative, avoiding any 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, has an output schema (so return values need not be explained), and the description covers purpose, usage, and non-mutating nature. It is complete for a read-only status check 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?

Schema description coverage is 100% for both parameters, so the description does not need to add much. It adds no extra parameter meaning beyond the schema, which is acceptable given the baseline of 3 for full schema coverage.

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

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

The description clearly states the tool checks the status of a task in a browser session, using a specific verb 'Check' and resource 'status of a task'. It distinguishes this from sibling action tools like stop_session_task or pause_session_task by focusing on observation rather than mutation.

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

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

It explicitly says 'Use to poll for completion or detect guardrails', providing a clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5 but is still strong 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?

The description adds context about the handoff to the live agent and the purpose of the response, but does not detail side effects beyond what annotations already indicate (destructiveHint=true). Given annotations already signal potential destructiveness, the description provides moderate additional context but lacks depth on consequences.

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 that front-load the tool's purpose and flow, with no redundant wording.

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

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

The description covers the core scenario and outcome, and the presence of an output schema reduces the need to explain return values. It does not explicitly address potential alternatives or prerequisites, but overall it provides sufficient context for a tool of 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?

The input schema already provides thorough descriptions for all four parameters (100% coverage), so the description adds no additional parameter-specific semantics. The description's mention of 'response' aligns with the schema but does not enrich the meaning beyond what is already documented.

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 'Respond' and the resource 'guardrail trigger', specifying the tool's role in providing human input to the browser agent. It distinguishes from sibling tools by referencing the guardrail/human-input context rather than task execution or session management.

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 identifies the trigger condition ('when the browser agent needs human input (credentials, clarification, approval)') and describes the flow ('response is handed to the live agent, which continues acting on it'). However, it does not mention alternative tools or exclusions, so it falls short of fully guiding selection.

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

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

The description states 'Read-only,' which aligns with and reinforces the annotations' readOnlyHint and idempotentHint. It adds useful context that the list is scoped 'for this account' and that the returned IDs are prerequisites for other tools, going slightly beyond the annotations without contradicting them.

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

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

The description is exceptionally concise: two sentences that front-load the main action and immediately state the value proposition and safety property. No unnecessary words 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?

For a zero-parameter, read-only list tool with an output schema, the description provides complete context: what is listed, the account scope, the relationship to downstream tools, and the read-only guarantee. No critical 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?

There are no parameters, so the schema provides full coverage. The description adds meaningful context about what is being listed ('persistent profiles') and the purpose of the returned IDs, which helps the agent understand the semantic domain even without parameters.

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

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

The description clearly states the tool's function with a specific verb ('List') and resource ('browser environments (persistent profiles)'), and it specifies the account scope. It also distinguishes itself from sibling tools by explicitly connecting its output to browser_task and create_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 provides clear context for when to use the tool: it returns environment IDs needed for persistent sessions in browser_task or create_session. However, it does not explicitly mention when not to use it or name alternatives, stopping short of full usage-exclusion 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?

Beyond the annotations, the description adds that only 'active' sessions are returned and scopes to 'this account'. It also repeats 'Read-only' which matches readOnlyHint, adding no contradiction but duplicating annotation info.

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, information-dense sentence that covers purpose, scope, and safety with no 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 simple with no params, and an output schema exists. The description fully covers the tool's purpose and scope; nothing more is needed 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, so the schema is fully covered. The description adds no parameter information, but none is needed; baseline 4 is appropriate for no-param tools.

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

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

The description uses a specific verb ('List') and identifies the exact resource ('active browser sessions') with scope ('for this account'). It clearly distinguishes this tool from siblings like list_environments and session lifecycle 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?

Clear context is provided: use this to list all active sessions. However, no explicit exclusions or alternatives are named, though the sibling tool names imply its role.

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 the task must be 'currently running' and that it can be 'resume[d] later', adding reversible-behavior context beyond the annotations' readOnly, idempotent, and destructive hints. It does not elaborate on side effects or failure modes, but the annotations already cover basic safety traits.

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

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

The description is two sentences, front-loaded with the action, and contains no filler words. 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?

This is a simple one-parameter tool with an output schema present (so no need to explain return values). The description covers the core behavior, the resume path, and the session scoping. It could mention permanent alternatives like stop/terminate, but given the sibling list, the context is reasonably complete.

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

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

The input schema provides 100% coverage for sessionId with a description ('Session ID'), so the baseline is 3. The tool description adds no extra meaning about the parameter or how to obtain it, but it is not required given the schema coverage.

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

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

The description clearly states the action ('Pause'), the resource ('task currently running in a browser session'), and differentiates from siblings by naming the complementary tool 'resume_session_task' for resuming later. This 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 says to resume later with resume_session_task, which implies when to use this tool and points to an alternative. It does not explicitly state when not to use it (e.g., for permanent stopping with stop_session_task), so it misses the full when/when-not guidance.

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

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

Annotations are provided (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true), so the safety profile is known. The description adds the precondition that the task must be previously paused, which is a meaningful constraint not in the annotations. However, it does not disclose other behavioral aspects like what happens on resume (e.g., continuation point, side effects) beyond the 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 a single concise sentence, front-loaded with the action. It contains no fluff or redundant information, earning its place with the key detail that the task is previously paused.

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

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

Given the tool's simplicity (one parameter, output schema exists), the description is reasonably complete. However, it lacks usage context and does not explain the implications of the destructiveHint annotation. The 'previously paused' precondition is helpful, but the description does not describe the lifecycle or relationship to sibling session tools, leaving some contextual gaps.

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

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

Schema coverage is 100% for the single parameter 'sessionId', which is described as 'Session ID'. The description does not add any additional meaning or format details beyond the schema. Baseline of 3 applies because the schema handles the parameter documentation adequately.

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 ('resume') and the resource ('previously paused task in a browser session'). It distinguishes this from siblings like pause_session_task, stop_session_task, and terminate_session by specifying that it acts on a paused task. The verb and resource are specific and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used after pause_session_task, nor does it exclude cases like already-running tasks. Without this context, an agent may not know the appropriate usage 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?

The description adds value beyond annotations by specifying the return format ('as an inline image'), which the schema does not explain. The 'Read-only' statement aligns with the readOnlyHint, and no contradictions 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?

Two sentences, front-loaded with the core action, and zero filler. Every word earns its place, and even the redundant 'Read-only' is short and reinforces the annotation.

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

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

The description is complete for a simple tool: it states the action, the context requirement, and the return format. With an output schema present, the tool doesn't need to spell out the full response structure. Minor details like full-page vs. viewport capture are not essential.

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 contextual meaning to sessionId by specifying it must be an active session, which goes beyond the simple 'Session ID' schema description.

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

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

The description states a specific action ('Capture a screenshot'), a specific resource ('current browser page'), and a condition ('in an active session'). This clearly distinguishes it from sibling tools like list_sessions or browser_task, which have different purposes.

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

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

The phrase 'in an active session' clearly indicates that a pre-existing, active session is required, implying a prerequisite of creating a session first. There are no competing screenshot tools, so no exclusions are needed, but it doesn't explicitly outline when not to use it.

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

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

Annotations already indicate openWorldHint=true and destructiveHint=true, but the description adds valuable specificity by stating that the real Chrome browser may navigate, fill forms, and submit data on third-party websites. This goes beyond the generic hints and informs the agent of concrete real-world 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 two sentences with no wasted words. The first sentence states the core action and prerequisite, and the second succinctly warns about real-world effects. It is appropriately concise and front-loaded.

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

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

Given the tool's complexity (8 parameters, output schema, nested objects), the description captures the essential workflow: send a task to a session and beware of real-world actions. The schema handles parameter details and the output schema covers return values, so the description is adequate, though it could mention asynchronous behavior or status tracking via get_task_status.

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 all parameters already have descriptions. The tool description does not add meaningful semantic detail beyond the schema, only reinforces that the task is sent to an existing session. This meets the baseline for full schema coverage without adding extra value.

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

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

The description clearly identifies the tool as 'Send a new task to an existing browser session', using a specific verb and resource. It references create_session to establish context, but does not explicitly differentiate from the sibling browser_task, so it loses a point for lacking direct sibling comparison.

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 'to an existing browser session (from create_session)' provides clear contextual prerequisites—namely that a session must already exist. However, it does not mention when to avoid this tool or compare it to alternatives like browser_task, stopping short of explicit 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?

Annotations already disclose destructiveHint and idempotentHint, lowering the burden on the description. The description adds valuable context beyond annotations by specifying that the session stays alive, which is a key behavioral trait differentiating it from more destructive operations.

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

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

The description is a single, concise sentence that immediately states the action and its outcome. No wasted words or 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?

Given the tool's simplicity, one parameter, strong annotations, and presence of an output schema, the description sufficiently covers what the tool does. It doesn't explain return values, but the output schema exists, so that's not required. Minor gap: no mention of behavior if no task is running, but overall 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 coverage is 100% with 'sessionId' documented as 'Session ID'. The description adds only the context that the session is a browser session, which is slightly more specific but not substantially beyond the schema. Baseline 3 is appropriate as the schema carries the 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 uses a specific verb ('Cancel') and clearly identifies the resource (the task running in a browser session). It distinguishes itself from sibling tools like pause_session_task and terminate_session by explicitly stating that the session is kept alive, making its purpose unambiguous.

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

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

The description provides a clear context for use (when you want to cancel the current task without ending the session). It implicitly contrasts with terminate_session by noting the session remains alive, but it does not explicitly list alternative tools 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?

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds meaningful context by stating the session and any running task cannot be resumed, and that resources are freed. This goes beyond the structured metadata and helps the agent understand the full impact of the 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 concise and front-loaded, using two sentences to state the action and its consequence. Every word earns its place, with no unnecessary detail or repetition of the title.

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, so the description covers the essential information: what it does and a critical behavioral caveat. It does not explain return values (unnecessary given the output schema) or prerequisites, but for this complexity level, it is sufficiently complete.

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

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

The input schema fully describes the only parameter (sessionId) with 100% coverage, so the description need not add more. The description does not elaborate on the parameter, but the schema is already clear, making the baseline 3 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 purpose with a specific verb ('End a browser session') and resource, and adds the key detail that it frees resources. It distinguishes itself from similar sibling tools like pause_session_task or stop_session_task by emphasizing the finality and non-resumability of the 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 (to end a session permanently) and even notes that the session cannot be resumed, which is a clear contextual hint. However, it does not explicitly mention alternatives or provide when-not-to-use guidance, leaving some ambiguity compared to sibling tools that might pause or stop tasks.

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