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

Annotations only flag openWorldHint and destructiveHint, but the description adds substantial behavior: return shape (recorded steps + new snapshot), verified-selector generation with a `fragile: true` marker for positional fallbacks, the refusal condition while a run item awaits verification, and hard safety rules (only the user decides what to submit, upload only named files, never type passwords). This is far more than the 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?

Front-loaded with the core action and return value, then layered with selector, safety, and gating details. It is dense with parentheticals but nearly every clause carries operational weight, so it reads as compact rather than padded.

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 destructive, open-world tool with no output schema, the description supplies the return shape, the selector-quality signal, the safety constraints, and the refusal condition an agent needs before invoking. Coverage is strong; only minor gaps remain around what happens on partial batch failure.

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?

Top-level schema coverage is only 33% (actions and snapshot are undocumented), but the description compensates by explaining the `inspect` mode's behavior and the batch semantics of the actions array. The nested action fields are well described in the schema itself, so the description adds meaning where the schema is thin without needing to restate the rest.

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 (performs actions), resource (elements of the current page), and mechanism (by ref), plus the side effect of recording a task and returning steps with a fresh snapshot. An agent can distinguish this from browser_snapshot, browser_open, and the run_* tools without opening any 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 routing context: `inspect` acts on nothing and is named as the input for step_repair, batching multiple steps in one call is endorsed, and the tool is 'Refused while a submitted run item awaits verification.' It stops short of explicit when-not-to-use exclusions against siblings like browser_open, but the operational context is strong.

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?

Goes well beyond the annotations (which only flag openWorld/idempotent/non-destructive) by disclosing that logins persist in a dedicated profile, that the action is recorded as a goto step in a task, that the page may be truncated, and that snapshot text is untrusted data whose instructions must never be followed. These are material behavioral facts an agent cannot infer from structured fields.

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 action and return value, then appends only operationally necessary caveats (login handoff, untrusted snapshot) in short clauses. No filler or restatement 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?

With no output schema, the description still explains what is returned (accessibility snapshot with ref ids), how it is consumed (browser_act), and the safety posture of the returned content. Nothing an agent needs to invoke this correctly appears missing.

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

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

Schema coverage is 50%: maxChars is documented in the schema, url is not. The description constrains the url to http(s), which is real added meaning, but it never mentions maxChars or the truncation cap parameter beyond the general snapshot note. Baseline 3 is appropriate given the partial 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?

