WebRun Browser Automation

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

The annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds valuable context beyond that: it 'Creates a session, runs the task, and auto-terminates' and warns that it 'may navigate, fill forms, and submit data on third-party websites as the task requires.' This paints a clear picture of side effects without contradicting 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 front-loaded with the core action and environment, followed by usage guidance and an explicit sibling exclusion. Each sentence earns its place, though the embedded docs link and parenthetical are slightly extraneous. It is compact enough for an agent to parse quickly.

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

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

For a tool with 15 parameters and nested objects, the description covers the essential selection criteria and behavioral expectations well. Since an output schema exists, return-value details are not required. A minor gap is that it doesn't mention the asynchronous nature (e.g., checking get_task_status or webhook notifications), but the schema and sibling tools partly compensate.

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

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

Schema description coverage is 100%, so the input schema already documents every parameter in detail. The description adds no parameter-specific semantics beyond clarifying the tool's general behavior, which is sufficient given the schema's thoroughness. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Execute a browser automation task in a real Chrome browser running in a WebRun cloud environment.' It clearly distinguishes itself from trigger_workflow by framing itself as 'Best for simple one-off tasks that no saved workflow covers,' so an agent can immediately tell which tool fits.

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 explicit when-to-use guidance ('Best for simple one-off tasks that no saved workflow covers') and explicit when-not-to-use instructions ('Do NOT use this to run or test a saved workflow — use trigger_workflow instead'). It even maps user phrases like 'run it' and 'test it' to the correct sibling tool, leaving no ambiguity.

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 substantial behavioral context beyond the annotations: it discloses that results and memory 'stay centralised on the workflow' in workflow mode, that the connection-bound environment 'is applied automatically,' that results are 'delivered to your connected chat and appear in session history,' and that variables are 'BAKED IN at deploy and reused every run.' The mutate/hint annotations (readOnlyHint=false) agree with the 'Create' action, so there is no contradiction. The only light gap is that it doesn't explicitly state idempotency/non-idempotency consequences, but the annotations carry that.

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 long but well-structured with clear section markers (WORKFLOW MODE / STANDALONE MODE) and front-loads the core purpose before the mode breakdown. Each sentence earns its place given the tool's genuine complexity (two modes, 11 parameters). It is not bloated — the length tracks the complexity, though it could be trimmed slightly by moving some prompt-authoring detail into the schema param 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 11 parameters, a nested schedule object, and an output schema that relieves the description of explaining returns, the description covers the mode logic, required-vs-optional parameters per mode, edge cases (variables only when {{variables}} exist, memory 'usually best left empty', environmentId omit), and agent interaction expectations. Nothing an agent needs to call it correctly is missing; one could argue for 5, but the very long prompt-format digression slightly dilutes the tool-level focus.

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, but the description goes beyond by clarifying mode-dependent semantics: 'name... Required standalone; defaults to the workflow title in workflow mode,' variables only apply 'when the workflow's prompt actually contains {{variables}},' and 'environmentId... OMIT it... never ask the user to choose.' The prompt field also gets a detailed runbook structure. This adds meaningful usage nuance that the schema alone doesn't convey.

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

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

The description opens with a concrete verb+resource: 'Create a scheduled agent — a recurring or one-time automation that runs on a timer in a real Chrome browser.' This clearly distinguishes it from siblings like create_workflow, trigger_workflow, and browser_task by foregrounding the timer/scheduled aspect, and it immediately breaks down the two modes (workflow vs standalone), leaving no ambiguity about what the tool does.

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

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

The description explicitly states when each mode applies: 'WORKFLOW MODE: pass workflowId plus a schedule' vs 'STANDALONE MODE: omit workflowId and provide name, prompt... and a schedule.' It also gives agent-level behavioral guidance on what to ask the user ('only what it should do and when it should run... never ask about environments or technical settings'). It names the source for workflow ids (list_workflows). While it doesn't explicitly say 'use X instead of this tool', the mode selection criteria fully cover the routing logic.

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 mark the tool as destructive and open-world, and the description adds important behavioral context: the browser may act on third-party websites immediately, the session is persistent, and it returns a sessionId for subsequent commands. This goes beyond the annotations by explaining what actually happens when an initial task is provided.

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 concise sentences with no filler. It front-loads the core purpose, then covers return value and side effects, and ends with the critical workflow-vs-session distinction. 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?

