websex_browser_action

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

With no annotations, the description carries the full behavioral burden, yet it says nothing about side effects, whether actions auto-wait for element readiness, what happens on a missing selector, or whether fill replaces versus appends text. The action list is a useful vocabulary but not behavioral disclosure.

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 with no filler; the action enumeration is substantive content rather than padding. It is tight, though the flat list could be grouped by category (text entry vs toggles vs pointer).

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

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

An output schema exists so return values need no explanation, but for a mutating browser tool with zero annotations, 0% schema coverage, and four required parameters, the description omits session prerequisites, selector format, and failure behavior — too little 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 0% across 5 parameters, and the description only indirectly covers the 'action' parameter by listing valid values. It never explains selector syntax (CSS vs XPath), which actions consume 'value', or what session_id/engagement_id must reference, leaving required inputs undocumented.

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

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

The description states a specific verb+resource ('selector-based browser action') and enumerates the concrete actions supported, so an agent knows this mutates a page element rather than navigating or capturing. It does not explicitly distinguish itself from siblings like websex_browser_evaluate or websex_browser_set_state, which also act on a live 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?

There is no when-to-use guidance, no mention that an existing browser session/engagement is required, and no routing to alternatives such as websex_browser_evaluate for JS-driven interactions or websex_browser_navigate for page loads. The agent must infer usage entirely from the name.

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