States a specific verb and resource ('Opens an http(s) URL in Ritoko's Chrome') and disambiguates from siblings by naming the return artifact and its consumer ('accessibility snapshot with [ref=…] ids for browser_act'). An agent can tell this apart from browser_snapshot and browser_act 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?

Gives concrete context for use (dedicated profile with persisting logins, records a goto step) and explicit handling for blocked flows ('On a login, MFA or CAPTCHA page, ask the user to complete it in that window'). It routes the snapshot refs to browser_act, but does not explicitly state when to prefer browser_open over browser_snapshot or how it fits the workflow/run siblings.

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

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

Annotations already declare readOnlyHint=true, but the description adds substantive behavior: refs may change after navigation (e4→f1e4), and the snapshot text is untrusted website data. The security warning and ref-mutation caveat are genuinely beyond the annotation and valuable to an agent.

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 'Read-only.' followed by tightly-packed, clause-separated facts. Every sentence carries information; density is high but no filler is present.

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

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

With no output schema, the description carries the return-value burden and largely meets it: it explains the accessibility snapshot format, the [ref=…] ids, the optional subtree narrowing, and the read-only nature. Truncation behavior is left to the schema, which handles it adequately.

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 ref and maxChars are already documented in the schema. The description's 'Pass ref to get only that element's subtree' mirrors the schema's own text and adds no new syntax or format detail, making 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?

States a specific verb+resource: 'Accessibility snapshot of the current page.' It situates the tool relative to siblings by explaining its output ([ref=…] ids) feeds browser_act, so an agent can distinguish it from browser_open/browser_act 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?

Clear context is given: use ref ids 'exactly as shown in the latest snapshot,' pass ref to get a subtree, and it 'works during a run.' The linkage to browser_act establishes when to reach for it, though there is no explicit when-not-to-use exclusion.

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 and openWorldHint=false, but the description goes further: it lists exactly what gets inspected, states that each check returns pass/warn/fail along with a fix, and adds the non-obvious side-effect guarantee 'Starts no browser.' That is meaningful behavioral context beyond the structured hints.

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 safety mode ('Read-only'), then the check inventory, then the invocation trigger. Every clause carries information — component names, result vocabulary, and the no-browser guarantee — with no filler sentences.

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

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

With no parameters, no output schema and a straightforward read-only diagnostic, the description supplies everything an agent needs: what is checked, what the results mean (pass/warn/fail plus a fix), that no browser launches, and when to reach for it. No output schema is needed given the result vocabulary is described.

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, so there are no values for the description to explain; the schema is empty and 100% covered by definition. Baseline 4 applies — nothing about parameter meaning is missing because there are no parameters.

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

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

The description gives a specific verb (checks) plus an enumerated resource list — Node.js, node:sqlite, the Ritoko home, the journal, playwright-core, RITOKO_BROWSER, the Chrome executable. That specificity clearly separates it from siblings like browser_open, run_start or step_repair, which operate on runs rather than on the installation itself.

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 states concrete triggers: use it when Ritoko cannot start a run or open Chrome, or when the user asks to check the setup, and it delimits scope with 'Starts no browser.' There is no explicit when-not or named alternative diagnostic tool, so it falls just 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful behavior beyond that: no OCR, no AI provider call, the returned artifact is a raw JPEG/PNG for the caller's model to interpret. It stops short of error/edge behavior (missing file, non-image path), but adds real value over 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?

Three compact sentences with the key qualifier ('Read-only.') front-loaded, followed by return type and parameter mechanics. Every sentence contributes, though the 'for the user to have you read it with your own model' clause is slightly verbose relative to the information it carries.

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 2-parameter, read-only tool with no output schema, the description covers return type, permitted sources, and path/runId semantics — everything needed to invoke it correctly. It omits failure modes (file not found, unsupported format) and any size/count limits, which is a minor gap given 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?

Schema coverage is only 50% (runId has no schema description), yet the description compensates: it explains that a run file is passed with its runId and a path relative to the run dir, versus an absolute path for a browser_act download. That ambiguity resolution (relative + runId vs absolute) is exactly what the schema leaves unclear, though the runId's own format/constraints remain unstated.

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 ('Returns a JPEG or PNG ... as an image') plus the exact sources it reads from (run evidence, run file, browser_act download). It also sharply distinguishes itself from anything that might be assumed to do OCR or call a model ('Ritoko does no OCR and calls no AI provider'), so an agent understands what kind of read this is without opening another 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 for when to reach for it: when the user needs the agent's own model to see a downloaded/captured image, and it names the three concrete origins (run evidence, run file, browser_act download). It does not name an explicit alternative tool or a 'when not to use' case, so it stops short of full 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 only declare openWorldHint and destructiveHint; the description goes well beyond them by documenting per-action semantics (navigate opens url, run_js needs page-script execution and returns raw JSON, click is a real click), the results array shape, error payload fields, and strong invariants ('Never invent outcomes or execute a batch twice'). Its one gap is that it never calls out the destructive side effects the destructiveHint annotation implies.

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 purpose is front-loaded, but the rest is a dense run-on block of semicolon-clause jargon and abbreviations with no grouping or bullets. Every sentence carries information, yet the structure forces the reader to parse hard to extract the rules.

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

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

With no output schema, the description correctly shoulders the burden of describing returns: 'done:{status,counts,files}', the {actionId,result:<raw MCP result>} envelope, and the error shape with completed/error/results. Combined with the resume and review guidance, an agent has enough to drive the loop, though the batching/counting protocol could be spelled out a bit more.

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

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

Schema description coverage is 0% across 5 params, so the description must carry the load, and it does: batch is a numbered batch that gets echoed, results holds one entry per run_js/tool in action order (none for navigate/click), error carries a message, completed counts fully finished actions, and runId drives resume with no results. This is substantive meaning beyond the bare types in the schema.

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

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

The opening sentence names a specific verb+resource ('Records a numbered batch and returns the next actions or done:{status,counts,files}'), which is precise and unambiguous. It's clear this is the work-loop primitive, but the description never explicitly contrasts itself with sibling host_start, so the differentiation is implicit rather than stated.

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 real routing guidance: 'Report problem rows with run_report; resolve review only after checking the destination,' and 'Resume an interrupted host run with host_next(runId) and no results.' That tells the agent both when to use this tool and when to hand off to run_report. It lacks an explicit when-not-to-use statement, keeping it from 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?

With annotations already declaring openWorldHint and destructiveHint, the description still adds meaningful behavior: commit is journaled before dispatch, missing write results are held for review, done keys are skipped, one tab per slot, parallel 1..4, existing MCP connections with frozen args, and unsupported operations in host mode. These go well beyond the annotations, though some statements are cryptic fragments rather than clearly actionable disclosures.

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?

It is front-loaded with the core purpose and the return shape, which is good, but the bulk is a run of telegraphic jargon fragments ('frozen args', 'done keys skipped', 'HTTP session:browser needs the browser runner') that add density rather than clarity. Appropriate length for the complexity, weaker structure.

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

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

With no output schema, the description usefully supplies the return shape ({runId,batch,actions,note}) and covers execution semantics, permissions, and mode constraints. It is fairly complete for a destructive, open-world batch runner, though the undefined workflow/params inputs remain a 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 0%, so the description must carry the load, but it only echoes the parallel constraint ('parallel 1..4') that the schema already encodes and never explains what 'workflow' or 'params' contain. The required parameter and the nested-string params object are effectively undocumented.

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 first sentence states a specific verb and resource ('Runs an authorized item batch with an agent host') and contrasts browser batches against API-only/agent-tool batches that need no browser. It is reasonably clear what the tool does, but it never distinguishes itself from the closely named sibling run_start, and terms like 'agent host' and 'slot' are left undefined.

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 partial conditional guidance ('Browser actions require permission...', 'API-only and agent-tool batches need no browser', 'Follow host_next'), which implies when the tool is appropriate. However, it never states explicitly when to choose host_start over run_start/run_resume, nor what prerequisites or exclusions select among them.

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

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

Annotations only declare openWorldHint=false and destructiveHint=false, leaving the description to carry the rest – and it does, disclosing the data's provenance (browser_open/browser_act) and its retention window (reset by clear or workflow_save). Return format/pagination is still unstated, but the recording-buffer lifecycle is meaningfully 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?

Front-loaded with what the tool is, then a compact usage flow in the second and third sentences. Dense but each clause (clear, substitution, expect steps, commit flag, workflow_save) maps to a real workflow action, with little wasted 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?

No output schema, but the description and the clear/network param docs together cover what is returned, where it comes from, and how to consume it. For a two-param, zero-required read tool with safety annotations already present, this is close to sufficient; only the exact shape of returned steps is unspecified.

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 parameters are already fully documented and the baseline is 3. The description only reiterates clear:true as a workflow step and says nothing about the network parameter, so it adds little semantic value beyond the schema.

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

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

The description states a specific resource (steps recorded by browser_open and browser_act) and its temporal scope (since the last clear or workflow_save), which lets an agent separate it from workflow_get (saved workflows) without opening schemas. It never uses an explicit retrieval verb like 'returns'/'lists', but the meaning is 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?

It gives concrete lifecycle guidance: call with clear:true before recording a new task, and it names workflow_save as the explicit follow-up action. It does not spell out when not to use it versus siblings like workflow_get, so it stops short of a full 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?

Adds substantial behavior beyond the annotations: it journals the run as done so replays skip it, a failed check leaves it in review, and it returns 'the same bounded result as run_start.' The destructiveHint=true annotation is consistent with the journaling state mutation described, and the description usefully clarifies that it does not resubmit the row.

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 trigger condition, then the behavior, then the parameter call-to-action. Three sentences with little waste, though the first sentence is dense and could be split for readability.

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 state-mutating tool with no output schema and 0% schema coverage, the description covers the key behaviors and the return shape, but omits the meaning of the 'workflow' and 'params' inputs. Adequate but not fully self-sufficient.

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

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

Schema coverage is 0%, so the description carries the full burden, and it only clarifies two of four parameters ('the exact recorded row data and an evidence note'). The 'workflow' and optional 'params' parameters go unexplained in both schema and description, leaving a real gap.

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 ('adopt the recorded row') and a precise scope: 'runs only the steps after the commit to verify it, without submitting again.' It also orients against siblings by naming workflow_save as the predecessor and run_start as the result-shape reference, so the agent can place it in the run_* family.

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 an explicit trigger: 'Call once after workflow_save when the recording really submitted a row,' which is a clear when-to-use condition. The 'without submitting again' clause implies the when-not case (don't use it if the row wasn't actually submitted), but that exclusion is left to inference rather than stated.

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

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

Annotations only give idempotent/destructive/openWorld hints; the description goes well beyond them by spelling out the item-level consequences: never-submitted items become failed (cancelled) so later runs can process their keys, possibly-submitted items route to review, and nothing is ever resubmitted. That is exactly the 'what gets destroyed' context the annotations cannot express.

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 tight sentences, front-loaded with the action and precondition, followed by the state-transition consequences. No filler and every clause carries 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 destructive, no-output-schema operation it covers preconditions and downstream effects well. The remaining gap is the runId source/format, which is the one thing an agent needs before it can actually invoke the 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 0% and the single required runId parameter is undocumented in both schema and description. The description never says what a runId is, where to obtain it (run_list), or what format it takes, so it fails to compensate for the coverage gap.

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 (cancel a run) plus the state precondition (paused or interrupted) and the outcome (permanent stop). It also names the sibling run_resolve as the downstream handler for ambiguous items, which lets an agent separate this from resume/repair 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?

Gives an explicit trigger condition ('when it cannot be repaired'), which is real when-to-use guidance, and points to run_resolve for the review path. It never states the inverse condition (use run_resume when the run is repairable) or when not to cancel, so it stops 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?

Annotations already declare readOnlyHint and openWorldHint=false, so 'Read-only' is somewhat redundant but consistent. Beyond that, the description adds real domain semantics: 'interrupted' means a direct run lost its execution lease, and a running host batch may be awaiting the agent with no lease between calls. That is non-obvious state meaning an agent cannot get from the schema or 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?

Dense and front-loaded — the read-only marker and returned-field list come first, then the resume routing, then the status semantics. Every sentence carries information, though the two status-semantics sentences are tightly packed and could be slightly more scannable.

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

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

With no output schema, the description correctly enumerates the returned columns and the sort order, and it explains the trickiest status value. It stops short of defining 'counts' or the other enum states, but for a read-only listing tool this is close to 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 description coverage is 0% across 3 parameters, so the description carries the burden and only partially compensates: it explains the 'driver (direct or host)' and 'workflow' concepts and the meaning of the 'interrupted' enum value, but says nothing about limit, ordering defaults, or what paused/done/partial/stopped mean.

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 clear verb and resource ('List runs') and immediately enumerates the returned fields (runId, workflow, driver, status, counts, start/end times) plus ordering ('newest first'). It differentiates itself from the run_* siblings by explaining the direct-vs-host driver distinction, though it never contrasts itself with the other list-style tool workflow_list.

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 routes the agent to run_resume for direct runs and host_next for host runs, which is genuinely useful follow-up guidance, but it never says when to call run_list itself or when to filter by status/workflow rather than listing everything. Usage is implied rather than stated.

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 idempotentHint, destructiveHint=false and openWorldHint, but the description adds substantive behavior beyond them: specific state transitions (verified presence→done, verified absence→failed), explicit error/passthrough semantics (errors, missing fields, conflicting records leave review unchanged), and a prerequisite and an exclusion. This is unusually rich behavioral disclosure for a write-adjacent tool.

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

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

The description is compact and front-loads the read/state-transition behavior, with each sentence carrying content. But the extreme terseness and domain-internal vocabulary trade away readability, so it is efficient without being clear.

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

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

With no output schema and 0% parameter coverage, the description must compensate. It does so well on behavior, state outcomes and prerequisites, but leaves the two parameters unexplained, which is a real gap for a tool whose inputs are non-obvious identifiers.

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

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

Schema description coverage is 0%, so the description carries the full burden for the two required parameters (runId, key), yet it never explains what either identifier means or how to obtain it. Only 'one original review item' loosely gestures at 'key'. This leaves the caller guessing at argument semantics.

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 gives a specific verb (Reads) and a resource ('direct run frozen ensure lookup for one original review item'), and the title clarifies the intent as reconciling an uncertain write. However, the heavily idiosyncratic jargon ('frozen ensure lookup') makes the core purpose hard for an agent to parse without domain knowledge. It does name the adjacent tool (run_resume) and what it does not do, which helps distinguish it.

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

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

Usage context is implied rather than explicit: it says errors leave review unchanged and points forward to run_resume, and it notes a prerequisite ('ensure saved before the run') and an unsupported case ('host runs are unsupported'). There is no direct when-to-use-this-vs-run_resolve/run_adopt guidance, so the agent must infer the trigger condition.

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 the annotations by disclosing that the default targets the latest run when runId is omitted, that paths inside the response are relative to dir, and that callers can safely poll during an active run. These are non-obvious traits annotations cannot convey. It doesn't cover pagination edge cases or error behavior, keeping it short of 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?

Four tightly packed sentences, front-loaded with the read-only nature and the core resource, then use cases, then the items/paging behavior. Every clause carries information; nothing is 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 four-param read tool with no output schema and 0% schema coverage, the description supplies the run-id default, the paging contract, the safety profile, and concrete decision scenarios. It could be more explicit about the default value of items (problems vs all) and the maximum page size, but otherwise an agent has enough 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 description coverage is 0%, so the description must compensate and largely does: it explains the runId default (latest run), the meaning of the items enum ('all' pages through everything), and the role of offset/limit together. It stops short of spelling out the default of items='problems' or the limit/offset ranges, leaving a little room on the table.

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 — read status of a run — and immediately enumerates exactly what's returned (counts plus failed, review and paused items with messages and evidence). This lets an agent distinguish it from siblings like run_list and run_resolve without consulting their 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?

Explicitly names three concrete use cases: answering 'how did it go', finding an interrupted run before calling run_resume, and polling a long run from another client. It also says it's safe while a run executes, which is precisely the when-to-use guidance an agent needs to choose it over run_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?

Adds rich behavior beyond the annotations: done causes later runs to skip the row, failed re-submits on resume and can create a duplicate, and hand-resolved items are marked unverified. These downstream consequences flesh out the destructiveHint=true profile with concrete mechanics rather than repeating it.

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 action and the outcome semantics before the confirmation rule. Dense but mostly earning its place, though the trailing sentences about reports marking items unverified and duplicate-held items are somewhat compressed and harder to parse.

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 5-param mutation with no output schema, the description supplies the key decision logic (status effects, confirmation gating, resume consequences) an agent needs. It could still clarify how runId and key are sourced, but it is close to complete 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 coverage is only 20%, so the description must carry the load, and it does for the high-risk params: it defines status semantics (done vs failed) and the confirmChecked gating rule, and explains that note carries evidence. runId and key are left unexplained, so it is not fully compensating.

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 (records a review item's outcome) tied to a clear precondition (once the user checked the destination). This is distinct from siblings like run_reconcile or run_resume, though it never explicitly names an alternative, so it falls short of a 5.

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 to use each outcome: done when the effect exists, failed when it did not, and 'otherwise leave it in review.' It also gives the operational condition for confirmChecked (only after the user confirms, never on your own), so the when/when-not decision is fully covered.

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

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

Annotations only mark it destructive and open-world; the description goes well beyond by disclosing that done items are kept, failed items retried, an item interrupted after commit becomes review 'never replayed blindly', and that host runs are refused 'without altering their journal'. These are exactly the safety/idempotency details an agent needs before invoking a destructive resume.

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?

Four tightly packed sentences, front-loaded with the action and item semantics before the routing guidance. Slightly dense, but every clause carries information an agent needs; little is wasted.

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?

No output schema exists, yet the description points to the return shape ('same bounded result as run_start'), and it covers refusal cases and journal safety. The only real omission is any definition of the runId input, which is minor for a one-parameter resume tool.

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

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

Schema description coverage is 0% and the single runId parameter is undocumented in the schema. The description implies the target is 'an existing direct run' but never defines the runId itself (id format, source, or that it must match a direct rather than host run). Adequate but leaves a gap it should have closed at this coverage level.

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 ('Finishes an existing direct run') and immediately distinguishes it from the host-run path handled by host_next. The item-level outcomes (done kept, failed retried, interrupted-after-commit to review) make the tool's contract 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?

Gives explicit prerequisites ('Read driver in run_report or run_list first'), an explicit exclusion ('host runs require host_next and are refused here'), and a triggering condition ('Use after step_repair or when the user asks to resume'). Nothing is left to inference.

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 openWorldHint and destructiveHint, and the description goes well beyond them: real data is submitted, done rows are skipped, return statuses (done|partial|stopped|needs_repair) are enumerated, and both the needs_repair recovery path and the timeout/busy retry policy (poll run_report, never re-call run_start) 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?

Dense but front-loaded, with the core action first and constraints following. Every sentence carries an instruction or constraint, though the error-handling tail is packed tightly enough that it borders on being a wall of text.

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?

Covers what the tool does, its preconditions, its return shape (status, runId, counts, problem items) despite no output schema, and the downstream recovery flows. 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 coverage is 0%, so the description must carry the load, and it does for all three parameters: workflow is a saved workflow, params should be read with workflow_get, and repeat should only be true on explicit request. It does not describe the string-map shape of params, so a small gap remains.

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 ('Runs a saved workflow on its input rows'), plus scope qualifiers (without an LLM, submits real data to the site). It is clearly distinguishable from siblings like run_resume and run_report, which are named 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?

Explicit when-to-use ('Call only when the user asked to run this workflow'), explicit when-not ('Never use it to diagnose a breakage or to finish an interrupted run'), and names the alternative (run_resume). Adds the repeat:true precondition as an explicit user-request gate.

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 (destructive/idempotent/openWorld=false, which it does not contradict), it discloses real side effects: it publishes a new workflow version when the workflow is otherwise unchanged, it returns the previous and new target, and it imposes an extra gate (confirmCommitTarget: true) for the commit step. That is material context an agent cannot get from annotations alone.

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?

Dense but front-loaded: the core mutation and its scope come first, then prerequisites, then the return value and the commit-step caveat. No filler sentences, though the second sentence chains three clauses and could be split for readability.

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?

No output schema exists, yet the description states what is returned (previous and new target). For a destructive, nested-object mutation tool it covers scope, prerequisites, sequencing, side effects (new workflow version), and the special commit-step flag — everything needed 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 description coverage is only 40%, and the description compensates for the two most ambiguous parameters: runId's default behavior ('latest run of the workflow if no runId') and confirmCommitTarget's purpose. It also defines the target shape by reference ('As in workflow_save'). workflow and stepId are still left unexplained, so it does not fully close the gap.

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 precise verb and resource ('replaces the target of the paused step of that run') and scopes it against siblings by explicitly excluding what it does not touch ('never its action order or submission boundary'). An agent can distinguish this from workflow_save, browser_act and run_resume without opening any 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 the trigger condition ('After needs_repair'), the prerequisite ('Get verified selectors first with browser_act inspect on the live page, in the same session'), the follow-up call ('then call run_resume'), and the fallback rule for runId. When-to-use and what-to-do-around-it are fully specified.

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 carry readOnlyHint/openWorldHint, so the leading 'Read-only.' is largely redundant. The description still adds real value beyond the annotations by disclosing the shape of the returned payload (params, items source, steps, targets), which the agent needs to know before calling.

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 compact sentences, safety hint front-loaded, and the payload enumeration and precondition packed into the second. No wasted words, though the 'Read-only.' fragment duplicates 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?

With no output schema, the description appropriately enumerates returned fields and gives the pre-run_start prerequisite. It omits failure behavior (e.g., unknown workflow name), which is a minor gap for a simple read tool.

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

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

Schema description coverage is 0% for the single required 'name' parameter, so the description is the only place meaning could be added. It never states that 'name' is the workflow identifier, though the phrase 'a saved workflow' implies it weakly; a single obvious param keeps this near baseline rather than a failure.

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 ('a saved workflow in full') and enumerates what is retrieved (params, items source, steps, targets), which separates it from the sibling workflow_list. It doesn't explicitly name a sibling to contrast with, so it falls just short of a 5.

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 routes usage by stating the read is for obtaining params so the caller can 'ask the user for missing required ones before run_start' — a clear precondition tied to a named sibling. There is no explicit when-not-to-use or contrast with workflow_list, but the context is concrete.

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 and openWorldHint=false, so 'Read-only.' adds no new information. The description does disclose the returned shape (name, version, description), which helps in the absence of an output schema, but says nothing about ordering, empty results, or whether the list is scoped or unbounded.

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?

Very short and front-loaded: purpose, return fields, then the trigger condition. The 'Read-only.' fragment largely restates the annotation and is the one piece that does not fully 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?

Zero-parameter read tool with no output schema; the description covers what is returned and when to reach for it. 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?

The tool takes no parameters, so the baseline of 4 applies. Schema coverage is 100% and there is nothing for the description to clarify parametrically.

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 the resource (saved workflows) and the fields surfaced (name, version, description), so an agent knows this is an enumeration of stored workflows. It does not explicitly distinguish itself from the sibling workflow_get, leaving the singular-vs-list split to be inferred from the names.

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 an explicit entry condition — 'Start here when the user refers to a previous browser task' — with two concrete examples ('like last time', 'the September export'). No when-not condition or named alternative (e.g. workflow_get for a single known workflow) is provided.

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 declare destructiveHint=false, but the description says the tool 'clears the recording,' which is a destructive side effect on the current recording data. This directly contradicts the annotation, so per the rubric the score is 1 despite the otherwise rich return and validation 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?

The description front-loads the core purpose and return behavior, which is good. However, the remaining DSL documentation is a single dense paragraph with little structural separation, making it hard to parse even though much of the content is necessary given the empty nested 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?

Given the complex workflow DSL, a placeholder input schema, and no output schema, the description is exceptionally complete. It covers validation, return values, error shape, side effects, step types, selectors, credentials, and execution limits.

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 is only a generic object with no nested parameter documentation, but the description defines the entire workflow JSON shape: params, items, servers, setup/item/teardown steps, selector variants, credential handling, ref:agent behavior, timeouts, and HTTP/MCP step details. This adds extensive semantic meaning far beyond the schema.

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

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

The description states a specific verb and resource: validates and saves a workflow as a new version, then clears the recording. It also distinguishes the tool from workflow_get by noting that workflow_get shows a saved example. An agent can identify the core operation without opening the tool 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?

The description does not state when to use this tool versus alternatives, nor does it give prerequisites or when-not-to-use guidance. The only sibling reference is 'workflow_get shows a saved example,' which is contextual but not actionable usage guidance.

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