device_capabilities

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

With no annotations, the description carries full burden and delivers well: it discloses the tri-state value semantics, the critical rule that 'unknown' is an equally valid answer and that support must never be invented, plus the fallback behavior when ADB is unreachable. Absent disclosure: what happens when neither ADB nor hints yield data, and exactly which capabilities beyond video output are checked.

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 tightly written paragraphs with purpose front-loaded in the first sentence. The 'unknown is equally valid, never invent support' warning and the fallback instructions each earn their place. Slightly verbose in phrasing but no filler.

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?

An output schema exists, so return-value format need not be in the description. The description covers value semantics and the non-ADB fallback path well, but leaves gaps: the role of scrcpy_path, fuller behavior of the ADB path via serial, and how this diagnostic tool relates to sibling diagnostic/rescue tools. Adequate but not complete for a 4-parameter tool with zero annotation support.

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 compensate. It does meaningfully explain manufacturer_hint and model_hint (manual fallback inputs for the known-model database lookup), and serial is loosely inferable as the ADB device identifier. However, scrcpy_path is entirely unexplained in both schema and description, leaving an important parameter semantically opaque.

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 clear verb+resource: 'Az eszkoz/gep helyreallitasi kepessegeinek diagnosztikaja' (diagnostics of the device/machine's recovery capabilities) and specifies the tri-state output values. This distinguishes it from device_info (general info) and the rescue_* session tools, though it never names those siblings explicitly, so full differentiation is left partly implicit.

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 concrete situational guidance: when ADB is unavailable (broken screen, never-authorized device), supply manufacturer_hint/model_hint manually to query at least video output capability from the known-model database. This is clear context for when to use the fallback path, but it does not explicitly state when to prefer this tool over specific alternatives like rescue_probe or explain_capability.

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