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

Annotations already provide destructiveHint=true and openWorldHint=true, so the mutation risk is flagged. The description adds value beyond that by promising that the tool always reports what actually changed and says so plainly when nothing did, and by enumerating the side-effecting actions it performs. This is useful behavioral context rather than a contradiction.

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

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

Three tight sentences cover the action set, targeting strategy, and output reporting behavior. Every sentence earns its place; there is no filler or repetition of schema details.

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 7-parameter, 10-action tool with no output schema, the description covers the action set, target syntax, and reporting promise. Operational details like session_id and max_tokens are handled by the schema. The return format is only vaguely described, but the honesty guarantee compensates enough for a tool of this complexity.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description adds only light enrichment, such as mentioning @eN references from steel_snapshot/steel_find and cookie/consent overlays. Since the schema carries the parameter burden, a 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 names a concrete set of interactions—click, type, fill a form, select, hover, scroll, press, go back, dismiss overlays—and ties them to a specific resource: the current page. It also distinguishes itself from siblings like steel_navigate and steel_snapshot by making clear this is the general page-interaction tool.

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 usage context: target elements by @eN references from steel_snapshot or steel_find, or by CSS selector. This implies the prerequisite of running snapshot/find first and orients the agent to the correct workflow. It does not explicitly state when not to use the tool or name alternatives, but the usage situation is still 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?

Annotations already declare destructiveHint and openWorldHint, but the description goes further by disclosing that execution stops on failure or login/challenge, the session is handed off, and only unrun steps should be resumed. It also warns against including payment or final confirmation steps. This adds meaningful behavioral context 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 three sentences with no wasted words. The first sentence front-loads the core usage condition, the second explains failure behavior, and the third gives a safety boundary. Every sentence earns its place.

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

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

For a batch tool with no output schema, the description covers the essential selection criteria, failure behavior, and safety constraints. It does not describe the return shape or how results from completed steps are surfaced, which is a minor gap, but the critical invocation decisions are well supported.

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

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

Schema description coverage is 100%, so the schema already documents the session_id, steps, max_tokens, and include_snapshot parameters. The description does not add parameter-specific syntax or format details, which is acceptable given full schema coverage. It provides general behavioral guidance but not deeper parameter 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 clearly states the tool runs multiple known reversible browser steps as a batch, which distinguishes it from the single-step sibling tools like steel_navigate, steel_act, and steel_wait_for. The title reinforces this by saying 'Run several browser steps at once.' It does not name a sibling explicitly, but the scope and specificity are strong enough to identify the tool's purpose.

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 concrete inclusion criterion: use for known reversible steps whose later targets do not need a fresh read. It also gives exclusions by warning to stop before payment/final confirmation and noting the batch stops on login/challenge. It does not explicitly name an alternative tool, so it falls just short of fully explicit routing.

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 read-only and open-world behavior. The description adds useful context by noting that only labelled elements are matched, that regex matching is safe, and that the result is @eN refs. It does not disclose truncation or cursor continuation behavior, but the schema covers those details and the safety profile is already established by 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?

A single front-loaded sentence states the action, the matching methods, and the return type with no filler. Every phrase earns its place.

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

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

For a tool with eight parameters and no output schema, the description provides the essential return concept (@eN refs) and the matching criteria. Combined with the fully described schema and read-only annotations, this is nearly complete; only explicit sibling differentiation and pagination caveats are 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 because the schema already documents all eight parameters. The description adds a high-level grouping of search modes (text, regex, role) but no new semantic 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?

The description uses a specific verb ('Find'), a concrete resource ('labelled elements'), and explicit search criteria (text, safe regex, role), plus the return type (@eN refs). This clearly differentiates it from sibling tools like steel_snapshot or steel_scrape, which retrieve page content rather than locate specific elements.

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 intended use is reasonably clear: call this when you need element references by label. However, it never explicitly states when to prefer it over alternatives such as steel_snapshot or steel_wait_for, nor does it provide any exclusions. Usage is implied rather than directly guided.

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 annotations, the description discloses that the tool waits for the page to settle, reports the final URL and changes, and that the snapshot is off by default because it is expensive. These are meaningful behavioral details. It does not contradict the openWorldHint or destructiveHint 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?

