WebRun Browser Automation

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

Discloses that it creates a session, runs the task, and auto-terminates, and warns about side effects on third-party websites. Annotations already cover destructive and openWorld hints, but the description adds context about session lifecycle and behavioral differences from workflows.

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?

Well-structured and front-loaded: starts with core action, then lifecycle, then usage guidance and exclusion. Every sentence contributes value, with no filler or redundancy.

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

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

Given the tool's complexity (15 params, nested objects, output schema) and rich schema, the description covers the key usage context and lifecycle. It could explicitly state the return format, but that is partially addressed by outputType/outputSchema parameters and sibling tools for status.

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

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

Schema coverage is 100%, so all 15 parameters have detailed descriptions in the schema. The tool description itself does not add additional parameter-specific details beyond the schema, which is the baseline for high 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?

Clearly states the tool executes browser automation tasks in a real Chrome browser via WebRun, and explicitly differentiates from trigger_workflow. The verb 'execute' plus resource 'browser task' is 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?

Explicitly states it is best for one-off tasks not covered by workflows, and explicitly warns against using it for saved workflows, naming trigger_workflow as the alternative. Also clarifies that phrases like 'run it' about a workflow should route to trigger_workflow.

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 adds context beyond annotations by warning that with an initial task the browser may act on third-party websites immediately, and by noting the behavioral difference from workflows. It does not cover session lifecycle or authentication, but the openWorld and destructive flags are complemented by this concrete side-effect warning.

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-loading the core purpose and the critical workflow exclusion. Every sentence earns its place, and there is 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?

For a complex tool with 9 parameters and an output schema, the description covers the essential decision points: what it does, what it returns, its side effects, and when not to use it. It does not detail session management (e.g., using terminate_session), but the rich schema and output schema fill in the rest, making this 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?

Schema coverage is 100%, so all 9 parameters are described in the input schema, including nested objects like proxy and task. The description does not add parameter-level semantics beyond the schema; it only mentions the sessionId return value, which is an output, not a parameter. A 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 creates a persistent Chrome browser session for multi-step interactive work in a WebRun environment, and explicitly contrasts it with trigger_workflow. The verb 'Create' and specific resource 'persistent session' are precise, and the exclusion of workflows distinguishes it from the most likely sibling.

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

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

The description gives an explicit when-not-to-use instruction: 'Do NOT use this to run or test a saved workflow' and names the alternative trigger_workflow, explaining why (workflow carries its own rules, tracking, and memory). This is clear, actionable guidance.

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

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

Annotations indicate this is not read-only or destructive, but the description adds significant behavioral context: the schedule is record-only and does not run until deployed, environment is auto-applied, variables usage policy, and platform wires tracking. It clearly explains side effects and non-side effects. No contradictions.

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 informative with critical guidance front-loaded (readiness bar, required fields, memory contract, environment). Some redundancy with schema field descriptions (proxy, memory) but those are essential because the schema is large. A bit more trimming possible, but each sentence adds value.

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

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

Given 38 parameters and high complexity, the description covers the key user-facing decisions: what to ask, what to write, what to omit, and how to handle memory and variables. It also explains schedule limitation and testing workflow. Output schema is present, so return values are covered. No major gaps for correct invocation.

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

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

Schema already has 100% coverage but the description adds high-value guidance beyond param names: promptTemplate structure, memoryContract field semantics (plain English, platform wires tracking), and variable usage rules. It reduces ambiguity around when to supply dynamic templates and how to write fields.

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 it creates a new saved workflow, distinguishing it from trigger_workflow (which runs it) and update_workflow. It clearly frames the key responsibility: turning a user request into a proper browsing runbook with required fields and memory contract conditions.

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 readiness bar for when to create vs. collect more facts, explicitly states when memoryContract is required, and gives strong exclusions: omit environmentId, use trigger_workflow for running/testing, not browser_task or create_session. This routes the agent to correct alternatives.

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's 'Read-only: reports on the task without affecting it' largely restates the readOnlyHint/destructiveHint annotations already provided. It does add genuinely new behavioral context — that the tool is meant for polling and that a guardrail state may surface (pointing toward guardrail_response) — but does not cover polling frequency, terminal states, or auth needs.

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 with the purpose front-loaded and no filler. The final read-only sentence is mildly redundant with the annotations, which keeps it from a 5.

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?

An output schema exists, so return-value/state enumeration is not the description's burden, and the essential prerequisite (a previously started task in a session) plus the polling intent are covered. Minor gaps remain around polling cadence and terminal state handling.

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% and both parameters are named and described in the schema, so the baseline is 3. The description only indirectly links sessionId to a browser session ('started in a browser session') and adds no format or ID-provenance detail 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+resource ('Check the status of a task') and scopes it to a task 'previously started in a browser session', which separates it from generic session tools. It does not explicitly name the sibling it differs from (e.g., guardrail_response, pause_session_task), so it falls short of full sibling differentiation.

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?

