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

With no annotations, the description carries the full behavioral load and does so well: it discloses country coverage (ES/PT/FR/IT/DE), that area/land use/municipality are populated only for Spain, that no market prices are returned, and that a missing parcel yields an error while the rest still compare. It also notes the whole comparison is one API call. Auth/permission requirements are the only notable omission.

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?

Roughly four compact sentences, front-loaded with what the tool does and what it returns, followed by constraints and edge cases. Every sentence carries information; only the density of the country caveats borders on crowded.

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 and no annotations, yet the description covers return contents, per-country field availability, unsupported regions, partial-failure behavior, and call cost. An agent has everything needed to call this correctly and interpret the 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 coverage is 100%, so the baseline is 3. The description goes further by explaining that the country code is semantically tied to regime support (ES common regime) and that the returned fields differ by country, giving the agent context the schema's plain enum list cannot convey.

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 states a specific verb (compare) plus resource (parcels) and enumerates exactly what is compared: location, solar potential, agricultural use and investment score. The 2-3 parcel scope and multi-country support immediately separate it from get_parcel and the other single-aspect 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?

It gives an explicit when-not ('Basque Country and Navarre are not supported here') and routes the agent to the alternative ('use the single-parcel tools'). It also implies the 2-3 parcel minimum. That is strong routing guidance, though it never states positively when comparison beats calling get_parcel per parcel.

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 and does meaningful work: it discloses the upstream data source (SIGPAC), that price is only returned 'when available' (partial/optional output), that richness varies by country, and that field names come back in Spanish. It does not cover behavior when the parcel is urban or outside the supported countries, which is the main remaining gap.

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 the returned content front-loaded, followed by coverage scope and a language caveat. No filler, though the final sentence about Spanish field names could arguably fold into the first sentence to tighten the block.

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 must describe returns, and it does — listing land use, crop, terrain attributes, NDVI and price. An agent can form a clear expectation of the response payload. It is slightly short on failure/edge behavior (unsupported country or non-rural parcel) and on whether price requires anything extra.

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%: both 'reference' (official cadastral reference of a rural parcel) and 'country' (enum with auto-detect on omission) are already documented in the schema. The description reinforces the geographic scope tied to 'country' but adds no new format or value semantics. Baseline 3 applies when the schema does the heavy lifting.

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 resource (agricultural context for a rural parcel) and enumerates the concrete outputs: SIGPAC land use, main crop, slope, altitude, irrigation, NDVI, and a reference crop price. That distinguishes it from siblings like get_solar_potential or get_parcel, though it never names an alternative explicitly. Purpose is clear and non-tautological.

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 by 'for a rural parcel' and by the geographic coverage note ('Richest in Spain; also Portugal, France, Italy and Germany'), which helps the agent decide whether to call it at all. However, there is no explicit when-to-use vs. when-to-use-an-alternative guidance and no stated prerequisites (e.g. must already have a cadastral reference or use get_parcel first).

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. It usefully discloses output formats and country-code coverage, including the UK coordinates-only exception. But it does not state read-only nature, permission requirements, or error behavior; for a read tool this is adequate but not rich.

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 waste. The purpose and outputs come first, followed by input compatibility constraints, making it well front-loaded and easy to scan.

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 tool is simple, has full schema coverage, and no output schema. The description appropriately explains return values (GeoJSON, ring, centroid, area) and input coverage. Minor gaps like coordinate reference system or precision are not critical for selection.

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. The description adds meaning by clarifying that references use the same 30 codes as get_parcel and that the UK is coordinates-only, which goes beyond the schema's generic 'Official cadastral reference' and country auto-detect notes.

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 gives a specific verb (get) and resource (parcel boundaries) and states the exact outputs: outline as GeoJSON and/or [lat, lng] ring, plus centroid and area. It clearly distinguishes the tool from get_parcel by focusing on geometry rather than parcel attributes.

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?

