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

With no annotations, the description carries the full behavioral burden; it does disclose outputs (area m²/ha, perimeter) and the two computation methods (planar UTM vs geodesic GRS80 ellipsoid). It omits input-validity behavior: minimum vertex count, whether points must be ordered/closed, and error handling for invalid polygons.

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 dense sentences with no filler; outputs are front-loaded, then the mode/point-format distinction. Only minor inefficiency is the line break mid-definition.

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 stateless computation tool with no output schema and 0% coverage, the description covers outputs and both input modes well. The main remaining gap is input constraints (min points, ordering) rather than results, which an agent would still need.

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% and the pontos array items are opaque generic objects, so the description does all the work. It specifies the exact keys for each mode ({'e','n'} for utm, {'lat','lon'} for geo) and the meaning of the tipo values, fully compensating for the empty schema.

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?

States a specific resource and outputs: area in m² and ha plus perimeter of a polygon. Clear enough to distinguish from coordinate-conversion siblings (geo_para_utm, utm_para_geo) implicitly, though no sibling is named explicitly and the closest analog (calcular_poligonal) is not addressed.

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 explains when to use each mode (tipo='utm' for planar UTM, tipo='geo' for geodesic GRS80), which is genuine mode-selection guidance. But it says nothing about when to choose this tool versus the transform/convert siblings in the family; usage is only implied.

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

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

No annotations exist, so the description carries the full burden. It does disclose the computational model (tolerance T·√n, bowditch vs transit compensation), which is meaningful behavioral context beyond structure. But it omits units (is angulo in DMS string or decimal degrees?), error behaviour when closure exceeds tolerancia_angular_seg or precisao_minima, and whether the call fails or returns a warning.

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?

Front-loaded with the operation and its outputs, then switches to a compact parameter glossary; nearly every clause carries information. The telegraphic, symbol-dense style ("1:N", "{'e','n'}") is terse but readable for a technical agent.

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 9-parameter computational tool with no annotations and no output schema, the description covers the inputs reasonably but never describes the return shape (closure values, residuals, coordinate list) or failure semantics, which an agent needs to interpret results. The combination of no output schema and no return-value description is the main incompleteness.

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% and every nested object is opaque (additionalProperties: true), so the description does heavy lifting by defining estacoes keys {nome, angulo, distancia}, the meaning of the angle (clockwise from backsight to foresight), distance to the next station, and the apoio keys {re, partida, chegada, vante}. It leaves fator_escala, precisao_minima, and tipo's other possible values unexplained, so it is not fully compensating.

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?

It gives a specific verb and resource — computes a topographic traverse — and enumerates the concrete outputs (angular closure with T·√n tolerance, linear closure, 1:N precision, compensation, coordinates), so the agent knows exactly what the tool produces. It does not differentiate itself from siblings such as area_poligono or the UTM/datum converters, so the agent must infer the boundary itself.

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 effectively separates two usage modes — closed traverse (requires azimute_inicial and inicio) and connected/framed traverse (requires apoio) — which is real conditional guidance for choosing inputs. However, it never explicitly says when to choose this tool over the sibling geodetic tools, nor what inputs make the call invalid.

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

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

With no annotations, the description carries the full disclosure burden, and it does contribute an important behavior: per-point failures are collected in 'erros' and do not abort the batch (partial-failure semantics). It stops short of stating that the operation is a pure computation with no side effects, and says nothing about the shape of the successful results.

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?