Gives concrete usage context: 'Use to poll for completion or detect guardrails', which tells the agent when this tool is the right call. It stops short of naming alternatives or stating exclusions, so it is clear context without 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond annotations, including that proxy credentials are masked and that pending logins and memory state are surfaced.

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 and then enumerates returned detail efficiently. It is dense but mostly earns its length given the breadth of returned fields, though the single long sentence could be easier to scan.

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

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

With annotations covering safety, an output schema present, and full schema coverage for both parameters, the description fills the remaining gaps: what detail is returned, how to identify the workflow, and where to page work-list data. An agent has enough information 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?

Schema coverage is 100%, and the schema already documents the exact-title and 24-hex workflowId formats. The description reinforces that either identifier works but does not add syntax or constraints 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 a specific verb and resource ("Full detail of one workflow") and enumerates the concrete contents returned, including prompt variables, triggers, run settings, memory, pending logins, and work-list summary. That lets an agent distinguish it from list_workflows, create_workflow, and update_workflow without inspecting schemas.

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 clearly establishes the lookup mode (by workflowId or exact title) and routes work-list paging to get_work_list. It does not explicitly say when to use this instead of list_workflows for discovery, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by explaining the band taxonomy and cursor-based pagination, though it repeats 'Read-only' and does not discuss auth or rate limits.

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 quickly explains bands, workflow identification, filtering, and pagination. Every sentence contributes to correct invocation, and the final 'Read-only' note is brief and useful.

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

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

The tool has an output schema and rich annotations, and the description fills the remaining gaps an agent needs: band meanings, workflow identification by ID or exact title, filtering, and cursor pagination. Nothing critical for selecting or invoking the tool 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 description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics by enumerating the watch-list and collect-list band values, which the schema itself does not list as enums. It also clarifies that title is an alternative to workflowId and that cursor is the previous nextCursor.

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: paging through a workflow's work list kept between runs. It also distinguishes the operation from the mutation sibling update_work_list by explicitly calling this read-only, so an agent can identify the intended tool without opening schemas.

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 gives concrete invocation guidance: identify the workflow by workflowId or exact title, filter by band or query, and pass nextCursor as cursor for the next page. It does not explicitly name alternatives such as get_workflow or update_work_list, but the read-only paging context is clear.

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

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

With destructiveHint=true and idempotentHint=false already declared, the description adds the key consequence: the response is handed to the live agent, which continues acting on it. That tells the agent its text has real downstream effect on a running session. It does not elaborate on what makes the call destructive or what a stale askId means, which the schema handles instead.

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, zero waste, with the trigger condition front-loaded and the consequence second. Nothing is padded or repeated from the schema.

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

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

Output schema exists, so return values need no explanation, and the schema covers all six parameters thoroughly. The description supplies the trigger and the downstream effect, which is most of what an agent needs before calling a destructive, open-world tool. Only the relationship to adjacent tools (get_task_status, send_task) is left implicit.

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 every parameter is already documented in detail, including askId, newState, response, decisions, and files. The description only adds the parenthetical input types (credentials, clarification, approval), which is marginal beyond the schema. Baseline 3 is correct.

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 ('Respond to a guardrail trigger') plus the concrete situation that produces it (browser agent needs credentials, clarification, or approval). An agent can distinguish it from generic task tools, though it never names a sibling such as send_task or resume_agent to sharpen the boundary.

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?

Gives a clear triggering condition ('when the browser agent needs human input') and lists the three input types that qualify. It does not state when not to use it or explicitly route to alternatives, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered; the trailing "Read-only" largely repeats that. What the description adds beyond annotations is the default environment-binding behavior and the account-wide escape hatch, which is real behavioral context for an agent deciding how results are filtered.

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?

Front-loaded with the core purpose and the field list, and it is compact overall. The standalone "Read-only." sentence is redundant with the annotations and is the one piece of text that does not earn its place.

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

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

An output schema exists, so return values need not be explained, yet the description still previews them. For a zero-required-parameter, single-enum list tool with full annotations, everything an agent needs to invoke it correctly is present.

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

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

Schema description coverage is 100% and the single enum's meaning is fully documented in the schema, so the baseline is 3. The description restates the scope semantics (bound environment by default, "all" for everything) without adding format or side-effect detail 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?

