screenshot

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

No annotations are provided, so the description carries the full burden. It discloses a key behavior: the screenshot is saved to a file (under screenshots/ or an absolute path) and then returned. However, it does not mention any prerequisites (e.g., an active browser connection), side effects (e.g., file overwrites), or limitations (e.g., timing, visibility of elements). For a read-like operation, this is moderate disclosure, but not exhaustive.

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?

The description is a single, tight sentence that front-loads the core action and includes the most important behavior (save location). Every word adds value; there is no filler. It is appropriately sized for a simple tool.

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?

The tool is simple with only two optional parameters and no output schema or annotations. The description adequately explains the main purpose and the path parameter, but fails to describe 'full_page', which is a significant omission. It also doesn't specify the return format beyond saying 'return it', which could be ambiguous (does it return the file path or the image data?). For a tool with zero annotation coverage, this is incomplete.

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%, so the description must explain both parameters. It partially does: the phrase 'unless an absolute path is given' clarifies the 'path' parameter by indicating it influences the save location. However, it completely omits any mention of the 'full_page' boolean parameter, which is essential to understanding whether the screenshot captures the full page or just the viewport. This leaves the agent guessing about half the tool's capabilities.

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 states the tool does a specific thing: takes a PNG screenshot of the browser, with a clear resource (browser) and verb (take). It also mentions the default save location and that it returns the screenshot, making it unambiguous and differentiated from any sibling tools (none of which are screenshot-related).

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?

The description implies usage whenever a screenshot of the current browser state is needed. It does not explicitly mention alternatives or when not to use it, but among the sibling tools there is no other screenshot tool, so the context is clear. A minor gap is the lack of any explicit 'use this when...' statement, but given the self-evident purpose, this is acceptable.

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