Two concise sentences front-load the core behavior and then add the key option. Every clause earns its place with no repetition of schema details.

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 navigation tool with no output schema, the description covers the main behavioral contract: navigating, waiting, reporting URL and changes, and the snapshot option. It does not fully describe the shape of the returned changes, but with annotations covering safety and 100% parameter schema coverage, the gaps are acceptable.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining include_snapshot ('also read the page', 'expensive') and by clarifying what navigation returns ('reports the final URL and changes'), which gives context to the url and session_id parameters.

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

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

The description clearly states the action: 'Navigate a live session and wait for it to settle.' The title 'Open a URL in a browser session' reinforces the resource and action. It does not explicitly compare against sibling tools like steel_scrape or steel_act, so it misses full 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?

The description implies when to use it: to navigate a live session and wait for it to settle, with include_snapshot when page content is needed. However, it offers no explicit exclusions or alternatives among siblings, such as 'use steel_scrape for extraction' or 'use steel_act for actions.'

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

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

Beyond the read-only, idempotent, and open-world annotations, the description adds two useful behaviors: it starts no browser session and it returns a link rather than inline content. It does not contradict the annotations, so credit is given for the extra context.

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 succinct sentences front-load the core purpose and return format, then give the alternative and use case. There is no filler or repetition; every sentence earns its place.

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

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

For a simple three-parameter tool with a full schema and safety annotations, the description covers purpose, return format, session behavior, and the key sibling alternative. No output schema exists, but the description explicitly states the return value, so 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?

Schema description coverage is 100%, so the schema already explains url, delay_ms, and use_proxy. The description adds no parameter-level detail, but the baseline of 3 applies because the schema carries the full burden and the description doesn't need to compensate.

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 ('Render') and resource ('a page to PDF') and states the deliverable ('return a link to the file'). It also distinguishes itself from steel_scrape by noting the PDF is for handing a document to a person, so an agent can tell it apart from the most similar 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 explicitly routes the agent: use steel_scrape when the goal is to read the text, and use steel_pdf when the goal is to produce a document for a person. This is clear when-to-use guidance with a named alternative, leaving little 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 already declare readOnlyHint, openWorldHint, and idempotentHint, and the description contradicts none of them. Beyond that, it adds three substantive behavioral facts: the tool runs a real browser so JS rendering works, it starts no browser session so there is nothing to release, and it always returns page links and metadata alongside content. This is solid context beyond the annotations, though it stops short of disclosing failure behavior 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?

Four sentences with zero waste: purpose and capability, session lifecycle, return-value behavior, and usage routing each get one sentence. The core action is front-loaded in the first line, and every sentence earns its place.

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

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

For a tool with one required parameter, a fully covered schema, and rich annotations, the description covers selection criteria, session handling, and return basics. Since there is no output schema, the return structure is only sketched as 'links and metadata,' but the combination of a 100%-covered schema, strong annotations, and this description leaves no critical gap for correct selection and 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 description coverage is 100%, so all six parameters are already fully documented in the schema. The description adds only marginal parameter-level meaning (markdown/HTML correspond to the format parameter, and 'no browser session' explains why no session parameter exists). Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description opens with a specific action — 'Read a web page as markdown or HTML through a real browser' — and adds distinguishing capability detail: it handles JavaScript-rendered pages and sites that block plain HTTP fetches. An agent can clearly tell this apart from steel_screenshot, steel_pdf, and steel_session_create without opening 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?

The last sentence is an explicit routing directive: 'Use this first for anything you only need to read; reach for steel_session_create only when you need to click, type or move through several pages.' It names the alternative tool and the exact condition that selects it, leaving nothing 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 already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds behavioral context beyond annotations: output artifact formats (PNG vs JPEG) and the non-interactive nature of pixels. It does not contradict 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 with no filler. The core action is front-loaded, artifact distinctions follow, and the sibling-routing caveat is placed last. Every sentence earns its place and nothing repeats schema content.

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 100% schema coverage and read-only/idempotent annotations, the description covers the key disambiguation from steel_snapshot and the two capture modes. It does not explain what happens when neither url nor session_id is provided, but the optional parameter schema and mode descriptions give sufficient guidance for a competent agent.

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

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

