navegador_abrir

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

With no annotations, the description carries the whole burden and does add useful behavior: it discloses the return shape and that credentials persist in the browser profile, which implies persistent state across calls. It omits side effects on existing browser state (does it open a new tab or navigate the current one), what happens on load failure, and any timeout/error behavior.

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 short sentences, front-loaded with the action and the return value, then the differentiator versus screenshots. No filler, though the trailing note about saved logins is placed after the usage cue rather than grouped with other behavioral caveats.

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 the description does not need to enumerate return fields and it briefly does anyway; with no annotations the remaining gap is behavioral (tab/window effects, failure modes, URL constraints). For a one-parameter navigation tool it is adequate but leaves real questions open.

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 single 'url' parameter carries no description in the schema, so the description must compensate — but it says nothing about expected format (scheme required? relative paths allowed?) or whether the URL can point to local files. The only param is required, and its semantics remain undocumented in both places.

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 resource ('Abre um site no navegador do agente') and even previews the return payload (page text plus numbered element list), so the agent knows what comes back. It does not explicitly name the sibling it complements, navegador_ler, so the boundary with the follow-up reading tools is only implied.

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?

Gives one clear usage cue: prefer this over screenshots because the page arrives as short text. That is genuine when-to-use guidance, but there are no exclusions (e.g. when to use navegador_ler or tela_descrever instead) and no mention of prerequisites such as needing a valid absolute URL or that a browser session must not already be mid-flow.

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