Three dense sentences with no filler: purpose first, then accepted conversion modes, then payload shapes and error handling. The shorthand style (colon-separated examples, no framing for 'de/para') is efficient but occasionally terse enough to slow parsing.

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 should describe return values; it only explains the 'erros' side channel and never states what a successful result looks like (presumably a list of converted coordinates with the same 'nome' key). For a batch conversion tool with three undocumented-schema parameters, this leaves the caller guessing at the success payload and at hemisphere encoding.

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% and the schema types 'pontos' as an untyped array of free-form objects, so the description must do all the work — and it does, spelling out the exact keys for GEO points ({'nome','lat','lon'}) and UTM points ({'nome','e','n','fuso','hemisferio'}) plus the accepted values for de/para. Remaining gaps are the accepted values for 'hemisferio' and whether de/para are case-sensitive.

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 opening sentence names a specific verb and resource ('Converte vários pontos') and the qualifier 'de uma vez' signals batch scope, which implicitly separates it from the single-point siblings geo_para_utm and utm_para_geo. However, no sibling is named explicitly, so the differentiation requires the agent to infer it from the tool names.

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 enumerates the four legal de/para combinations ('GEO:SIRGAS2000', 'GEO:SAD69', 'UTM:SIRGAS2000', 'UTM:SAD69'), which effectively constrains how the tool may be called. It does not, however, say when to prefer this batch tool over the single-point conversions or transformar_datum, so the routing decision is left implicit.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does not state that this is a pure/side-effect-free computation, does not give output format (zone number only? hemisphere? central meridian in degrees?), and gives no valid range for the longitude.

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?

A single front-loaded sentence with no filler, which suits a one-parameter utility. It is arguably too terse rather than bloated, but nothing is wasted.

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 minimal one-parameter tool this is close to adequate: the input and the two computed outputs are named. However, with no output schema and no annotations, the missing input format and output encoding leave the agent guessing on details that matter for calling it correctly.

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% and 'lon' is typed merely as a string with no title or format. The description confirms the parameter is a longitude but does not specify decimal degrees, sign convention, hemisphere handling, or whether a string like '45W' is expected — a real ambiguity given the string type.

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?

States a specific computation: the UTM zone and central meridian for a given longitude, which is distinct from sibling conversion tools like geo_para_utm or utm_para_geo. It names the resource and the returned quantities, though it never explicitly contrasts itself with those siblings.

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?

No indication of when this tool should be chosen over geo_para_utm or utm_para_geo, nor any prerequisites or exclusions. The agent must infer usage purely from the one-line purpose.

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

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

With no annotations, the description carries the full burden. "Converte" plus the named outputs (E, N, fuso, fator de escala, convergência meridiana) make clear this is a deterministic computation, but it never states that the operation is side-effect-free, how hemisphere/southern-hemisphere false northing is handled, or what happens with invalid input.

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?

Three short sentences, front-loaded with the transform and its outputs, then per-parameter notes. Efficient, though the mid-sentence line break and the terse "fuso:" / "datum:" labels make it read more like schema notes than prose.

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?

No annotations and no output schema, so the description is the only source of behavior, and it partially covers returns and two parameters. It is not complete enough for an agent to call confidently, since input formatting for lat/lon and error/edge-case behavior are absent.

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. It does add real meaning for datum (SIRGAS2000 default vs SAD69) and fuso (forced zone), but says nothing about lat/lon despite them being typed as strings, leaving the accepted format (decimal degrees vs DMS, sign convention) undocumented — a critical gap for a coordinate conversion tool.

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?

States a concrete verb and resource ("Converte latitude/longitude em coordenadas UTM") and names the output components (E, N, fuso) plus scale factor and meridian convergence. The direction of the transform implicitly separates it from the inverse sibling utm_para_geo, though the sibling is never named.

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 only implied: the fuso parameter is described as forcing a specific zone, which hints that by default the zone is derived from longitude, and datum defaults to SIRGAS2000. There is no explicit statement of when to use this versus utm_para_geo, transformar_datum, or fuso_utm, and no conditions or exclusions.

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

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.

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