Given the complexity of the tool, the description covers the essential decision boundary (session vs workflow), the operational environment, the immediate external side-effect potential, and the return value. An output schema is present, so return structure does not need to be explained further.

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 every parameter has a rich description in the schema, so the baseline applies. The tool description does not add parameter-level meaning, but it does not need to because the schema already covers parameter semantics fully.

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 in a WebRun cloud environment, for multi-step interactive work. It also names the key sibling alternative (trigger_workflow), so an agent can distinguish a session from a workflow run.

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

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

The description explicitly states when to use the tool (multi-step interactive work) and gives a clear exclusion: do not use it for saved workflows; use trigger_workflow instead. It explains why, because a workflow run carries its own rules, tracking, and memory, making session runs behave differently.

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 only indicate non-read-only, non-destructive, non-idempotent. The description adds substantial behavioral context: schedule is stored as a setting only, not run until deployed via create_agent; the connection's environment is applied automatically; memoryContract wiring is platform-managed; variables are only used when explicitly requested. This goes beyond the sparse annotations and clarifies side effects and invocation semantics.

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 long but densely packed with essential guidance. It's front-loaded with the readiness bar and required fields, then flows logically through memoryContract, environment, variables, schedule, and testing. While it could be tightened, every sentence serves a purpose given the tool's complexity and 38 parameters; no filler or redundancy.

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

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

For a tool with 38 parameters and nuanced usage rules, the description covers all critical aspects: required fields, prompt construction, memoryContract requirements, environment handling, variable policy, schedule semantics, testing routing, and what to avoid. The output schema exists separately, so return values need not be explained. An agent has enough to call this correctly without external lookup.

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. However, the description adds crucial meaning for several parameters: it explains memoryContract's three fields and when it's required, clarifies environmentId should be omitted, prescribes the promptTemplate structure (Goal/Ground rules/Stages/Output contract), and distinguishes concrete values from {{variables}}. It also notes schedule only stores a setting. This is significant added 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?

States a specific verb and resource: 'Create a new saved workflow.' It differentiates from siblings by explicitly directing to trigger_workflow for testing and warning against browser_task or create_session. The description also clarifies what the workflow is not (not a timer until deployed).

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

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

Provides explicit when-to-use guidance: only when readiness bar is met, requires title and promptTemplate, and collects missing facts first. Clearly states when to use trigger_workflow instead, and instructs to omit environmentId and not ask the user to choose one. Also explains when memoryContract is required, distinguishing from defaults.

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 include readOnlyHint=true and idempotentHint=true, which the description reinforces with 'Read-only: reports on the task without affecting it.' The description adds behavioral nuance by mentioning 'poll for completion' and 'detect guardrails,' which are not in the annotations. It does not contradict the annotations and adds useful context beyond what structured fields provide.

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 filler. It front-loads the core purpose and then adds the primary use cases and read-only nature. Every sentence contributes value, and it is appropriately sized for a simple polling 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?

Given the presence of an output schema (which documents return values), the low complexity, and straightforward parameters, the description is complete. It covers the purpose, usage context, and read-only nature. An agent has everything needed to decide when to call this tool and what to expect.

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

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

The input schema covers 100% of the parameters with descriptions for both taskId and sessionId. The tool description does not add any parameter-specific details beyond the schema, so the baseline score of 3 applies. It neither enhances nor detracts from the schema's clarity.

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

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

The description states a specific verb ('Check'), a clear resource ('status of a task'), and adds context ('previously started in a browser session'). It also signals the two main uses (poll for completion, detect guardrails), which clearly distinguishes it from action-oriented siblings like pause_session_task or stop_session_task. The purpose is unmistakable.

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

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

