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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It reveals the no-look-ahead rule, the exclusion of the own deed, the comparison against actual sale prices, and the exact output metrics returned. This is highly transparent for an agent.

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 carry a dense amount of useful information: methodology, core behavior, output metrics, and intended usage. It is front-loaded and every phrase earns its place with no repetition of schema details.

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 tool with no output schema, the description lists the output metrics in sufficient detail for an agent to interpret results. The methodology and data source are clearly explained, and the required parameters are simple and covered by the schema. Nothing essential is missing.

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 the schema already documents every parameter. The description adds context about the methodology and outputs but does not add new meaning to the parameters themselves beyond what the schema already provides.

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 ('Replay') and resource ('the comparable-sales estimator on the commune's own notarized sales'), and clearly explains the walk-forward methodology. It also distinguishes itself from the sibling estimate_property by positioning this as the reliability-checking counterpart.

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 an explicit use case: 'Use it to say how reliable estimate_property is in this specific market.' It names the relevant sibling and the intended purpose, though it does not explicitly state when not to use it or list alternative tools for other scenarios.

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 provided, the description carries the behavioral disclosure burden and does substantial work: it clarifies that contenance is the taxed whole-parcel area, not living space, and that the cadastre never records ownership. It also names the data source. It does not cover edge behaviors like no-match responses or multiple parcels, but the core semantic traps are disclosed.

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 description is efficiently structured: the main subject and key outputs are front-loaded, followed by valuable semantic clarifications and a source attribution. Every sentence contributes something, though the provenance line is minor and the phrasing is slightly dense. Overall well-sized for the information it conveys.

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 lists return fields and clarifies their meaning, which is valuable given the lack of an output schema. However, it omits essential invocation context: how to choose between address and lat/lon, whether parameters combine, and what happens with multiple or unmatched parcels. This is a functional lookup tool, but an agent cannot fully anticipate calling behavior from the description alone.

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 only 33% and lat/lon have no schema descriptions. The tool description does not compensate: it references 'an address' but never explains how to supply one, how lat/lon relate to address, which parameter takes precedence, or what coordinate format is expected. The address parameter's schema description adds some meaning, but lat/lon remain effectively undocumented.

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 clearly identifies the resource (official cadastral parcels) and enumerates the distinctive outputs (idu, section, number, contenance), which separates it from sibling property/estimate tools. However, it relies on a nominal phrase 'Official cadastral parcel(s) containing an address' rather than an explicit action verb like 'retrieve' or 'look up'.

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 contextual usage guidance by stating what the data is for (cadastral id quoted on deeds, section, number, official area) and explicitly excludes ownership information and habitable surface. It does not name sibling alternatives or state when not to use this tool, so it stops short of full routing guidance.

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 of behavioral disclosure. It lists the outputs and the accepted query forms, which is helpful, but it does not explain behavior for ambiguous names, partial matches, or non-existent communes. This is acceptable for a simple read-only lookup but leaves some behavioral gaps.

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 description is a single efficient sentence that front-loads the returned data fields and ends with the input key. Every word contributes useful information, and there is no redundancy or 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 tool with one documented parameter and no output schema, the description gives a solid overview of the return fields and how to query. It is complete enough for a straightforward lookup, though it could mention matching behavior for ambiguous names or the response format to be fully airtight.

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 for the single parameter is 100%, and the schema's query description already explains the accepted values with examples. The main description adds context by showing what the result will contain, but it does not need to elaborate on parameters beyond what the schema already provides.

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 clearly identifies the resource (French communes) and the specific data returned (population, postcodes, département, région, surface, center coordinates), which distinguishes it from sibling tools like geocode_address or reverse_geocode. It lacks an explicit verb like 'get' or 'retrieve', but the intent 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?

The description conveys when to use the tool by stating the input key ('by name or INSEE code') and the type of information returned. However, it does not explicitly contrast it with any sibling tools or state when not to use it, leaving the alternative-routing to inference.

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 burden. It discloses the data source (ADEME open data) and the nature of the data (official certificates), which adds credibility and context. However, it does not disclose behavior such as what happens when no DPE is found, whether the tool returns partial matches, or whether the data is updated/complete. The description is honest but thin on behavioral detail.

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 description is a single, well-structured sentence that front-loads the core purpose and includes the source. Every word earns its place; no filler or repetition of schema details.

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 simple lookup tool with 3 parameters and no output schema, the description is mostly adequate. However, it does not mention what the response looks like (e.g., list of DPE records), how to interpret missing results, or any rate limits. Given the absence of annotations and output schema, a bit more context about return behavior would make it complete.

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 the schema already documents all three parameters (address, limit, dataset). The description adds context about what the DPE contains (energy label, GES label, surface, construction year) but does not add meaning beyond the schema for the parameters themselves. Baseline 3 is appropriate.

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 ('Find'), a specific resource ('official energy performance certificates (DPE)'), and the key attributes (energy label A-G, GES label, surface, construction year). It also names the source (ADEME open data) and the geographic scope (French address), which clearly distinguishes it from sibling tools like geocode_address or property_sales.

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 implies usage for French addresses and DPE lookups, but it does not explicitly state when to use this tool versus alternatives like property_report or commune_info. It does not mention exclusions or prerequisites (e.g., that the address must be in France, or that DPE may not exist for all buildings). The context is clear enough for a basic lookup, but no explicit routing guidance is provided.

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 of behavioral disclosure. It clearly states the method (weighted median of nearby notarized sales, adjusted to current market level), the auditability (every comp and weight returned), and additional outputs (rent indicator, gross rental yield). It does not disclose potential limitations like data coverage gaps or precision caveats, but the core behavior is well described.

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 description is a single, dense sentence that front-loads the core purpose and method, then lists additional outputs. Every clause adds information: method, geographic scope, property types, auditability, and extra outputs. No filler or repetition.

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 tool with no output schema and no annotations, the description covers the main inputs, method, and outputs. It does not explain the return format (e.g., JSON structure of comps and weights) or edge cases like addresses without nearby sales, but the essential context for calling the tool is present.

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 75%, so the schema already documents address, surface_m2, and rooms. The description adds context that surface_m2 and type_local are key valuation inputs and that rooms refines the rent indicator, but it does not add meaning beyond the schema for most parameters. The description's mention of 'precise French address' reinforces the address parameter's requirement.

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 ('estimates'), a precise resource (property value at a French address), and a distinctive method (weighted median of notarized sales with audit trail). It clearly differentiates from siblings like rent_estimate (rent indicator) and property_sales (raw sales data).

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 implies when to use it: for a valuation of a flat/house at a precise address, and it explicitly mentions the official rent indicator and gross rental yield, which distinguishes it from rent_estimate. However, it does not explicitly state when not to use it or name alternative tools for other cases (e.g., property_sales for raw comps).

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 behavioral burden. It explains that the tool normalizes input into multiple candidates and lists the key fields returned. It also signals fuzzy/ambiguous-address handling. It does not discuss no-match behavior or error conditions, but covers the core behavior well.

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 pack the purpose, output details, and usage guidance with no filler. The most actionable instruction ('Use this first if an address is ambiguous') is placed at the end as a capstone.

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 simple two-parameter tool with full schema coverage, the description covers what it returns, what inputs it accepts, and when to reach for it. It lacks explicit response shape details, but the listed output fields are enough for an agent to understand the result. Minor edge-case behavior is not described.

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%, with both 'query' and 'limit' already explained and exemplified. The description reinforces that the query can be an address, street, or city, but adds little beyond the schema, so the baseline of 3 is appropriate.

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 uses a specific verb ('Resolve') and a clear resource ('a French address, street, or city'), and enumerates concrete outputs (coordinates, INSEE city code, BAN id). This distinguishes it from siblings, especially reverse_geocode, which handles the opposite direction.

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 phrase 'Use this first if an address is ambiguous' provides a clear trigger condition for choosing this tool. It does not explicitly name the alternative for reverse geocoding or state when not to use it, so it stops short of full when/when-not guidance.

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 provided, the description carries the full disclosure burden. It clearly explains what the tool returns, notes the data source (IGN ADMINEXPRESS), and explicitly states the layer has no socio-demographic figures, which is a meaningful behavioral limitation beyond the basic lookup.

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 sentences, each earning its place: the core purpose and outputs, the downstream join possibility, and the data source/limitation. It is front-loaded with the most important action and avoids redundant or filler text.

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 and no annotations, the description is reasonably complete: it names the output fields, the data source, and the layer's limitation. It does not discuss edge cases like invalid addresses or ambiguous matches, but that is a minor gap for this simple tool.

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?

The input schema fully describes the single parameter 'address' as 'Address in France,' so schema coverage is 100%. The description adds little beyond that, mentioning the address is used to identify the containing IRIS but not providing formatting or disambiguation guidance; baseline 3 is appropriate.

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 opens with 'Identify the IRIS', a specific verb and resource, and enumerates the exact outputs: 9-character IRIS code, name, type, and commune. It also distinguishes the tool from generic geocoding or commune lookups by specifying INSEE's infra-communal statistical unit.

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: obtaining the IRIS code for an address and joining it to INSEE demographic/income tables. It also states the layer 'carries identity only, no socio-demographic figures,' which prevents misuse, though it does not explicitly name sibling alternatives or state when not to use it.

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 bears the full burden of explaining behavior. It states the source and high-level content, but it does not disclose what the output looks like, whether an address or coordinate pair is required, how missing/invalid inputs are handled, or any limitations of the report.

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 description is a single focused sentence that front-loads the core purpose, lists representative risk types, and adds the authoritative source. Every part contributes useful information with 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?

Given no output schema and no annotations, the description is incomplete for reliable invocation. It does not state required inputs, response format, or whether both address and coordinates are accepted together. The risk list and source are helpful, but an agent still lacks key operational details.

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 only 33%, with lat and lon having no descriptions. The description's phrase 'address or point' hints at the alternative inputs, but it does not explain coordinate format, units, or the need to supply at least one of address or lat/lon. This does not sufficiently compensate for the schema gap.

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 action and resource: an 'Official risk report' covering concrete risk categories like flood, clay shrink-swell, radon, earthquake, and industrial sites. It clearly distinguishes the tool from real-estate and geocoding siblings by focusing on natural and technological risks.

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 establishes clear usage context: it is for a French address or geographic point and returns official risk information from Géorisques. It does not explicitly mention alternatives or when not to use it, but the scope and risk-topic focus make the intended use reasonably clear.

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 behavioral burden. It discloses the data source (actual notarized sales), the time range (2021-2025), and the computed metrics, but it does not mention output shape, missing-data behavior, or whether a minimum number of sales is required.

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 description is two sentences with no filler. It front-loads the core operation and adds only valuable context: source of data, statistics produced, geographic scope, and data years.

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 is sufficiently complete for a statistics tool: it names the outputs (median, mean, quartiles, per-year evolution), the data source, and the accepted query scopes. It could add caveats about statistical confidence or sparse data, but nothing essential is missing given the detailed schema.

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?

The schema already describes all four parameters with 100% coverage, including defaults and the radius behavior for city-wide queries. The description adds no parameter-level meaning beyond that, so the baseline score 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 uses a specific verb and resource: compute price-per-m² statistics from actual notarized DVF sales. It also specifies the exact statistics produced and the geographic scope (address or commune), making it distinguishable from sibling tools like property_sales or estimate_property.

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 implies the tool is for aggregate price-per-m² statistics and gives geographic scope, but it does not explicitly state when to prefer this tool over siblings or what conditions would make another tool more appropriate.

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 bears the full burden. It transparently lists all returned data categories and notes that valuation and yields are computed only when type_local and surface_m2 are supplied. It implies a read-only operation (a report), but does not explicitly state side-effect-free behavior. Given the context, this is adequate but not exhaustive.

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 description is a single dense sentence that packs many data points without redundancy. It front-loads the core purpose ('One call, full dossier') and then enumerates components. It is slightly long but every element contributes to setting expectations. It could be broken into shorter phrases for readability, but it remains efficient.

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?

Given the tool's broad scope and the absence of an output schema, the description does a good job of listing all report sections and the condition for the valuation part. It states the required address and mentions the optional parameters that affect output. It does not describe error handling or what happens when data is unavailable, but for an aggregation tool this is acceptable. Overall it provides sufficient context for an agent to decide and invoke 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 50% (address and type_local are described in the schema). The tool description adds meaning for type_local and surface_m2 by explaining they enable the valuation and yield calculations, which goes beyond the schema. However, it gives no explanation for the 'rooms' parameter, and does not clarify its role in the report. Thus it partially compensates for the schema coverage gap but leaves one parameter unexplained.

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 clearly states a specific verb ('produce a full dossier') and a precise resource ('French address'), and enumerates the many report components. It explicitly differentiates itself from the narrower sibling tools (rent_estimate, dpe_lookup, etc.) by being a comprehensive aggregate, and even positions itself as the 'ideal first call' for property questions.

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 clear context: it is the recommended first call when a user asks about a specific property. It implies that for focused sub-queries (e.g., just rent, just risks), the dedicated sibling tools should be used instead. It could be more explicit about when not to use it, but the guidance is unambiguous enough for an agent to route properly.

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 adds useful behavioral context: data source (French tax administration DVF), time range (2021-2025), access requirement ('no API key'), and the address-vs-commune behavior. It does not disclose rate limits or result ordering, so it is not a 5.

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-load the core action, resource, and important access facts. Every phrase earns its place with no redundant schema repetition.

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 covers what the tool returns (price, date, surface, rooms), data source, and coverage years. With no output schema, that return-field list is important and present; only minor operational details such as defaults/pagination are left to the schema.

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 71%, and the description adds context for 'address' and 'city' behavior but does not clarify the undocumented min/max_surface_m2 parameters. The description is not sufficient to fully compensate for the two schema-less surface filters.

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 verb ('List'), a precise resource ('actual notarized property sales ... recorded by DVF'), and the scope ('around an address' or 'whole commune'). This distinguishes it from estimation/price-per-m2 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 clearly tells when to use the tool: for actual sales around an address or for a whole commune when only a city is provided. It does not explicitly name alternatives or exclusion conditions, but the 'actual notarized' phrasing contrasts with estimate-style siblings.

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 burden. It discloses the result is an average proxy for taxe foncière on built properties, includes specific components, and cites the data source, giving the agent a realistic expectation of the output. It does not discuss rate limits or auth, but for a read-only tax lookup these are less critical, so this is adequate.

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 description is two sentences with no filler, placing the key return statement first and then the caveat and source. Every word contributes to understanding the tool's purpose and limitations.

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 covers the output's nature, scope, components, and source, while the schema covers parameters and default behavior. It does not specify the currency or output format, but for an average tax estimate this is likely sufficient given the tool's simplicity. The absence of an output schema means details are left to the caller, but the essentials are present.

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?

The schema already provides descriptions for both parameters (year with default behavior, location accepting address, commune, or INSEE code), giving 100% coverage. The description adds no extra parameter meaning, so it relies on the schema baseline. A score of 3 is appropriate.

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 clearly states it returns the annual average charge per taxable REI article for taxe foncière on built properties, listing included components. The title and context distinguish it from sibling tools like price_per_m2 or rent_estimate since it is the only tool addressing property tax. This provides a specific verb and resource that an agent can select accurately.

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 implies the tool is for aggregate tax averages by explicitly saying it is an aggregate proxy, not an individual property's tax bill. This tells the agent when not to use it, but it does not name alternative tools for individual tax estimates. The context is clear enough to guide selection, though explicit alternatives would strengthen it.

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 behavioral disclosure burden. It reveals the output unit, the coverage limitation, and the explicit no-guessing behavior when an address is not covered. It also names data sources, adding trustworthiness. Minor omissions like default behavior when optional parameters are absent are not addressed.

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 compact sentences deliver the core output, scope, non-guessing behavior, and sources with no redundancy. The most important information is front-loaded, and every sentence 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?

Given there is no output schema, the description adequately explains return values and edge-case behavior. It covers scope, units, and non-covered addresses. A small gap is that the optional parameters' behavior when omitted is not specified, but this does not seriously impair correct invocation.

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 the baseline is 3. The description adds context by linking rooms, construction period, and furnished status to the output, and clarifies that address must fall within covered areas. It does not add syntax or format details beyond what the schema already provides.

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 identifies the exact deliverable: loyer de référence, majoré (legal ceiling), and minoré in €/m²/month for rent-controlled areas, segmented by rooms, construction period, and furnished status. This clearly distinguishes it from siblings like rent_estimate by specifying legal reference rents rather than market estimates.

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 clear usage context: the tool applies to rent-controlled areas with a published open grid, notably Paris and Métropole de Lyon, and explicitly handles non-covered addresses. It does not name alternative tools or state exclusions explicitly, but the scope is concrete enough for an agent to decide when to invoke it.

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. It discloses that values are modelled, official, charges included, and sourced from the Carte des loyers. It does not mention coverage caveats or address-to-commune resolution, but 'modelled' appropriately signals that these are estimates.

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 compact sentence conveys the output, units, geographic scope, property breakdown, and data source with no filler. The key information is front-loaded and every clause 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?

For a simple two-parameter lookup with full schema coverage, the description is largely self-sufficient: it tells the agent what is returned and from where. It could be slightly more explicit about how an address maps to a commune and what happens when surface_m2 is omitted, but these are mostly inferable or handled by the schema.

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 little parameter-specific meaning beyond the schema: it reinforces that location is commune-oriented, but it does not elaborate on surface_m2 or its interaction with the returned values. The schema already documents both parameters adequately.

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 ('asking rents') and scope ('any French commune'), plus the exact breakdown by dwelling type. This clearly differentiates it from sibling tools like price_per_m2 and property_sales, which concern sale prices rather than rents.

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 implies the use case: obtain official commune-level modelled asking rents. However, it never explicitly contrasts this tool with alternatives such as price_per_m2, estimate_property, or rent_control, and it gives no when-not-to-use guidance.

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 provided, the description carries the full burden of behavioral disclosure. It only says 'Find', which suggests a read-only lookup, but does not disclose coordinate system assumptions, failure modes (e.g., out-of-range values, no address found), or any network/rate-limit behavior.

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 delivers the essential information with no filler. Every word contributes to understanding the tool's purpose and input.

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 simple two-parameter tool with no output schema, the description is adequate but not complete. It implies the return value (an address) but does not explain the meaning of 'nearest' or address format, nor any error/edge-case behavior. Given the complexity, more detail would improve agent success.

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 merely says 'GPS coordinates', which adds little beyond the parameter names 'lat' and 'lon'. It does not specify format (e.g., decimal degrees), valid ranges, or precision requirements, leaving the agent to rely on common knowledge.

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 ('Find') and a clear resource ('nearest French address') with the input ('GPS coordinates'). It differentiates from the sibling 'geocode_address' by reversing the direction (coordinates → address), which is immediately clear to an agent.

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 implies the use case—given GPS coordinates, get an address—but provides no explicit guidance on when to prefer this over alternatives like 'geocode_address', nor any exclusions or prerequisites. The intended context is inferable but not 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 of behavioral disclosure. It adds value by clarifying that the tool only states applicable rules and never judges project permission, a key behavioral boundary. It also cites the data source (GPU, DGALN / IGN), lending confidence about provenance. It does not mention read-only nature or error behavior, but the boundary is a solid extra beyond the basic purpose.

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 description is two well-structured sentences. The first sentence delivers the core purpose and lists the output components; the second adds the crucial limitation and the source. There is no filler, and the caveat is positioned for impact. It earns every word.

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?

Given there is no output schema, the description appropriately explains what the tool returns (zoning label/type, document reference, prescriptions). It also gives the source and the non-permission boundary. It does not cover coordinate format or edge cases like missing data, but for an agent deciding whether to call the tool and understanding its output, this is largely sufficient.

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 only 33% (only 'address' has a description). The tool description does not compensate for the undocumented 'lat' and 'lon' parameters—it does not specify coordinate format, reference system, or whether they are alternatives to address. The description mentions 'address' but adds no further parameter meaning. This leaves a significant gap for an agent needing to correctly populate coordinates.

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 clearly identifies the specific resource: urbanism zoning and prescriptions applicable to an address. It enumerates the returned information (zoning type, document reference, prescriptions) and implicitly distinguishes itself from sibling tools focused on property value, sales, and risks. This is more than sufficient for an agent to recognize the tool's unique purpose.

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 provides an explicit exclusion: 'never whether a project is permitted,' which signals when not to use this tool. It also sets context by mentioning the Géoportail de l'urbanisme source and address-based usage. However, it does not name any alternative sibling tool or explicitly state 'use this when you need zoning rules.' Thus it stops short of full routing guidance.

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