browser_element_at

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

With no annotations, the description carries full burden. It does disclose the return payload (role, text, clickability, DOM path), which is the most useful behavioral fact for this tool. However it does not say what happens when nothing is at that point (null vs error), whether a live browser session is required, or that the operation is a non-mutating lookup.

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 dense sentence with zero filler, front-loading the key differentiator ('Visión por píxel SIN imagen') before the concrete contract. Nothing redundant to cut.

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 small two-parameter read tool with no output schema, the description compensates well by enumerating returned fields. The remaining gaps — coordinate frame and behavior at empty coordinates — are the only things an agent might need in order to call it correctly.

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

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

Schema description coverage is 0%, and the schema declares both params as bare numbers. The description tells the agent x and y are pixel coordinates for a hit-test, which is real added meaning, but leaves the coordinate frame unspecified (viewport vs page vs device pixels) — a critical ambiguity for a coordinate-based tool.

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 concrete verb and outcome: given (x,y) it returns which element is at that point, plus the shape of what comes back (role, text, clickable, DOM path). The 'SIN imagen' framing implicitly distinguishes it from the visual screenshot approach, so an agent can tell it apart from image-based siblings without opening the schema.

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

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

There is no explicit statement of when to reach for this over browser_find (search by selector/text), browser_snapshot (structure) or browser_screenshot (visual). The 'SIN imagen' phrase hints at the screenshot alternative but never names it or states the selecting condition, leaving the agent to infer usage from coordinates alone.

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