The description explicitly states when to use the tool: 'Use to poll for completion or detect guardrails.' It does not explicitly name alternatives or say when not to use it, but given the sibling list, no other tool serves this status-checking function. The guidance is clear enough for an agent to select this tool over mutating 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 already declare readOnlyHint and idempotentHint. The description adds useful behavioral context by noting 'Read-only; proxy credentials are masked' and mentioning 'pending logins,' which go beyond the annotations. No contradictions present.

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, coherent sentence front-loaded with the tool's purpose, followed by a short identification note and a safety note. Each phrase adds value with no redundancy or 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 read-only tool with an output schema and good annotations, the description enumerates the key data fields and identification parameters. It lacks an explicit statement that at least one identifier is required, but this is implied by 'Identify by workflowId or exact title,' making it almost complete.

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

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

Schema descriptions already cover 100% of parameters, including that each is an alternative to the other. The description merely reinforces this with 'Identify by workflowId or exact title,' adding no new semantic detail beyond the schema, so baseline 3 is appropriate.

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

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

The description states the tool retrieves full detail of exactly one workflow, listing specific contents (prompt template, variables, trigger, settings, etc.). This clearly distinguishes it from sibling tools like list_workflows by focusing on a single workflow.

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

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

The description implies usage by providing identification methods ('Identify by workflowId or exact title') and lists what data is returned, giving clear context for when to use it. However, it does not explicitly compare to alternatives or state when not to use this tool, so it falls short of 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?

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 annotations already declare readOnlyHint and idempotentHint, and the description adds 'Read-only' to confirm. It also explains what data the tool returns (schedule, status, run times, deployment type) and the scope behavior, which goes beyond the s chema. 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 concise sentences, front-loading the primary function, then adding the key scope nuance and a read-only note. Every sentence contributes value with no redundancy.

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

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

For a simple read-only tool with one optional parameter and an output schema, the description covers all essential aspects: what is listed, what fields are returned, how scope works, and the safety profile. It is fully sufficient for an agent to select and invoke the tool correctly.

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

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

The schema provides a complete description of the scope parameter with 100% coverage. The description essentially restates the same scope information without adding new semantic details. Thus, baseline 3 is appropriate.

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

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

The description clearly states the tool lists the account's scheduled agents (cron deployments) and enumerates the exact information returned (schedule, status, next/last run, standalone/deployed from workflow). It distinguishes itself from sibling tools like list_workflows and list_environments by focusing on agents.

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 clarifies when to use this tool by explaining the scope parameter: it is scoped to the bound environment unless scope 'all' is passed. This gives clear context for how to invoke it, though it does not explicitly name alternative tools for different 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?

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces with 'Read-only'. It adds useful behavioral context about automatic environment usage for workflows/agents and the tool's role in returning environment IDs, going beyond what annotations convey.

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

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

Two sentences with front-loaded action and purpose; the note about workflows/agents is succinct and valuable.

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?

Output schema is present so return values are covered; no parameters; description provides sufficient usage context and alternatives. It fully addresses the tool's simplicity.

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

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

No parameters exist, so schema coverage is complete. Description does not need to explain parameters, and the baseline for zero-param tools is met.

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

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

Description uses specific verb 'List' with resource 'available browser environments' and clarifies it provides environment IDs for persistent sessions. It clearly distinguishes from sibling tools by noting workflows/agents use the connection's environment automatically.

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

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

Explicitly states when the tool is needed (persistent sessions via browser_task or create_session) and when it isn't (workflows/agents), including instruction not to ask users to choose an environment. This provides clear alternative guidance.

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

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

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?

Annotations already declare readOnlyHint and idempotentHint, and the description adds useful behavioral context: it documents what fields are included in the output (title, schedule, variables, run stats) and clarifies the environment-scoping behavior. It does not contradict the annotations; it reinforces 'Read-only' consistency.

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

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

