gsd_drone

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

No annotations exist, so the description carries the full burden. It usefully enumerates what the tool computes (GSD, footprint, spacings, precision, photo count), which effectively describes the return payload in the absence of an output schema. It does not state that the tool is a pure side-effect-free calculation, nor what happens when both gsd_cm and altura_m are supplied or omitted — a meaningful behavioral gap for a no-annotation tool.

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 sentences, front-loaded with the computations and followed by the camera list. No filler or restatement of the tool name. Slightly dense as a comma-separated list, but every clause carries information.

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 output-side is adequately covered by the enumeration of computed values, which substitutes for the missing output schema. The main unresolved issue is input sufficiency: with six parameters and zero required, the agent is not told that it needs at least one of gsd_cm/altura_m and area_ha for a meaningful result. For a calculator with no annotations, that invocation-critical detail should be stated.

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 0%, so the description must compensate, and it does in one important place: the valid camera values (mavic 3 enterprise, matrice 4e, phantom 4 rtk, zenmuse p1 35mm, mini 4 pro) are listed only here, since the camera parameter has no enum. It also explains the inverse relationship between gsd_cm and altura_m. It says nothing about units or valid ranges for sobreposicao_frontal/lateral or area_ha, leaving part of the six parameters to be inferred from their names.

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 names a specific domain and concrete computations: GSD from height (or height from GSD), photo footprint, line/photo spacing, expected precision, and estimated photo count. An agent immediately knows this is a drone aerial-survey geometry calculator rather than a coordinate/geodesy tool like the siblings. It stops short of explicitly contrasting itself with the UTM/polygon siblings, but the domain is unambiguous.

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?

Usage is implied: '(ou altura a partir do GSD)' hints that the tool can be driven from either GSD or flight height, which is the key invocation choice. However, it never states prerequisites, which inputs are needed together, or when an agent would pick this over a sibling. No explicit when/when-not guidance is present.

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