locate_target

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

With no annotations, the description carries the full burden. It adds one behavioral note ("Claude and Antigravity share one queued model"), hinting at serialization/contention, but says nothing about the required model-loading prerequisite, whether image files are consumed, error behavior, or latency. Key traits affecting invocation are undisclosed.

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 short sentences with the most important constraint ("Visual fallback only") front-loaded. The final sentence about the shared queued model is cryptic and its relevance to the caller is unclear, which slightly undercuts the otherwise tight structure.

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?

A five-parameter tool with no annotations, no parameter documentation, and an evident prerequisite (a loaded grounding model, per the load_grounding_model sibling) is under-described. The output schema covers return values, but the description leaves the caller without enough information to correctly prepare inputs.

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 five parameters, including required target and image_path, and the description adds no meaning for any of them. Nothing explains whether target is a text label, a CSS selector, or a description, nor what viewport_css_width/height or delete_after_read do.

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 phrase "Visual fallback only" implies image-based target location, but the description never states a verb+resource explicitly (e.g., "locate a UI target in a screenshot"). An agent must combine the name and the word "visual" to infer the purpose, and nothing distinguishes it from grounding_health or load_grounding_model.

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?

"First inspect Playwright DOM/accessibility" explicitly names the preferred alternative and establishes a fallback ordering, which is genuine when/when-not guidance. It stops short of naming the sibling tools or stating failure conditions under which the visual path should be retried.

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