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

Annotations are sparse, so the description carries the burden and succeeds. It discloses that the operation does not add a new history entry, becomes a no-op at the first entry, returns an error on navigation failure while preserving the history index, and reuses/creates the default session when session_id is omitted. This goes well 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?

Three dense sentences deliver all essential information with no filler. The main purpose is front-loaded, and each sentence earns its place by clarifying scope, edge behavior, and error handling.

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 one-optional-parameter tool with an output schema, the description covers the necessary behavioral, error, and session semantics. 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 100% for the single session_id parameter, but the description adds meaningful behavior: omitting session_id reuses or creates the active/default session, and the first sentence notes 'active or named browser session.' This extra context pushes it above 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 clearly states the operation: 'Loads the previous history entry in the active or named browser session' with the key nuance 'without adding a new history entry.' It explicitly differentiates from browser_navigate, and the name plus context make the distinction from browser_forward obvious.

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 usage directive: 'Use it for history traversal rather than browser_navigate.' It also covers edge conditions (no-op at first entry), behavior on failure, and session fallback semantics, providing enough guidance for an agent to choose this tool appropriately.

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

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

Beyond the annotations, the description adds meaningful behavioral constraints: POST is refused, password fields are blocked to prevent credential leakage, and errors are bounded without bypassing navigation controls. This gives agents important safety context beyond the structured annotation 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?

Three compact sentences deliver purpose, restrictions, safety rationale, and outcome with no filler. The most important scoping information 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?

Given the simple two-parameter schema, the output schema, and annotations, the description covers what the tool does, what it refuses, why it refuses it, and what it returns. No critical contextual gap remains.

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 both parameters. The description reinforces that element_id targets links or submit controls, but it does not add substantive new semantics 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 clearly states the specific action: activating an href-bearing link or submitting a GET form via normal browser navigation. It gives a concrete verb and target, though it does not explicitly contrast itself with sibling tools like browser_navigate.

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 specifies when the tool applies (links and GET forms) and explicitly excludes POST/other methods and password-containing GET forms. It provides clear conditions but does not name alternative sibling tools for divergent cases.

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

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

The description adds significant behavioral context beyond the destructiveHint=true annotation: it specifies that the session is permanently discarded, history is removed, but persistent cookies remain saved. It also discloses the return values ('closed', 'not_found') and guarantees no effect on other sessions, which is useful for the 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?

Three sentences, each earning its place: action, usage, and parameter behavior. The most critical information (destructive action) is front-loaded, and there is no redundancy or fluff.

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

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

The description fully covers what the agent needs: the action, its effects (including cookies and history), parameter behavior, and return values. The output schema exists for additional detail, but nothing critical is missing. The tool is simple, and the description is 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 description coverage is 100% (session_id is described as 'Optional browser tab/session identifier'), but the description adds meaningful clarification: 'targets a specific session; if omitted, the active session is closed.' This explains the default behavior and parameter semantics 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+resource: 'Closes and permanently discards one in-memory browser session', which clearly distinguishes it from siblings like browser_open or browser_navigate. The scope is precise (one session, including document and history), leaving no ambiguity about what the tool does.

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

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

Provides a clear usage condition: 'Use it when that tab is no longer needed.' It also explains the optional session_id behavior, which helps the agent decide whether to pass it. It doesn't explicitly name alternatives, but the operation is simple and the context of siblings (all navigation/control) makes the intended use obvious.

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

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

The description goes beyond annotations by detailing that it does not add a history entry, is a no-op if no forward entry exists, returns an error on navigation failure while preserving the history index, and clarifies session_id omission behavior. These are valuable behavioral traits not covered 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?

The description is concise yet information-dense, with logical flow: primary action, usage guidance, edge cases, and parameter nuance. Every sentence adds value 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?

Given the tool's simplicity and the presence of an output schema, the description covers all necessary aspects: behavior, usage, error handling, and session semantics. No critical information is missing 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?

Although the schema already documents session_id as optional, the description adds the important semantic that omitting it reuses or creates the active/default session, giving agents the context needed for correct invocation.

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: loads the next history entry in a session without adding a new entry. It also differentiates from browser_navigate by specifying usage after browser_back, making its purpose distinct among siblings.

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

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

