adl_open

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

With no annotations, the description carries the full burden and does substantial work: origin/network grants gate URL opens, interactive_desktop shares the human pointer and keyboard, physical OS input needs trusted opt-in plus an exclusive input lease, and strict isolation fails closed. It omits failure modes, return values, and whether an open is reversible.

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?

Purpose is front-loaded in the first clause, and the subsequent sentences each add a distinct constraint rather than restating. The closing sentence, 'Desktop strict isolation fails closed,' is terse to the point of being cryptic, which costs a point.

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 3-parameter, zero-annotation, no-output-schema tool, the description covers the permission and safety model well but leaves an agent guessing about what an open returns (a handle? a target_id?), what happens on a denied or failed open, and how to choose between url and target_id.

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 coverage is 0%, so the description must compensate, and it partially does by explaining the behavioral meaning of two mode values (background_semantic, interactive_desktop) plus strict isolation. But target_id is never explained beyond the word 'permitted', and nothing clarifies the url-vs-target_id relationship or precedence when neither is marked required.

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 specific verb and dual resource: 'Open a permitted target_id or HTTP(S) URL.' This clearly distinguishes the open-from-handle case from the open-a-URL case. It does not differentiate itself from siblings like adl_app or adl_act, which also act on targets, so it stops short of a 5.

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 concrete routing advice – 'Use background_semantic for desktop work alongside a human' – and an explicit prohibition: 'Never switch to interactive_desktop to work around a failed semantic action.' That is real when/when-not guidance. It does not say when to prefer this over sibling tools such as adl_app, so it is not fully exhaustive.

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