WebRun Browser Automation

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

Beyond annotations, the description discloses that the tool creates a session, auto-terminates, may navigate and fill forms on third-party sites, and may submit data. It also warns that a session run behaves differently from a workflow run. This aligns with and enriches the destructiveHint and openWorldHint 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 lifecycle, then provides usage guidance and an explicit sibling distinction. Every sentence contributes behavioral context, selection criteria, or an important warning. There is 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 complex tool with 15 parameters, the description covers purpose, environment, lifecycle, side effects, and when not to use it. The exhaustive parameter schema handles parameter-specific details, and the sibling context is explicitly addressed. Nothing essential is missing 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 input schema has 100% parameter description coverage, so the schema itself fully documents all 15 parameters. The description adds no additional parameter-level semantics, but it does not need to. This matches the baseline of 3 for a high-coverage schema.

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

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

The description states a specific verb and resource: executing a browser automation task in a real Chrome browser in a WebRun cloud environment. It clearly distinguishes this from trigger_workflow by describing the session lifecycle and one-off task scope. The agent can immediately tell what the tool does and how it differs from 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 explicitly says this tool is best for simple one-off tasks not covered by a saved workflow. It names trigger_workflow as the alternative and even maps natural-language phrases like 'run it' or 'test it' to the correct sibling. This is unusually strong routing 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 discloses significant behavioral traits beyond the annotations: the platform copies workflow settings, bakes variables into the prompt, results are delivered to the connected chat and session history, memory is automatically updated, and the schedule timezone also drives the browser session. It also warns about proxy country mismatch causing login issues. These details are not present in the annotations and greatly enhance understanding.

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 sections for modes and parameter-specific guidance. Every sentence contributes value, and the organization makes the complexity navigable. It is appropriately detailed for a tool this complex, though a slightly more compact format could be imagined.

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 (12 parameters, nested objects, two modes), the description is remarkably complete. It covers the core behavior, user interaction guidelines, prompt construction, proxy nuances, memory rules, and output delivery. The presence of an output schema and comprehensive parameter descriptions further bolster completeness. Nothing essential is missing.

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

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

Although schema_description_coverage is 100%, the description adds substantial meaning beyond the schema. For example, it explains how to structure a prompt as a browsing runbook (Goal, Ground rules, Stages, Output), provides rules for memory seeding, clarifies proxy modes and country recommendations, and specifies when variables are required. This goes far beyond what the schema descriptions offer.

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

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

The description clearly states the tool creates a scheduled agent, a recurring or one-time automation running in a real Chrome browser. It explicitly distinguishes two modes (workflow mode and standalone mode), which differentiates it from sibling tools like create_workflow and list_agents. 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 explicit guidance on when to use each mode: use workflowId to deploy a workflow, or omit it for standalone. It also instructs the agent on how to interact with the user ('Ask the user only what it should do and when it should run'), what to avoid (never ask about environments or technical settings), and even details proxy country recommendations for social/messaging workflows. This is comprehensive and actionable.

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 goes beyond annotations by noting the session runs in a "real Chrome browser" in a cloud environment, returns a sessionId, and that "with an initial task the browser may act on third-party websites immediately." This complements the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=true). It does not contradict them. It could still mention that persistent sessions may need explicit cleanup/termination, but most safety-critical traits are disclosed.

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?

Every sentence earns its place: core function, return value, unexpected side effect, and the caution about trigger_workflow. The sentences are front-loaded and concise, with no filler or redundancy. The more involved exclusion sentence is still clearly structured.

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

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

Given 9 parameters, rich nested objects, a full input schema, annotations, and an output schema, the description supplies the essential decision-making context: what a session is, that it is stateful, that it may take real-world actions, and that it is not a workflow runner. Nothing critical needed for selecting or invoking the tool appears to be missing.

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

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

Schema description coverage is 100%, so the input schema already documents each parameter. The prose does not need to repeat parameter details, and it does not add much semantics beyond what the schema provides. The schema itself already explains key nuances like proxy levels and timezone interpretation.

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 action and object — "Create a persistent session" — and clarifies the resource as "a real Chrome browser running in a WebRun cloud environment" for "multi-step interactive work." It also explicitly separates this from running a saved workflow, naming the sibling trigger_workflow as the alternative, which removes ambiguity.

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

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