It provides clear context for use ('for mapping and GIS work') and specifies input compatibility with get_parcel references, including the UK exception. However, it stops short of explicitly saying when to choose this tool over alternatives like get_parcel or compare_parcels.

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 and does well: it discloses that the formula is never returned, that accessibility and risk come back as not_available, that the score is relative to available factors, and that it costs one API call. It does not describe auth requirements or what the error looks like for an unsupported country, which is the main remaining gap.

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 core deliverable and zero filler sentences; every clause carries information (scale, rating values, factor levels, country scope, cost). The middle sentence is a dense run-on covering three separate facts, which costs a little readability.

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 and no annotations, so the description must explain the return value — and it does, specifying the 0-100 scale, the rating enum, the factor-level enum, and which factors may be not_available. Combined with the country-support constraints and the one-call cost hint, an agent has everything needed to call it and interpret the response.

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 both parameters are already documented, including the country enum with auto-detect behavior. The description repeats the country list rather than adding new parameter-level meaning (no reference-format guidance, no note on how country changes the result set beyond availability). Baseline 3 is correct.

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+resource (investment score for a parcel) with the output scale (0-100) and rating vocabulary, and implicitly differentiates itself from factor-level siblings like get_solar_potential, get_agriculture and get_market_data by explaining that it is built from them. An agent can distinguish it from every sibling without opening a 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?

Gives clear context for when the tool applies: supported countries (ES, PV, NA, PT, FR, IT, DE), the narrower country scope of the market factor, and an explicit exclusion ('Other countries are not supported'). It never explicitly says 'use this instead of get_solar_potential when you want an aggregate', so the routing guidance is 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 carries the full burden, and it does disclose meaningful behavior: aggregated-not-individual data, per-country data availability and sources, degradation to available=false, and 'One API call' cost. It omits auth requirements and whether results are cached or rate-limited, but the behavioral disclosure is well above average 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?

Front-loaded with the core purpose, then coverage details in tight parenthetical clauses. Every sentence earns its place, with only minor density in the country enumeration. No filler or restatement of the name.

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?

With no output schema, the description must convey return shape, and it does: France returns average EUR/m2, number of sales, last sale date and estimated value; Italy returns OMI zone values; Germany returns Bodenrichtwert per m2 or available=false. It also covers the reference-note case, so an agent knows exactly what to expect across all inputs.

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 already 100%, so the baseline is 3. The description adds real meaning to the country parameter by mapping its enum values to concrete outcomes (ES/PV/NA/PT => note only; FR/IT/DE => figures), which the schema description alone does not convey.

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 first sentence states a specific verb and resource ('Aggregated land and property price reference for the area around a parcel') and immediately narrows scope with 'Never returns individual sales.' It clearly distinguishes itself from a raw sales-list tool, but it never names or contrasts against close siblings such as get_value_history or get_investment_score, so sibling differentiation is only 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?

It gives strong conditional guidance: which countries yield figures (FR, IT, DE/NRW) and what to expect elsewhere (ES, PV, NA, PT return a reference note with no figures; DE outside NRW returns available=false). This tells the agent when the tool is useful versus when it is not. It stops short of pointing to alternative sibling tools for the no-data cases.

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 burden and does so well: it enumerates the returned fields (reference, location, address, municipality, area, land use, outline), flags that outlines are only present when the official source provides them, and discloses the UK coordinate-only limitation. It says nothing about authentication, rate limits, or error behaviour for missing parcels.

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 purpose and input modes, then the coverage caveat. The 31-code list is long and largely duplicates the schema enum, which is the one redundant element; the rest of the prose is dense and earns its place.

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 output schema exists, and the description compensates by listing the returned fields and the condition under which the outline is included. Combined with the coverage and UK caveats, an agent has what it needs to call it correctly; only error/not-found behaviour is unaddressed.

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 on top: automatic country detection from the reference format or point, the coordinate-only constraint for the UK, and a human-readable expansion of every enum code. That goes beyond what the schema alone conveys.

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?

Specific verb+resource: 'Look up a cadastral parcel' by official cadastral reference or WGS84 coordinates, with an explicit geographic scope (29 European countries plus two foral cadastres). An agent can immediately distinguish this from siblings like search_address or compare_parcels.

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?

