screenshot

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

Annotations declare readOnlyHint=true, which covers the safety profile. The description adds that it returns base64, which is useful output context. However, it doesn't disclose details like whether a screen-on state is required, whether the device must be unlocked, or how large the base64 payload might be. The base64 return disclosure is the main value-add beyond annotations, but richer behavioral context (e.g., required device state) would be more helpful.

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 concise sentences with zero waste. The description clearly communicates the action, the target, and the return format without any padding. Every word earns its place.

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 single-parameter read-only tool with full schema coverage and an output schema present, the description is largely complete. It communicates purpose and return format. It could note the required device state (on/unlocked), but given the tool's simplicity, annotations (readOnly) plus good schema coverage make this adequately complete.

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 100% - the single 'serial' parameter is fully described as the device serial number. The description adds no additional parameter semantics beyond the schema. With full schema coverage, baseline 3 is appropriate; the description doesn't add context like what happens when serial is omitted or whether it's optional for single-device setups.

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 takes a screenshot of the Android device screen and returns base64 image. The verb is specific ('screenshot') and the resource is defined (Android device screen). It doesn't explicitly distinguish from screen_record_start/stop, but 'screenshot' vs 'screen_record' are semantically distinct enough that the name carries the differentiation.

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 (when you need a static image of the device screen) but provides no explicit guidance on when to use this versus screen_record_start/stop or other alternatives. The sibling set includes screen recording tools, which share visual-capture context, and the description offers no differentiation. However, the distinction between screenshot and video is reasonably understandable from the name alone.

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