Three short sentences deliver a complete description without unnecessary words. The tool's purpose, output content, and scope nuance are packed efficiently, and 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 simple list tool with one optional parameter and an existing output schema, the description covers the core purpose, the returned fields, the scope semantics, and its read-only nature. Nothing important is missing for the assumed complexity level.

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

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

The schema already fully documents the only parameter 'scope' with an enum and explanation (100% coverage). The description adds semantic nuance about the default behavior when a connection is bound to an environment, which enriches the schema description and helps the agent choose the correct value.

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

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

The description clearly states the verb 'List' and the resource 'the user's saved workflows', with an added definition of workflows as 'prompt-templated browser automations'. It further specifies what is shown (title, schedule, variables, run stats), which distinguishes it from sibling tools like get_workflow (single workflow) or trigger_workflow (execute/run).

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 on when to use the tool by explaining the environment scoping and the scope parameter values ('environment' default vs 'all'). It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for a simple read-only reporter.

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 convey destructiveHint and readOnlyHint, so the bar is lower. The description adds useful behavioral context: the agent stops firing until resumed, and the tool is for active agents. It could further disclose edge cases (e.g., already paused agents), but the added behavior description earns credit 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 two tight sentences, front-loaded with the core action, and every piece of information (pause, stops firing, resume, agentId source) earns its place. 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?

For a simple one-parameter tool with an output schema and clear annotations, the description covers the essentials: purpose, effect, and how to obtain the required ID. It doesn't describe error conditions (e.g., invalid or already-paused agents), but these are not critical for a standard pause operation and the output schema likely covers result details.

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% as the single parameter agentId is fully described in the schema, including its format and source. The description's note to 'Get agentId from list_agents' adds little beyond the schema, which already mentions list_agents. Baseline 3 is appropriate.

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

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

The description clearly states the action: 'Pause an active scheduled agent' with a specific verb and resource, and distinguishes it from siblings like resume_agent and pause_session_task by specifying 'scheduled agent' and the behavior 'stops firing until resumed.'

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

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

The description gives clear context (use on active scheduled agents) and even tells where to get the agentId from list_agents. It does not explicitly mention alternatives or exclusions, but the phrase 'until resumed' implicitly points to resume_agent as the complementary operation.

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?

Even though annotations already declare destructiveHint=true, the description adds valuable behavioral context: it recomputes next run, reactivates, restarts with a full pass for completed agents, and refuses if expiration has passed. This goes well beyond the structured annotations and helps the agent anticipate side effects and failure conditions.

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 primary action, and every sentence adds distinct information: main action, special-case behavior, and failure condition. No fluff or redundancy.

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

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

With a single parameter, an output schema, and clear behavioral descriptions covering normal, special-case, and refusal scenarios, the description is complete for the tool's complexity. The inclusion of the expiry edge case and fresh-pass behavior leaves no major 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 agentId, and the schema already provides a description ('24-hex agent id (from list_agents)'). The tool description does not add new parameter-level semantics, so the baseline score of 3 is appropriate.

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

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

The description names a specific verb ('Resume') and resource ('scheduled agent'), explains the core behavior ('recomputes its next run and reactivates it'), and distinguishes from sibling tools like resume_session_task by specifying 'scheduled agent' rather than session task. The additional detail about completed work-list agents further clarifies the specific use case.

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

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

The description clearly implies when to use the tool (for paused scheduled agents) and describes a special case (completed work-list agents). It also provides a precondition for use (expiry not passed) and a workaround ('extend it on the dashboard first'). However, it does not explicitly compare against alternatives like resume_session_task, though the 'scheduled agent' wording provides implicit differentiation.

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

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

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?

The annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, so the agent knows this is a side-effectful, open-world operation. The description adds valuable context: 'The real Chrome browser may navigate, fill forms, and submit data on third-party websites as the task requires.' This goes beyond the annotations by specifying actual behaviors, which helps the agent anticipate side effects. No contradiction.

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

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

The description is two sentences, front-loaded with the core purpose, followed by a contextual note about browser behavior. Every word earns its place; there is 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?