Clearly states the two input modes (reference or lat/long), that country is optional and auto-detected, and that the UK supports coordinates only. It does not name alternatives such as search_address or state when this tool is preferred over them, so it stops short of a 5.

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 behavioral burden. It usefully discloses the external data source (PVGIS, European Commission JRC) and the output set, but says nothing about it being a read-only computation, latency of the external call, or what happens for out-of-coverage references.

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 the capability and source, followed by the concrete deliverables and coverage. No filler or redundancy beyond the country list, which itself is useful scoping.

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?

With no output schema, the description's enumeration of returned metrics (kWp, production, savings, payback, CO2, tilt/orientation) does the necessary work of setting expectations. Only edge behavior outside the supported countries is left unaddressed.

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 both parameters are already documented in schema, including the enum and the auto-detect fallback. The description's country list merely repeats the enum and adds no syntax or format detail for 'reference'.

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 (estimate) and resource (photovoltaic potential of a parcel), names the authoritative source (PVGIS / EC JRC), and enumerates the concrete outputs returned. No sibling tool touches solar data, and the stated country scope further pins down the capability.

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 supported-country list implicitly tells the agent when the tool is applicable, but there is no explicit 'use this when...' framing and no named alternative among the parcel siblings. Usage is inferred 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 carries the full burden and does well: it discloses the 30-day snapshot granularity, the provenance-dependent start of history, the guaranteed-null cadastral value, the exact semantics of change_pct, country coverage, and the one-call cost. It does not explicitly state the operation is read-only/paginated or whether the number of returned snapshots is capped, which are the remaining gaps 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?

The core content is front-loaded in the opening clause (what a snapshot is and which fields it holds), and every following sentence adds distinct information: cadence, provenance, null-value caveat, change_pct definition, coverage, and cost. The fragment style ('One API call.') is dense rather than bloated.

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 must describe returns, and it does: snapshot fields, change_pct meaning, empty-list behavior, and the always-null cadastral value. What it omits is the ordering of the returned snapshots (oldest-to-newest) and any cap on the number of entries, which an agent consuming a time series would want.

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% and both parameters (reference, country) are already documented in the schema, including the enum and auto-detect behavior. The description repeats the country list ('Recorded for ES, PV, NA, PT, FR, IT, DE and AT') without adding format, syntax, or lookup guidance beyond the schema, so the baseline of 3 applies.

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+resource (historical snapshots of a parcel's area and land use) and immediately resolves the ambiguity in its own name: 'The official cadastral value is not recorded yet (always null)', so an agent knows get_value_history does not actually return cadastral values. It also distinguishes itself from the sibling that feeds it (get_parcel).

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?

It gives a strong precondition and implicit usage rule: history 'starts the first time anyone looks the parcel up through CatastroGPS (get_parcel)', so a never-queried parcel returns an empty list. That tells the agent when the tool is useful versus when it will yield nothing, and names the related sibling, but it never explicitly contrasts this tool with get_parcel for current-state queries.

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 burden. It discloses geographic coverage limits, the expected input shape, and the downstream chaining step, but says nothing about behavior on no-match, partial-match, rate limits, or authentication, which would matter for a lookup 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?

Front-loaded with purpose, then constraints, then required inputs, then next step. The two inline examples consume space but are directly useful for formatting the free-text input; no sentence is 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 single-parameter lookup with no output schema, the description covers input format, geographic scope, and the follow-up call well enough to invoke correctly. It stops short of describing failure modes or what the returned reference looks like in structure.

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 value beyond the schema by giving two concrete format examples and the instruction to include street number and municipality or postal code. It slightly exceeds the schema's terser field note.

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+resource ('Find the Spanish cadastral reference for a postal address') and explicitly scopes it to free-text Spanish addresses. It clearly distinguishes itself from the sibling get_parcel by describing the address-based path versus the coordinate-based path.

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?

Explicitly states when to use it (Spanish postal address as free text, Spain central Catastro), when not to (Basque Country, Navarre, other countries), what the alternative is ('use get_parcel with coordinates there'), and the required follow-up ('call get_parcel with the returned reference and country ES').

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