get_screen

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

With no annotations, the description discloses the substantive behavior: it is a snapshot read of live screen state and a required precursor to ui_act. It does not explicitly state that the call is side-effect free, nor how fresh the snapshot is or what happens if no browser is attached, keeping it below a 5.

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 sentences, front-loaded with the core identity before the usage rule. The first sentence is a dense four-item enumeration packed into one clause chain, but every item carries information an agent needs.

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?

No output schema exists, and the description compensates by enumerating what the snapshot contains, which is exactly what is needed. Missing only the relationship to sibling board tools (show_board, list_boards) for an agent deciding where to look first.

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 tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The parenthetical about ui_act inputs describes return content, not this tool's inputs.

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 resource — the current browser screen — and enumerates its contents (page/app state, ui_act actions with inputs, board components, active board). An agent can distinguish it from ui_act and show_board, though the boundary with show_board/describe_data is only implied, not spelled out.

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?

"Call it before ui_act, and to see what the user is looking at" gives a concrete precondition and a concrete use case. It stops short of naming when NOT to use it (e.g. vs show_board or describe_data), so it is clear context rather than full routing guidance.

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