Given that the schema covers all parameters and an output schema exists to define return values, the description provides the essential context: the purpose and the real-browser behavior that may have side effects. It could mention prerequisites like needing a valid session ID from create_session, but that is implied and captured in the schema. The description is sufficiently complete for an agent to understand what the tool does and what to expect, though it could briefly mention state changes or error conditions.

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 all 12 parameters, each with descriptive text. The description itself does not add any additional meaning to the parameters beyond what the schema already states. Since the schema covers everything, the baseline of 3 is appropriate.

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

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

The description clearly states the tool sends a new task to an existing browser session, tying it to create_session. It specifies the verb 'send' and the resource 'task'. However, it does not explicitly differentiate from potentially similar tools like browser_task or create_workflow, relying on the context of 'existing session' to distinguish. This is clear but could be more explicit about its unique role among siblings.

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

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

The description gives clear context: use for existing sessions created via create_session. This implies a workflow where create_session precedes this tool. However, it does not provide any exclusions or mention when to use alternative tools, such as browser_task for direct browsing or create_workflow for multi-step tasks. The context is clear but not comprehensive.

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.

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

Beyond the annotations, the description discloses concrete real-world side effects: "Drives a real Chrome browser: the run may navigate, fill forms, and submit data on third-party websites." It also clarifies that the run carries workflow rules, tracking, and memory, adding meaningful behavioral context that annotations alone do not provide.

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 front-loaded with the core purpose, then layers usage guidance, behavioral disclosure, parameter direction, and return-value handling in a logical order. All sentences earn their place; there is no filler.

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

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

For a tool with a destructiveHint and openWorldHint, the description covers purpose, when to use it, what happens during execution, how to pass variables, and how to obtain results. Nothing essential is missing when combined with the rich schema.

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

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

Schema description coverage is 100%, so the input schema already documents all four parameters in detail. The description mostly repeats the variables semantics already present in the schema, adding no significant new parameter-level information beyond emphasizing variable defaults.

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

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

Description clearly states a specific verb and resource: "Run a workflow now in its deployed environment." It explicitly distinguishes itself from browser_task/create_session as the only correct way to run or test a saved workflow, naming sibling alternatives directly.

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

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

Provides explicit when-to-use guidance: "When the user says 'run it', 'run it once', 'test it' or 'try it' about a workflow, this is the tool they mean." It also names alternatives not to use (browser_task/create_session) and describes the post-call flow via get_task_status.

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 signal non-read-only and destructive nature, but the description goes well beyond: it explains whole-replace semantics for objects/arrays, null-to-clear behavior, slug stability on rename, schedule being record-only, and memoryContract being the exception to whole-replace. This adds significant behavior beyond annotations without any contradiction.

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 lengthy but packed with essential detail for a 39-parameter tool. It opens with the core usage, then clarifies edge cases. While not short, it avoids redundancy and is well-structured, earning a strong score though not perfect conciseness.

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

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

For a tool with 39 parameters, the description is exceptionally complete. It covers update mechanics, special behaviors (schedule, memoryContract), cross-references to create_workflow for promptTemplate contract, and clarifies the output schema is not needed to explain return values. Nothing an agent needs to invoke it correctly appears missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds valuable update semantics not captured in individual parameter descriptions: the overall 'replace whole' rule, null-to-clear guidance, and the memoryContract exception. This supplements the schema meaningfully, raising the 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 states a specific verb ('Update') and a specific resource ('an existing workflow'), and the contrast with sibling tools like create_workflow and get_workflow is implicit. It clearly distinguishes itself as a mutation tool for existing 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?

It provides clear guidance on how to use: supply workflowId plus only changed fields, pass null to clear. It also clarifies the schedule behavior (record-only, deployed agents unaffected). However, it does not explicitly state when NOT to use it (e.g., for creation use create_workflow) or mention alternatives like get_workflow for reading. The usage context is strong but lacks explicit exclusions.

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