Schema descriptions cover all 5 parameters, so the baseline is 3. The description adds mode-level meaning that helps select between url and session_id by specifying output format and audience. It does not re-explain full_page or use_proxy, but those are already well documented 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 description opens with a specific verb and resource: 'Capture a page image.' It further distinguishes URL captures and session captures by artifact type, and differentiates the tool from steel_snapshot by noting that pixels are not action targets. This makes the tool's purpose unambiguous relative to siblings.

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

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

The description explicitly tells agents when not to use this tool: 'Pixels are not action targets, so use steel_snapshot to click or type.' It also provides mode-selection guidance by contrasting user-facing PNG URL captures with model-visible JPEG session captures. This gives clear routing versus the main sibling alternative.

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 only openWorldHint/destructiveHint annotations, the description adds meaningful behavioral context: the operation is billed, and the created session must be released, which suggests a chargeable, long-lived resource. It doesn't go into consequences, but it reveals cost and lifecycle 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 definition is extremely short, but it is under-specified rather than economically structured; the fragments are not front-loaded with the core purpose and read as disconnected warnings rather than a purposeful summary.

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 10-parameter, billed, destructive-flagged creator with no output schema, the description omits crucial context: what the call returns (e.g., session id), how billing is triggered, what 'release' implies, and any setup prerequisites. The cost/lifecycle hints are useful but far from 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 100%, so the schema already documents all 10 parameters. The prose description adds no parameter-level detail; 'profiles/credentials via session_options' is a routing hint, not semantics for any specific parameter. 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 never states the core action; it is a fragment list ('Billed; profiles/credentials via session_options; release.') that forces the agent to infer 'create session' from the name/title. It also doesn't differentiate this creator from siblings like steel_session_live_view beyond the title.

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 fragments imply some usage boundaries: credentials/profiles should go through steel_session_options, and the caller should later release the session. However, there is no explicit when-to-use, prerequisites, or exclusion guidance for the other sibling tools.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces safety with 'Read' and 'never starts a browser.' It adds a useful behavioral boundary that is not fully captured by the annotations alone: no browser is launched during invocation.

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?

One short sentence delivers the core action, the scope, and a key exclusion. Every word earns its place, and the most important behavior is front-loaded.

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

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

For a read-only diagnostics tool with no required parameters, the description plus annotations provide enough context for selection and safe invocation. A bit more detail about what 'activity' includes or how output is returned would help, but the absence is not critical given the schema and annotations.

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 parameters are fully documented there. The description's 'live/released activity' and 'list live handles' loosely map to session_id, steel_session_id, and list_live, but it adds no parameter-level detail beyond what the schema already provides.

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 operation and resource: 'Read live/released activity or list live handles.' It also distinguishes itself from sibling tools by adding 'never starts a browser,' which separates it from session-creating or browser-acting 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?

The description clearly indicates this tool is for reading diagnostics or listing live handles, not for launching a browser. However, it does not explicitly name siblings like steel_session_live_view or steel_session_replay, leaving some routing to the agent's 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?

The description adds behavior not visible in annotations: the tool pauses the current flow, grants exclusive human control, and resumes only after hand-back. This goes beyond the destructiveHint/openWorldHint annotations to explain the handoff lifecycle.

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

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

Two sentences with no filler; the core behavior is front-loaded and the usage guidance follows immediately. Every phrase earns its place.

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

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

For a two-parameter handoff tool with annotations covering safety, the description fully explains what happens, when to use it, and how the handoff is resolved. No output schema is needed because the behavior is the primary contract.

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 already documents both parameters. The description still adds value by mapping the reason enum to concrete scenarios (sensitive input, local files, review, or any manual step), which helps an agent choose the correct value.

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

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

Description states a clear action—'Pause for a person to take exclusive control of this same live browser'—and the title reinforces the handoff behavior. It is easily distinguished from sibling session/automation tools, which all operate under agent control.

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

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