With no annotations, the description has to carry the full load: it does disclose the returned fields and that status reflects 'the last week' (a useful recency window). It does not state that the operation is a non-mutating lookup, which datum/coordinate system lat/lon must be expressed in, or what happens when no station meets the criteria — notable gaps given sibling datum-transformation tools that imply reference-frame ambiguity.

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 sentence with the resource and coordinate scope front-loaded, then the return payload. Every clause contributes; only the sub-list of fields makes it slightly listy, but nothing is wasted.

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 description partly compensates for the missing output schema by naming the returned fields, but with no annotations, no output schema, and three undocumented optional parameters (including a boolean filter and a count), an agent still lacks the coordinate format and result-limit behavior needed to call it confidently.

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% and the 4 parameters are undocumented: the description only alludes to 'uma coordenada' without saying lat/lon are strings in decimal degrees, and never explains so_ativas (default true, presumably filtering to operational stations) or quantidade (default 3, result count). With the schema doing nothing, the description should have compensated and does not.

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?

States a specific resource (RBMC/IBGE GNSS stations) and the exact operation (nearest to a coordinate), and enumerates what comes back: distance, azimuth, weekly status, receiver, descriptive sheet link, and practical RTK/static/PPP guidance. No sibling tool in the list does station lookup, so the agent can route here without ambiguity.

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 mention of 'orientação prática (RTK, estático, PPP)' implies the surveying use case but never says when to pick this tool, what the prerequisites are, or what to do if results are empty. Since no sibling overlaps, the absence of an explicit alternative is tolerable, leaving usage implied rather than stated.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses that it uses official IBGE parameters (R.PR 1/2005) and that the response includes horizontal displacement in meters, which is real added context. It does not, however, state directionality (de/para), accepted input formats, or input validity constraints.

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 tight sentences, front-loaded with purpose and followed by the useful output note. Nothing redundant, 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?

For a 5-parameter tool with zero schema descriptions, no annotations, and no output schema, the description is too thin. It partially addresses return behavior (displacement) but leaves the entire parameter surface undocumented, which an agent needs in order to call it correctly.

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% across 5 parameters, so the description is the only source of meaning—and it fails to explain them. It never maps 'de'/'para' to source/target datum, never explains the height parameter 'h' (default 0), and gives no hint whether lat/lon are decimal or DMS strings.

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?

States a specific verb (transforma) and resource (coordenadas geográficas) scoped to exactly two datums, SAD 69 and SIRGAS 2000. This clearly distinguishes it from the UTM-centric siblings (geo_para_utm, utm_para_geo) without the agent needing to open any schema.

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 datum-to-datum scope implies usage, but the description never explicitly says when to pick this over geo_para_utm/utm_para_geo or converter_lote. No exclusions or prerequisites are stated, leaving the agent to infer the boundary between datum transformation and projection conversion.

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

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

With no annotations, the description carries the full behavioral burden, yet it only names the inputs and the output pair. It says nothing about the default datum SIRGAS2000 and its effect on results, hemisphere defaulting to S, valid fuso range, input units, output precision, or failure modes for out-of-range coordinates.

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?

A single front-loaded sentence with no filler, stating inputs then output. It is efficient, though its brevity is part of why semantics and behavior go unexplained.

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?

Five parameters with zero schema descriptions, no annotations, and no output schema leave the description responsible for explaining defaults, units and return format — none of which it does. An agent can guess the call shape but not the correct values or expected result.

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% — all five parameters have only bare titles. The description names four (E, N, fuso, hemisfério) but adds no semantics: no units for E/N, no fuso range, no accepted hemisphere or datum values, and the datum parameter is not mentioned at all despite materially changing the output.

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?

States a specific verb and resource: converting UTM coordinates (E, N, fuso, hemisfério) into latitude/longitude. The direction of conversion implicitly distinguishes it from the sibling geo_para_utm, but the sibling is never named and the tool name alone would be ambiguous to a non-Portuguese reader.

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?

No indication of when to use this versus geo_para_utm, transformar_datum, or converter_lote, and no prerequisites stated (e.g. that the source datum must be known or that inputs are in metres). The agent must infer the workflow entirely from the name.

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