Capture Screenshot

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

The annotations declare destructiveHint: true and readOnlyHint: false, while the description depicts a benign capture-and-return operation with no side effects. A screenshot capture is fundamentally non-destructive, so the annotation directly contradicts the described behavior. This is flagged as an Annotation Contradiction; an agent relying on the safety annotations would be misled about this tool's side effects.

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 front-loaded with the core purpose in the first sentence, followed by usage guidance and the password note. It is slightly dense, but every sentence earns its place — the returnImageBase64 guidance is essential for correct invocation, and the bold emphasis improves scannability.

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?

Given there is no output schema, the description correctly carries the burden of explaining return behavior, covering both output modes. For a tool with 4 optional parameters and no required fields, it covers the essential invocation decisions. It omits error/failure behavior (e.g., unreachable device), but the core usage space is adequately covered.

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%, so the baseline is 3. The description adds meaning beyond the schema by explaining the two response shapes (inline image vs. '{ success, filename, bytes }'), the host rendering behavior, and the condition under which the password can be omitted. This gives the agent decision-relevant semantics the schema alone does not provide.

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 states a specific verb and resource ('Capture a screenshot of the current device screen') plus the exact return mechanism ('MCP image content block (JPEG, base64)'). This clearly differentiates it from image-related siblings like get_app_icon, which captures an app icon rather than the live device screen. An agent knows exactly what this tool does and what it returns.

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 gives explicit when-to guidance: keep returnImageBase64 true (or omit it) 'for any human-facing capture,' and set it false ONLY for batch/metadata-only flows where no one will view the image. The password condition is also spelled out. It does not explicitly contrast with alternative tools or state when not to use screenshot at all, but the usage context provided is strong.

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