It provides explicit when-to-use guidance ("for multi-step interactive work") and an explicit when-not-to-use rule with a named alternative: "Do NOT use this to run or test a saved workflow — use trigger_workflow instead." It also explains why the alternative is required: only a workflow run carries the workflow's rules, tracking, and memory, and a session run behaves 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 provide minimal behavioral hints (all false), so the description must fully disclose behavior. It explains that environment is auto-applied, schedules are record-only (no timer until deployed), tracking is wired automatically, and variable values are only applied via MCP trigger. It also warns about proxy country concerns for social/messaging workflows. 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?

The description is long, but each section earns its place given the tool's complexity (38 params). The essential decision point (readiness bar) is front-loaded, and later sections are clearly structured with labels like 'READINESS BAR' and 'To run or TEST.' Slight redundancy (repeating the {{variables}} guidance in promptTemplate and variableValues) but overall efficient for the stakes.

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 full lifecycle: prerequisites (collect facts), required fields, prompt authoring pattern, memory contract necessity, schedule semantics, deployment path (through create_agent), and testing route (trigger_workflow). It also gives guidance on optional parameters like proxy, skills, and variable handling. The output schema is provided separately, so return format is complete. Nothing critical is missing.

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

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

Schema has 100% description coverage, but the tool description adds richness beyond them: for promptTemplate it gives the runbook structure (Goal/Ground rules/Stages/Output), for memoryContract it explains when required and how to write the three fields, for proxy it gives WebRun vs custom and country guidance, and for environmentId it instructs to omit. This is decisive, actionable parameter guidance.

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

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

The description clearly states the tool creates a saved workflow, lists required fields, and frames the action with a readiness bar. It distinguishes from sibling tools by naming trigger_workflow (to run/test), create_agent (to deploy), and browser_task/session (to execute) as alternatives. This removes ambiguity about the tool's core function.

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

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

Explicitly states 'To run or TEST the workflow, use trigger_workflow ONLY — never browser_task or create_session.' It also specifies when memoryContract is required ('for tasks that must handle each new item exactly once') and when to omit IDs (environmentId, schedule). The description consistently provides concrete conditions for choosing this tool over others.

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

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

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 declare destructiveHint=true and idempotentHint=true, and the description adds valuable behavioral context: full replacement of object/array fields, null to clear optional fields, slug stability on rename, schedule being record-only until deployed as scheduled agent, and memoryContract partial-update exception. This goes beyond what annotations provide. However, it doesn't explicitly mention reversibility or confirmation beyond the idempotent hint, and the destructive nature is implied by 'update' plus the hint, though not explicitly described as irreversible.

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 reasonably concise for a complex tool, front-loading the core behavior (supply workflowId plus only changed fields) and then providing targeted details about edge cases (null clearing, slug stability, schedule semantics, memoryContract). It's a bit dense but each sentence earns its place by conveying behavior not found in the schema. It could be slightly tighter, but is well-structured.

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

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

Given the tool's complexity (39 params, nested objects, output schema), the description covers the key update semantics and caveats (replacement, null clearing, schedule record-only, memoryContract exception). The output schema exists, so return values are covered there. It doesn't explicitly walk through every parameter because the schema covers them, and the description focuses on the critical behavioral nuances an agent must know. A slightly higher score would require more explicit mention of which parameters are commonly updated together, but this is already strong.

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

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

Schema description coverage is 100%, so the schema already documents all 39 parameters thoroughly. The description adds a small amount of semantic value by summarizing the partial-update behavior and highlighting how memoryContract differs from whole-replace, but most parameter detail is in the schema. Baseline 3 applies as schema does the heavy lifting.

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 resource ('an existing workflow') and clearly differentiates from siblings like create_workflow and trigger_workflow by emphasizing partial updates and the workflowId requirement. It also names the runbook contract for promptTemplate and the exception for memoryContract, which distinguishes it from create_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 explicitly says to supply workflowId plus only the fields to change, which is a clear usage directive. It also provides important when-to-use context: object/array fields are replaced whole, null clears optional fields, and renaming via title keeps slug stable. It distinguishes from create_workflow by referencing the same runbook contract and the memoryContract exception. This is explicit guidance for the update use case.

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