Explicitly directs the agent to use it after browser_back rather than browser_navigate, and describes the no-op behavior when no forward entry exists. This provides clear when-to-use guidance and an 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?

Annotations only mark safety traits; the description adds substantive behavior: active-session reuse or default session creation, the exact data returned, and the guarantee that failures return an error without changing committed page state. This is beyond what annotations provide and does not contradict them.

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

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

Two sentences front-load the core navigation action, then add usage routing and failure behavior without redundancy. Every clause 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 3-parameter tool with an output schema, the description covers invocation context, behavior, return contents, and error semantics. Nothing an agent needs to call 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 100%, so the schema carries the parameter basics. The description adds value for session_id by defining what happens when it is omitted, and it confirms url and timeout semantics in context. This justifies moving above the baseline 3.

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

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

The description opens with a specific verb and resource ('Loads `url` into an existing browser session') and explains the document-replacing, history-adding effect. It also names the sibling alternative (browser_open), so an agent can distinguish navigation from opening a session.

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

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

It explicitly states when to choose this over browser_open ('continuing in a known session') and explains fallback behavior when session_id is omitted. It also covers timeout and failure conditions, giving clear context for invocation.

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 no annotations, the description carries the burden and does add useful behavioral context: persistent local logins/profile and a 20 MB RAM ceiling. It does not disclose tab/session side effects, failure modes, or timeout behavior, so transparency is partial but not absent.

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 dense sentences with no filler. The primary action and the most decision-relevant constraints are front-loaded, and every word earns its place.

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

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

The schema covers parameters and the description provides the key operational constraints, so basic invocation is supported. However, without annotations or an output schema, and without explicit sibling differentiation, the description leaves return behavior and tool-selection context incomplete.

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. The description adds no parameter-level detail, but the schema already fully documents url, timeout, and session_id.

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 ('Opens a URL') and the resource ('stealth agent browser'), and adds differentiating context about persistent local logins/profile and a RAM ceiling. It doesn't explicitly name a sibling tool to distinguish itself from, but the core purpose 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?

The description implies usage contexts: use when persistent logins/profile are needed or when targeting local dev servers. However, it gives no explicit when-not-to-use guidance and doesn't reference alternatives like browser_navigate, leaving the routing decision partially 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?

No annotations are provided, so the description carries the full burden for disclosing side effects. It fails to mention that pressing Enter on a link may navigate away or trigger forms, or that the tool might alter page state. Given it can 'edit' and 'activate', it should warn about potential navigation or state changes.

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

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

The description is a single, front-loaded sentence with no wasted words. It conveys the core functionality immediately and is appropriately concise for a simple key-press tool.

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

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

The tool is simple with one required parameter, and the schema covers parameter details. However, the description lacks essential behavioral caveats like potential navigation or side effects when activating links, which is a notable gap given the absence of annotations. It is adequate but not fully complete for safe 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% for all three parameters, providing baseline 3. The description adds semantic meaning by explaining that specific keys (Enter, Tab) have specific effects (activate links, move focus), which enhances the agent's understanding of how the key parameter behaves beyond the schema's simple example.

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 three distinct actions: editing text controls, moving focus with Tab, and activating links with Enter. This gives a specific verb-resource pair and differentiates it from siblings like browser_click and browser_type without ambiguity.

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

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

The description provides clear use cases for pressing keys, such as editing, tabbing, and activating links. However, it does not explicitly state when to use this tool versus alternatives like browser_type or browser_click, so the agent must infer the appropriate context from the action 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states the core action but does not mention potential side effects like losing unsaved page state or re-submitting requests, nor does it clarify behavior with multiple sessions. This is adequate but thin.

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 focused sentence with no filler. The action is front-loaded and the scoping phrase 'in the browser session' earns its place by connecting to the sibling tool set.

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 one-parameter optional tool, this is nearly sufficient. However, with no annotations and no output schema, it leaves unclear whether an active session is required, what happens if session_id is omitted, and what the tool returns after reloading.

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

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

