browser_get

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

No annotations are provided, so the description carries the full burden. It states only that it 'gets' properties, implying a read operation, but does not disclose side effects, if any, whether permissions are needed, or what happens when required parameters are absent. It also does not clarify behavior for different property types beyond the schema's note that selector is required for text/html/value.

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 extremely brief ('Get text/html/value/url/title'), which is concise but arguably too sparse. It front-loads the essence but omits any context or caveats that could help an agent. It is not verbose, but it also does not feel complete.

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

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

The tool has many siblings and no output schema, so the description should clarify what the tool returns and how it interacts with other tools. The listing of property types hints at possible return values, but there is no note about the return format, error cases, or relationships with tools like browser_snapshot or browser_state. The description is insufficient for an agent to call this correctly in all contexts.

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 describes each parameter (session, property, selector) with basic descriptions, giving 100% coverage. The description adds significant value by enumerating the allowed values for the 'property' parameter (text/html/value/url/title), which is not present in the schema. This helps agents know what to pass.

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 clear verb (Get) and a specific resource (browser property), and lists the exact property types it can retrieve: text, html, value, url, title. This gives a concrete idea of what the tool does. However, it does not explicitly differentiate from sibling tools like browser_read or browser_snapshot, which may have overlapping capabilities.

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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any conditions, exclusions, or prerequisites. With 38 sibling tools, an agent has no basis for choosing browser_get over others without deeper inspection.

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