dosbox_view_screen

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral context: capturing from a window photograph without activating it implies non-exact/approximate output, and clarifying the contrast with 'exact and saved' helps set expectations. It could additionally state output format details, but the annotations already cover the key safe-read 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?

Three sentences, all substantive, with the primary function and key differentiator front-loaded. No filler or redundant prose.

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 simple read-only view tool with two optional parameters, defaults, and only an image return value, the description gives everything an agent needs to determine when to call it and what result to expect. It even routes to the exact-frame sibling.

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 50%: max_width is thoroughly described in the schema, but pid is not. The description does not explain pid's role or when to provide it, though pid is optional with a null default and max_width is already documented. Since the missing parameter is optional and low-risk, baseline 3 is appropriate.

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 description clearly identifies the action ('look at/results in the current frame as an image') and the resource (the emulator screen). It also explicitly distinguishes the tool from dosbox_capture_screen by noting this view is photographed from the window and not guaranteed to be the exact saved frame.

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?

It states when to use this tool ('see where the game actually is between steps') and provides the alternative condition: use dosbox_capture_screen when the frame has to be exact and saved. This gives clear decision guidance to an agent.

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