The schema already documents the single optional session_id parameter at 100% coverage, so the baseline is 3. The description adds no additional format, default, or fallback semantics beyond what the schema 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 uses a specific verb ('Reloads') and identifies the resource ('current page in the browser session'). This unambiguously distinguishes it from sibling navigation tools like browser_navigate, browser_back, and browser_forward, even without naming them.

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

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

There is no guidance about when to use reload versus navigating to a URL, going back, or going forward. It also does not mention prerequisites such as an active session or when reload would be inappropriate. The intended usage must be inferred.

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 mark this as read-only and non-destructive, and the description adds useful behavioral guarantees: no navigation/scroll side effects, a fixed 1280x800 image, and a single-layer return value. It does not cover things like rate limits, but those are not material here.

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

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

Three sentences with no filler; the primary behavior and key limitation are front-loaded, the sibling comparison follows, and the default-parameter behavior closes the only remaining ambiguity.

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 only one optional parameter, an output schema present, and annotations describing safety, the description covers all necessary selection and invocation guidance. The agent knows exactly what will happen, what it will get back, and which tool to choose instead for broader coverage.

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

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

The schema fully documents session_id as an optional identifier, and the description adds the important default behavior (omitted session_id targets the active/default session). This exceeds the baseline because it resolves the main semantic question an agent would have.

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 precise action ('Captures one 1280x800 PNG'), a specific resource ('current viewport'), and an explicit constraint ('without navigation or scroll changes'). It also distinguishes itself from the sibling browser_snapshot_layers, so an agent can identify the correct tool immediately.

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 explicitly says to use this for the visible region and to use browser_snapshot_layers for multi-viewport coverage, and it clarifies the default behavior when session_id is omitted. This gives clear selection criteria without leaving alternatives 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the mechanical action and gives no indication of side effects, whether it is read-only, or what happens if the page is not scrollable. It also does not mention that scrolling is relative to the current position. This is a notable gap for an action without annotation support.

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

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

The description is a single focused sentence with no fluff. It front-loads the action and unit, and the key parameter meaning is conveyed immediately. It is appropriately concise for the simplicity of the tool.

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

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

The description is minimal but acceptable for a simple, two-parameter tool. It covers the core 'do what' but omits behavioral transparency and usage context, which are important given no annotations and no output schema. The absence of any guidance about when to use this tool versus sibling tools leaves the description incomplete in a broader operational context.

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. The description mentions 'delta pixels,' which aligns with delta_y and clarifies the unit, adding a small amount of semantic value beyond the schema. It does not describe the direction convention (positive vs. negative), which is left to the parameter description.

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

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

The description clearly states the action: 'Scrolls the page vertically by delta pixels.' It uses a specific verb, resource (page), and unit (pixels), making it easily distinguishable from sibling tools like browser_navigate or browser_click. The tool's purpose is unambiguous even without referencing 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 implies usage: scroll when you need to move the viewport vertically. However, it provides no explicit guidance on when to choose scroll over alternative navigation tools, and it does not mention any prerequisites like a loaded page or session context. This leaves some inference burden to the 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 readOnlyHint=true and destructiveHint=false. The description adds valuable traits beyond those: it captures from the top, uses a fixed 1280x800 viewport per layer, avoids changing session scroll position, and lists the returned data shape. This is rich behavioral context for an agent deciding whether invocation has side effects.

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

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

Three sentences with no filler. The first explains how the tool operates, the second gives usage routing, and the third covers defaults and return values. Information is front-loaded 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?

With only two optional parameters, 100% schema coverage, rich annotations, and an output schema present, the description supplies all necessary behavioral and selection context. An agent can confidently decide when to invoke it and what to expect.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining that an omitted session_id targets the active/default session and that max_layers defaults to 3 and is capped at 10, which is not fully specified 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 names a specific action ('Captures'), a precise resource ('layers of the current document'), and the operational details (1280x800 viewport per layer, from the top). It explicitly differentiates itself from browser_screenshot, so an agent can disambiguate without opening schemas.

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

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

It states exactly when to use this tool ('multi-viewport page coverage') and names the alternative ('browser_screenshot for only the current viewport'). It also clarifies the behavior of an omitted session_id, giving complete selection 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?