The description explicitly lists when to use it: 'sensitive input, local files, review, or any manual step.' It doesn't explicitly state when not to use it or name alternatives, but the use-case list is sufficient guidance for an agent.

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 openWorldHint and destructiveHint, so the description does not need to restate those. It adds a little context with 'app-only' and 'no page content,' but it does not disclose the lease lifecycle, side effects of release, or what happens to a control lease across actions. There is no contradiction with 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 very short and contains no filler, but it is under-specified to the point of being a cryptic fragment. It front-loads no actionable instruction and leaves the agent to infer meaning from the title and schema, which is not effective conciseness.

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

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

For a three-parameter control tool with no output schema, destructive and open-world annotations, and many related session siblings, this description is insufficient. The only substantive guidance comes from the session_id schema description; the agent still lacks action semantics, token requirements, and selection criteria.

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 33%: only session_id has a description, while action and control_token are undocumented. The description's word 'lease' loosely relates to the action enum, but it does not explain connect, acquire, renew, or release semantics, nor does it clarify what control_token is or when it is needed.

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 communicates that this tool is about an app-only viewer/control lease and explicitly notes 'no page content,' which gives some domain context. However, it is phrased as a noun fragment rather than a clear verb+resource statement, and it does not distinguish this tool from siblings like steel_session_create, steel_session_release, or steel_session_handoff.

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 offers no guidance on when to use this tool versus its siblings. 'No page content' hints at an exclusion, but there are no explicit conditions, alternatives, or when-not-to-use signals, leaving an agent to guess whether live_view is appropriate relative to session_create, session_release, or handoff.

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=true, so the safety profile is covered. The description adds minimal behavioral context consistent with read-only behavior (finding profiles/credentials and planning), but it does not disclose what the plan contains, whether live network checks are performed, or what the output looks like. It does not contradict 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?

At six words, the description is under-specified rather than genuinely concise. 'Find profiles/credentials; plan setup' reads like a note-to-self and fails to earn its place as a functional tool definition—there is no front-loaded verb-object statement of effect, no scope, and no return behavior.

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 6 parameters, no output schema, and complex inter-parameter constraints (needs enums with exclusion logic), this description is far too thin. An agent cannot determine what the tool returns, how the goal enum affects the plan, or how this differs from other session tools. The cryptic schema notes are not compensated for by the description.

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 of 3 applies. The description itself adds nothing about parameters like needs, cursor, country, or minutes, and the schema's own descriptions are cryptic (e.g., goal is just 'Mode'; needs uses terse constraint strings like 'protected_text=read'), but per the rubric the high schema coverage keeps this at baseline.

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 offers a concrete verb+resource in 'Find profiles/credentials' but 'plan setup' is vague and largely restates the title 'Plan session.' It hints at a discovery/planning operation but never states what the tool actually returns or does with the found profiles/credentials, and it does not clearly distinguish itself from siblings like steel_session_create or steel_find.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention steel_session_create, steel_find, or any sibling, nor any condition such as 'call before creating a session.' An agent is left to infer the intended workflow entirely from the tool name and terse fragments.

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

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

The description adds substantial behavioral detail beyond the annotations: it reports idempotency ('Safe to call twice'), destructive effects ('current URL and session-only page state are gone'), persistence rules, and return value ('reports the final URL and title'). This fully discloses the side effects and consequences of calling the 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 concise, front-loaded with the primary action ('Shut down the current browser and stop the meter'), then covers safety, side effects, persistence, and return behavior in four short sentences. Every sentence adds meaningful information without 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 low-complexity tool with one parameter and no output schema, the description is complete: it covers the destructive nature, idempotency, persistence behavior, return value, and usage timing. Nothing needed for correct invocation or expectation-setting is omitted.

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

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

The input schema already provides 100% coverage for the single parameter, including 'Live session_id from steel_session_create.' The description does not need to add parameter-level detail, and it does not. Baseline score of 3 is appropriate because the description adds no additional parameter semantics beyond what the schema already documents.

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

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

The description clearly states the tool's function: 'Shut down the current browser and stop the meter.' This is a specific verb + resource combination that makes the core purpose obvious. It does not explicitly name sibling tools for differentiation, but the terminating nature is distinct enough from the listed siblings.

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

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

