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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: values are measured on a 1080x1920 reference and scaled to the requested frame size, which tells an agent results are approximate and scale-dependent rather than exact device measurements.

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?

One dense but well-ordered sentence with the primary output (unsafe margins) leading and secondary details trailing. No filler, though the colon-separated list makes it heavier than it needs to be for a single-sentence description.

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?

There is no output schema, so the description carries the return shape, and it does so by naming each returned field. Combined with annotations covering safety and a fully documented three-parameter schema, this is close to complete; only the units/precision caveats beyond "approximate" and the distinction between 'all' and per-platform calls are left implicit.

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 100%, so the baseline is 3, but the description adds real meaning for width/height by explaining the 1080x1920 measurement basis and scaling relationship. Platform enumeration is repeated from the schema rather than extended.

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?

Opens with a specific verb and resource ("Returns the approximate areas of a vertical (9:16) video frame that the app interface covers") and names the exact platforms supported. The output contents (margins in px/percent, safe rectangle, button column position, guidance) are enumerated, so an agent can tell this apart from siblings like check_text_position without inspecting schemas.

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 intended use — knowing where UI overlays occlude a vertical frame — is implied but never stated as guidance ("use this when..."). No alternative is named; in particular the relationship to check_text_position, which presumably consumes these zones, is not explained.

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