Discloses error behavior for missing or non-editable elements (returns an error object and does not change them), confirms no form submission, and describes the return payload (status 'typed', element ID, supplied text). This goes well beyond the sparse 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 pack the main effect, alternative usage, session default, return value, and error behavior with zero filler, front-loading the core action.

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

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

The description covers selection, invocation, session handling, and success/failure results. Sibling differentiation and output schema remove remaining ambiguity.

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?

Despite 100% schema coverage, the description adds meaning: 'full value' and 'text-like input or textarea' clarify text/element_id semantics, and the session_id default behavior is specified.

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+resource: replaces the full value of a text-like input or textarea identified by element_id. Explicitly notes that it does not submit the form, distinguishing it from activation and navigation 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?

Names browser_press as the alternative for single-key edits or activation, giving an agent actionable routing criteria. Also clarifies that an omitted session_id targets the active/default session.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It states the core behavior but does not mention blocking semantics, session-scoped behavior, or what happens with edge values such as 0 or 10 seconds. As a simple, non-destructive wait operation, the minimal disclosure is acceptable but not rich.

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

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

The description is a single front-loaded sentence with zero wasted words. It states the action and the unit of measurement, which is all that is needed for a tool of this simplicity.

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

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

Given the tool's low complexity, a two-parameter schema with full descriptions, and the absence of an output schema, the description is nearly sufficient for an agent to call the tool correctly. It could be more complete by mentioning when a wait is appropriate, but nothing essential about invoking the tool is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description adds no meaning beyond what the schema provides; it only restates the notion of a duration. Accordingly, baseline score 3 applies.

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

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

The description uses a specific verb ('waits') and a specific resource ('a specified duration in seconds'), making the tool's function immediately clear. It also distinguishes itself from sibling browser actions like browser_navigate or browser_click, which perform different operations.

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 no explicit when-to-use guidance or exclusion cases. However, in a browser automation context, waiting is a recognizable low-level utility, and no sibling tool duplicates this function, so the appropriate usage is largely implied.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description goes well beyond them: it partitions operations into read-only families (status/list/telemetry/get/view/check) vs. stateful ones (create, log, record, checkpoint, etc.), discloses error semantics ('missing or invalid inputs return an `Error:` message without raising an MCP transport error'), warns that `unlock_execution` stays blocked until gates pass, and flags that `apply_auto_update` can replace installed Fable files. This materially enriches the annotation-level safety profile.

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

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

The description is a single dense paragraph of moderate length, but for a tool with 116 parameters and 61 actions, the density is justified and nearly every clause earns its place. It is front-loaded with the core dispatcher concept and action-selection rule. Minor deduction: the long comma-enumerated lists of operation names and families are harder to scan than structured bullets or a small table would be.

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 extreme complexity (116 params, 61 actions, output schema present), the description covers the essentials an agent needs: dispatch semantics, sibling-tool routing, session lifecycle, read-only vs. persistent operations, error-handling behavior, and two dangerous operations that require caution. Because an output schema exists, not restating return-value structure is acceptable; nothing critical is missing.

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

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

Schema coverage is 100%, so the schema already documents every parameter, giving a baseline of 3. The description adds genuinely useful parameter behavior beyond the schema: 'Only fields documented for the selected action are read' — a critical clarification for a 116-parameter dispatcher — plus the `session_name` reuse convention and the note that results live in `result`. These rules prevent an agent from assuming all 116 parameters are applicable to every call.

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: 'Runs one Fable operation selected by `action`' — accurately framing this as an action-dispatching umbrella tool. It then enumerates the domains it covers (sessions, gates, evidence, rubrics, checkpoints, etc.) and explicitly distinguishes itself from the browser_* sibling family, so an agent can determine what this tool is versus what it is not.

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 ('Use it for Fable sessions, gates, evidence/proofs...') and explicit when-not-to-use routing ('use browser_* tools for web-page navigation and interaction'). It also gives a concrete workflow rule: start stateful flows with `create_session` and `session_name`, then reuse the name — actionable direction an agent can follow without opening the schema.

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