Specific verb (List) plus resource (account's scheduled agents / cron deployments), and it names the returned fields (schedule, status, next/last run, standalone vs workflow-deployed). An agent can distinguish this from create_agent, pause_agent, or list_workflows without opening the schema.

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

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

Gives clear context: results are scoped to the bound environment, and passing scope "all" widens to every environment. It does not explicitly name a sibling alternative or a when-not-to-use case, but the environment-scoping condition is stated plainly.

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, idempotentHint and destructiveHint=false, so the explicit "Read-only." repeats structured data. However, the description adds genuinely new context: what the output is for, and a caveat that the tool is rarely needed and the user should not be prompted to choose. That goes meaningfully beyond the annotation set.

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

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

Three sentences, front-loaded with purpose, then usage, then the caution. Every sentence carries weight except "Read-only.", which duplicates the readOnlyHint annotation and could be dropped. Very near optimal otherwise.

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?

An output schema exists, so return values need not be re-explained; the description still usefully says what the IDs are for. Combined with the when-to-use guidance and the no-parameter schema, an agent has everything needed to call this 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 takes zero parameters and schema coverage is 100%, so there is nothing for the description to disambiguate. The baseline for a parameterless tool applies; no additional meaning is required or missing.

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 ("List available browser environments (persistent profiles)") and clarifies the payload's purpose by noting it returns environment IDs. It also names the sibling tools that consume those IDs (browser_task, create_session), letting an agent place it precisely in the tool graph.

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 in browser_task or create_session) and when it is not (workflows and agents use the connection's environment automatically). It even gives a behavioral instruction — do not ask the user to choose an environment — which is exactly the routing guidance an agent needs.

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, idempotentHint, non-destructive, and closed-world behavior, so the description's 'Read-only' is redundant. It does add the scoping traits 'active' and 'for this account' beyond the annotations, which is useful behavioral context, but it does not cover return format, pagination, or other operational details.

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

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

Two short sentences, front-loaded with the core purpose and followed by a safety note. There is no filler or repetition, and the size is appropriate for a simple list operation.

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

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

Given no parameters, rich annotations, and an output schema, the description is nearly complete: it defines the resource, scope, and read-only nature. It could be marginally better by noting that results are returned as a list, but the output schema covers return values, so this is not a significant gap.

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

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

The tool has zero parameters and schema coverage is 100%, so the schema fully defines the input. The description does not need to add parameter meaning, and the baseline for zero parameters is 4.

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 (List), resource (browser sessions), and scope (active, for this account). It clearly distinguishes the resource from siblings like list_agents and list_workflows, though it does not explicitly name an alternative or contrast with them.

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 purpose implies the tool should be used to retrieve active sessions, but there is no explicit when-to-use guidance, prerequisites, or named alternatives. It gives enough context for an agent to infer usage, but no more.

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, idempotentHint and openWorldHint=false, so the trailing 'Read-only' is largely redundant. The description still adds real behavioral context beyond annotations: the connection-binding scoping behavior and the shape of what comes back (title, schedule, {{variables}}, run stats).

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, front-loaded with the core action and the resource definition, then scoping, then the safety note. No filler and nothing out of order.

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

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

For a single-optional-parameter list tool with a full output schema and complete annotations, the description covers action, resource, scoping behavior, returned fields, and safety profile. Nothing an agent needs to invoke it correctly 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 description coverage is 100%, so both enum values and the binding-dependent default are already documented in the schema. The description restates the same scope semantics without adding syntax, format, or edge-case detail, so the baseline of 3 applies.

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

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

States a specific verb and resource ('List the user's saved workflows') and immediately defines what that resource is with a parenthetical gloss ('prompt-templated browser automations, docs.webrun.ai'). It also enumerates the returned fields, which cleanly separates it from the singular get_workflow sibling.

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

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

Explicitly describes the selection rule for the scope parameter: default is the bound environment, and 'all' broadens to every environment. It gives clear context for when each mode applies, but never names an alternative tool (e.g., get_workflow) or states when not to use this one.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds the return modality — the screenshot comes back as an inline image, not a file path or URL — which is meaningful behavioral context an agent needs to handle the response. 'Read-only' simply restates the annotation and earns no credit.

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, front-loaded with the action, then the return format, then the safety trait. No padding, no redundancy beyond the harmless 'Read-only' restatement.

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

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

The tool is simple (one required param), safety is fully covered by annotations, and an output schema exists so return values need not be explained in prose. The description covers purpose, precondition and return modality adequately; only the absence of routing guidance to related siblings keeps it from being fully complete.

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

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

Schema coverage is 100% with a single required sessionId, so the schema carries the parameter documentation. The description contributes only the indirect signal that the session must be active; it adds no syntax, format, or meaning beyond what the schema already provides, matching the baseline of 3.

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

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

States a specific verb and resource ('Capture a screenshot of the current browser page in an active session'), which is unambiguous and easy to tell apart from siblings like send_task or create_session by name alone. It stops short of explicitly naming or contrasting with any sibling, but the purpose itself is precise.

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?

'in an active session' implies the prerequisite that a session must already exist, which is useful context. However, there is no explicit when-to-use guidance, no statement of when not to use it, and no pointer to which sibling to use instead for related operations.

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?

It adds concrete behavioral disclosure beyond the annotations: 'The real Chrome browser may navigate, fill forms, and submit data on third-party websites as the task requires.' This warns the agent about real-world side effects and aligns with openWorldHint and destructiveHint.

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 purposeful sentences: the first states the operation and prerequisite, the second warns about real-world behavior. No redundant information.

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

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

For a tool with 12 parameters, full schema coverage, an output schema, and safety annotations, the description provides enough context for selection and invocation. It could mention asynchronous behavior, but the sibling get_task_status and output schema reduce that gap.

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

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

Schema description coverage is 100%, so the parameter descriptions already carry the meaning. The text adds no new parameter details beyond the session prerequisite, so the baseline 3 applies.

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

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

The description states a clear action ('send a new task') and target ('existing browser session'), and references create_session as the prerequisite. It does not explicitly differentiate from sibling tools like browser_task, but 'new task to an existing session' is reasonably specific.

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 it: after create_session, to add a task to that session. It gives the prerequisite context but does not name alternatives or exclusions such as using browser_task for standalone 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?

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?

Adds substantial context beyond the destructiveHint=true/idempotentHint=true annotations: object/array fields are replaced whole, null clears optional fields, memoryContract is a documented exception that partially updates, and the schedule is record-only and does not run on a timer. It also explains the typed-list constraints (outputSchema needs workList keep/empty, listType and queue mode are immutable). This is exactly the behavioral disclosure an agent needs for a destructive mutation.

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?

Front-loads the core partial-update rule in the first two sentences, then layers the trickier conditional flows. Dense but nearly every sentence carries behavioral weight; the promptTemplate runbook reference is long but points to another field's description rather than duplicating it.

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 43-parameter destructive mutation with a 100%-covered schema and an output schema, the description covers the high-risk interactions (resultType confirmation, workList requirement, schedule record-only, memoryContract exception). Minor gaps remain around environmentId refusal consequences and error behavior, but the critical call decisions are covered.

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, but the description adds real meaning above the per-property text: whole-replace vs partial semantics, null-clearing, the memoryContract exception, rename-stability of the slug, and how outputSchema/workList interact. It does not attempt to re-document the many mundane fields, which is appropriate given the schema already does.

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

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

The description opens with a specific verb+resource ('Update an existing workflow') and immediately defines partial-update semantics. It differentiates from create_workflow implicitly via 'same contract as create_workflow' and the 'only the fields to change' framing, though it never names create_workflow or get_workflow as the sibling to use for creation/reads.

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?

Gives clear operational context: supply workflowId plus only changed fields, pass null to clear, and specific gating rules for resultType (preview then confirm) and workList (ask the user). It stops short of explicit when-to-use/when-not guidance relative to create_workflow or update_work_list.

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 readOnlyHint=false, but the description adds context they cannot carry: a human-confirmation requirement for remove/clear, a refusal condition (run in progress), and per-op semantics such as clear dropping readings on a watch list while keeping watched items. It stops short of saying whether anything is recoverable after a destructive op, which keeps it off a 5.

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?

Front-loaded with the core purpose, then op semantics, then constraints — nothing redundant. It is a single dense paragraph with stacked parentheticals, which costs some scannability but not correctness.

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 annotations covering the safety profile and an output schema covering returns, the description supplies what remains: op meanings, retention behavior, confirmation policy, and the in-progress refusal. Only the recovery/undo story is unaddressed for a destructive tool.

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

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

Schema coverage is 80%, so the schema documents items, title, workflowId and keepHandled. The description's real contribution is decoding the op enum — add/remove behave differently on a watch list, skip_approval targets drafts awaiting approval, clear has list-type-dependent retention — meaning the enum values are unusable without it. It does not restate the item object shape, which the schema already covers.

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 with scope: change the work list a workflow keeps between runs. It explicitly distinguishes itself from the two nearest siblings — get_work_list (read) and update_workflow (change what the list records) — so the agent can route without opening a schema.

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

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

Enumerates every op with the condition that selects it, names the alternative tool for a related-but-different need (update_workflow), requires user confirmation for remove/clear, and states the tool is refused while a run is in progress. That is explicit when/when-not/alternatives coverage.

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