The description gives clear usage context: 'Read what you need first' signals that this should be called after data extraction is complete. It also notes the persistence caveat ('A profile is saved only when persistence was requested'), which informs the user whether they can expect preserved state. It does not explicitly contrast with alternatives like handoff or replay, but the when-to-use guidance 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?

Annotations already carry the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower, and the description adds genuinely valuable behavioral context beyond them: it clarifies the tool returns a dashboard link and does NOT start a browser, correcting the natural but wrong assumption that 'replay' spawns a browser session. No contradiction with 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?

Two sentences, zero fluff, and the most decision-critical information (usage condition) is front-loaded. Every clause earns its place: the trigger, the behavioral clarification, the return value, and the sibling routing.

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 of this complexity — one optional parameter, full schema coverage, strong annotations, simple return value — nothing an agent needs is missing. It covers when to call, what happens (no browser), what comes back (dashboard link), and where to go for the related task, despite having no output schema to lean on.

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 (steel_session_id with UUID pattern and 'Finished Steel UUID; omit for latest released') is fully documented in the schema. The description adds no parameter-level detail, which is appropriate — baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource ('watch or replay a finished session') and a concrete outcome ('Returns its Steel dashboard link without starting a browser'). Explicitly differentiates from sibling steel_session_diagnostics, and the contrast with steel_session_live_view (finished vs. live) is evident from context.

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, restrictive trigger ('Call only when the user explicitly asks to watch or replay a finished session') and names the alternative tool for the neighboring case ('use steel_session_diagnostics to inspect or explain activity'). An agent needs zero inference to decide when to invoke this.

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 cover the read-only safety profile and open-world scope, so the bar is lower. The description adds genuine value: the compact-tree output format, the critical behavioral rule that unreferenced elements cannot be targeted, and a cost/performance comparison ('much cheaper'). Truncation/pagination behavior is left to the schema's cursor parameter, but this is a minor gap.

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 short sentences with zero filler. The core function is front-loaded first, followed by usage timing, the targeting constraint, and the cheaper alternative. Every sentence earns its place.

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

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

For a read-only tool with full annotation coverage, 100% schema description coverage, and no output schema, the description is complete: it explains what is returned, when to call it, what the references mean operationally, and when to prefer a sibling. 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 all four parameters (cursor, max_tokens, session_id, interactive_only) are already documented in the schema. The description does not add parameter-specific detail, so the baseline 3 applies — the schema carries the load and does so 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?

States a specific verb and resource: 'Return the page as a compact accessibility tree with a @eN reference on every element you can click or type into.' The distinctive @eN reference format makes the output immediately recognizable, and the mention of steel_find as an alternative helps differentiate it from at least one 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?

Provides explicit when-to-use guidance ('This is the read to use before acting'), a hard constraint that shapes usage ('Elements with no reference cannot be targeted'), and names the alternative with the condition that selects it ('If you already know what you are looking for, steel_find is much cheaper').

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 conveys the core waiting behavior and clarifies that conditions are alternatives. Annotations already mark the tool as read-only and open-world, so the safety profile is covered. It does not disclose timeout failure behavior, polling semantics, or what happens if multiple conditions are passed, but for a simple wait operation the stated behavior is reasonably transparent.

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 one compact sentence with no wasted words. It front-loads the action and immediately enumerates the supported condition types, followed by the key invocation constraint.

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 core invocation details are covered by the schema and the at-least-one note. However, there is no output schema and the description does not explain what happens on timeout or what a successful wait returns, which an agent may need to know for robust usage.

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%, but the description adds meaningful parameter semantics by mapping 'named text', 'CSS selector', and 'URL substring' to the optional text, selector, and url fields. It also adds the at-least-one constraint, which the schema does not enforce.

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

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

The description uses a specific verb and resource: wait for page conditions including text, CSS selector, or URL substring. This avoids tautology and gives an agent a clear sense of what the tool does, though it does not explicitly contrast with sibling tools like steel_find or steel_snapshot.

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

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

The phrase 'Wait for...' implies the tool should be used when a page condition must be awaited, and 'pass at least one' gives a necessary precondition. However, it does not provide explicit guidance on when to choose this tool over alternatives or when not to use it.

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