Is this listing too expensive? French property sales (DVF), crime, rents, risks, schools
Scored across 14 tools
Most tools target distinct resources or granularities (e.g., radius medians vs. address-level sales vs. commune rankings), and the long descriptions clarify scope. However, several price-data tools (property_prices, street_prices, recent_sales, sales_at_address, rank_communes) could be confused at first glance, and sea_views overlaps with sales_at_address via the sea_view flag.
All names use consistent snake_case, which is predictable. There is minor deviation in phrasing—some are verb_noun (find_place, rank_communes, appraise_listing) while others are noun_noun or noun_adjective (commune_profile, crime_stats, amenities_nearby)—but the overall style is stable.
14 tools is well within the ideal 3–15 range for a rich French real-estate data and valuation server. Each tool covers a distinct analytical dimension (amenities, appraisal, commune profile, copropriété, crime, loans, PTZ, prices, rankings, sales, sea views, streets), so the count feels earned rather than padded.
The surface covers the domain thoroughly: sale price data at multiple granularities, commune-level statistics (taxes, risks, energy, internet, rents), crime, amenities, copropriété registry, financing and PTZ calculations, sea-view detection, and geocoding. No obvious lifecycle gaps or dead ends for a property analysis toolset.
Schools (maternelle, primaire, collège/lycée), bakeries, night clubs, noisy bars and every bar or café within a radius (France), golf courses within 3 km (a point in a home's favour), and public transport (OpenStreetMap): train and RER stations, metro stations and tram stops within 1.5 km, and stations being built (the Grand Paris Express's) within 3 km: count per kind and the nearest ones.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| radius_m | No | Radius in metres (default 500, at most 3000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for adding operational detail: category-specific radii, country scope (France), data source (OpenStreetMap), and the return shape ('count per kind and the nearest ones'). It does not discuss auth needs, rate limits, or error behavior, but it goes well beyond what the structured fields provide.
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 definition is a single, dense sentence that leads with the main resource categories and avoids filler. It is longer than ideal and somewhat hard to parse due to nested parentheses and multiple radii, but every clause adds substantive scope information rather than repeating the name or title.
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?
Because there is no output schema, the description reasonably explains the return shape as counts per kind plus nearest ones, and it specifies the geographic and categorical scope. The main remaining gap is the absence of usage guidance relative to sibling tools, but for a read-only spatial lookup with full parameter documentation, the description is close to 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?
With 100% schema coverage, the baseline is 3, but the description adds crucial semantics not captured in the schema: radius_m does not apply uniformly, because golf courses are fixed at 3 km and transport is queried within 1.5 km (with stations under construction up to 3 km). That changes how an agent should interpret the radius parameter and is valuable despite the schema documenting each field.
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 the resource: nearby amenities and nuisances, with a detailed enumeration of categories (schools, bakeries, bars, golf, transport) and the fact that it returns counts and nearest items. It is specific about scope but does not explicitly contrast itself with any sibling tool, such as appraise_listing or commune_profile.
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?
There is no explicit guidance on when to use this tool versus alternatives, nor any stated prerequisites or exclusions. The phrase 'a point in a home's favour' hints at property-appraisal context, but the description stops short of telling an agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares a French listing's asking price with recent recorded sales (DVF) of the same type and a similar size around it (the smallest radius with enough of them): estimate with its interquartile range, gap and verdict, closest comparables (sales over 2.5 times off the median price per m² are left out as no market price), a headline such as "12 % au-dessus du marché", local price trend, the commune's main crime rates against France, its rent for the type (monthly rent for the floor area, gross yield at the asking price), its share of passoires thermiques (DPE F or G) for the type, its natural risks, its local tax rates (taxe foncière, waste tax, taxe d'habitation on second homes), its home internet (fibre and wired speeds), each mobile operator's 4G coverage level at the address (mobile_4g) and their antennas, amenities within 500 m, and the address's sea view when it has one. The estimate is the prix normal (resales without a view of the sea around) plus the premiums that apply (premiums): the energy label's discount or premium (décote/surcote DPE, resales only) when the label is known (energy, else its title and description say it: « DPE : F »), what the label fetches against the commune's mix of labels (ADEME) after the Notaires de France's « valeur verte » of 2024 resales per région and type (rates: each label's); the new-build premium (surcote neuf: what new homes sold off-plan fetch over resales in the commune, DVF 2023–2025; where it sold few, its département's read at the price of the resales around, the dearer they are the smaller) when the listing is new (new_build, else its title and description say so: VEFA, programme neuf, livraison prévue…), and the sun premium (surcote soleil) when the sun goes down into the sea (or the sea is seen) from its address, else when its description says so (unverified); the gap and verdict are against that total. It also gives what financing the asking price costs at France's current home-loan rates (financing: L'Observatoire Crédit Logement/CSA's latest month, per 15, 20 and 25 years: rate, monthly payment, total interest, and the commune's rent for the floor area minus the payment, borrowing the price and 8 % purchase costs less a 10 % down payment).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| sea | No | Its view of the sea, when known: the sun goes down into it, the sea is seen, or none; otherwise its address's view, then its description, decide. | |
| type | No | "Appartement" or "Maison" (others compare with every sale). | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| price | Yes | Asking price. | |
| title | No | The listing's title. | |
| energy | No | Its energy label (DPE), when the listing gives it; "none": unknown (with by_user, the words are then not read). | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| by_user | No | "new_build", "sea", "energy" or several joined by commas: what the user said themselves (it then beats the address's view and the words, and is shown as theirs). | |
| surface | No | Floor area in m². | |
| new_build | No | Whether the home is new (sold off-plan or never lived in), when the listing says; otherwise its title and description decide. | |
| description | No | The listing's description: its words tell a new home, a view of the sea and the energy label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare it as a safe read-only, idempotent operation; the description goes far beyond by disclosing data sources (DVF, ADEME, Notaires, Observatoire Crédit Logement), exclusions (comparables over 2.5× off median), inference fallbacks from title/description, and financing assumptions (8% purchase costs, 10% down payment, rates per 15/20/25 years). This is rich behavioral context that would not be inferable from the annotations alone.
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 one massive, run-on paragraph that tries to enumerate every output and methodology detail, making it hard to parse. While the first sentence is front-loaded, the overall size and convoluted phrasing are not concise.
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 carry the return-value burden, and it does exhaustively enumerate the estimate, IQR, gap, verdict, comparables, trends, crime, rent/yield, DPE, risks, taxes, internet, mobile 4G, amenities, sea view, and financing scenarios. Despite poor readability, the content is complete for this complex 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?
Schema description coverage is 100%, so the baseline is 3. The description adds integration semantics beyond the schema, such as by_user overriding address view and words, and how energy/new_build/sea are inferred when not explicitly provided.
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 states the specific action: comparing a French listing's asking price with recent recorded sales (DVF) and producing an estimate with verdict. It is clearly an aggregate appraisal tool, but it never names sibling tools like recent_sales or crime_stats to explicitly differentiate scope.
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 never states when to use this tool versus the many sibling data tools, nor any prerequisites or exclusions. Usage is only implied by the title and the verb 'compares'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a French commune (by name, INSEE code or position) or département: for a commune, its zone ABC (which sets the PTZ, Denormandie and LLI), whether it is a zone tendue, its rent control (encadrement des loyers, with its territory) and its social housing under the SRU law (homes, share, target, déficitaire, carencée), and its building plots' median price per m² of land (DVF, with its département's and France's); asking rents per m² (charges included) for flats, small and large flats and houses, with their range (ANIL/DHUP Carte des loyers); the energy ratings (DPE A–G) of its dwellings diagnosed since July 2021 and the share of passoires thermiques (F or G, which may no longer be let: G since 2025, F from 2028, and E from 2034), per flats and houses (ADEME); its natural risks: the risks listed by the state (DDRM), natural disaster (CatNat) decrees since 1982, prevention plans, radon potential (Géorisques); its local tax rates (DGFiP, in %): taxe foncière on buildings and on land, the household waste tax (TEOM; null where a fee pays for it), taxe d'habitation (on second homes and vacant dwellings only since 2023) with the commune's surcharge on second homes, the latest year's and the first's, the taxe foncière year by year, and for a commune how each rate splits between the commune, its syndicates, its intercommunality (named), special taxes and GEMAPI; its median price per m² of recorded sales (DVF) for flats, houses and both over the latest two years against the two before, and year by year; its home internet (ARCEP Ma connexion internet): the share of premises fibre, cable, copper DSL (copper_closed: no new subscribers), fixed 4G, radio and satellite reach, the share getting 8 and 30 Mbit/s and 1 Gbit/s by wire, and its premises by best technology; each mobile operator's 4G coverage of its homes (Orange, SFR, Bouygues Telecom, Free Mobile: the share of homes at each level of ARCEP's simulated maps, very good meaning indoors; metropolitan France), and their antennas in the commune (sites with 4G, 5G, 5G at 3.5 GHz). Each compared with its département and France.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| commune | No | Commune name or INSEE code (e.g. "Carnac", "56034"), or a département code ("56"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: data provenance (DVF, ANIL/DHUP, ADEME, Géorisques, DGFiP, ARCEP), time windows, comparison baselines (département and France), and the 'metropolitan France' scope limit for mobile coverage. It says nothing about response size or latency for what is clearly a very heavy aggregate call.
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 content is dense rather than padded, and with no output schema the return-value enumeration arguably earns its place. But it is delivered as one enormous run-on sentence joined by semicolons, with no headings or bullets, making it hard to parse. Front-loading exists but is immediately buried under the enumeration.
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 carries the full burden of describing returns, and it does so exhaustively — every metric, unit, source and comparison is stated. The main missing piece is usage routing against siblings, which is a guidelines concern rather than a return-shape one.
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 all five parameters (lat, lng, place, address, commune) are already documented, including precedence rules. The description only echoes the accepted inputs ('by name, INSEE code or position') and adds that a département code is valid, which the schema also states. 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 makes clear this is a comprehensive commune-level profile, enumerating the exact datasets returned (rents, DPE, risks, taxes, internet). It is a distinct resource from point-lookup siblings like street_prices or sales_at_address. However, it never explicitly distinguishes itself from overlapping siblings such as property_prices, ptz, crime_stats and rank_communes, leaving the agent to infer the boundary.
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?
There is no statement of when to use this tool versus the thirteen siblings. With overlapping tools like property_prices, ptz and crime_stats present, the absence of routing guidance ('use this when you need everything about a commune; use X for a single metric') is a real gap. Usage is only implied by the breadth of the enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The copropriété(s) the Registre national d'immatriculation des copropriétés (RNIC, Anah, Licence Ouverte 2.0) registers at a street address, matched by cadastral parcel (BAN geocoding then IGN API Carto), else by normalised address, else within 50 m (marked probable, with the distance): name, immatriculation number, lots, construction period, syndic type and name, whether a mandate is running, any mandat ad hoc, administration provisoire or état de carence, any arrêté (insalubrité, péril, équipements communs), residence service, last update, and alerts. The register does not say which works were voted in general meetings: the answer lists the documents to demand from the seller (minutes of the last 3 AGs, pré-état daté, PPPT/DTG, next AG's convocation, fiche synthétique and carnet d'entretien). A principal and its secondary syndicates are all returned. Cite "Registre national des copropriétés — Anah".
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | City or postcode the address is in, when the address does not say. | |
| address | Yes | Street address with its postcode or city (e.g. "138 boulevard de la Mer, 62152 Neufchâtel-Hardelot"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial context beyond them: the three-tier matching strategy, that the 50 m fallback is flagged 'probable' with a distance, that principal and secondary syndicates are all returned, the register's limitation (it does not record which works were voted), and a required citation string. This is exactly the kind of behavioural disclosure an agent needs before trusting the answer.
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 content is front-loaded (resource first, then matching caveats, then citation requirement) and the long field enumeration earns its place given there is no output schema. It loses a point for a heavily run-on opening sentence whose list of returned fields and document demands could be more scannable.
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 describe the return payload itself, and it does so comprehensively — result fields, matching confidence and distance, principal vs secondary syndicates, alerts, and the citation obligation. Nothing an agent needs to call and interpret this tool correctly appears to be 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 coverage is 100% with only two parameters, so the schema already carries the meaning of both. The description adds indirect value by explaining the geocoding path (BAN then IGN API Carto) but never addresses the 'place' fallback parameter, so it does not enrich the parameters beyond the schema baseline.
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 and resource — what the RNIC registers at a street address — and enumerates the exact fields returned (immatriculation number, lots, syndic, arrêtés, etc.). It is clearly distinguishable from siblings like sales_at_address, property_prices or commune_profile, which concern transactions or area statistics rather than copropriété registration.
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 context is clear: this is the tool for finding the registered copropriété(s) covering a given French address, and the matching cascade (parcel, normalised address, 50 m proximity) tells the agent what inputs will and won't resolve. However, no sibling alternative is named explicitly for cases where the agent instead wants ownership/transaction or commune-level data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offences recorded by police and gendarmerie (SSMSI, latest year) for a French commune — by name, INSEE code or position — per indicator, as rates per 1,000 inhabitants (per 1,000 dwellings for burglaries), next to its département, région and France, with the yearly trend.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| commune | No | Commune name or INSEE code (e.g. "Carnac", "56034"), or a département code ("56"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds real behavioral context beyond the annotations: the data source (SSMSI), recency (latest year), unit normalization (per 1,000 inhabitants / per 1,000 dwellings for burglaries), and comparative framing (département, région, France) plus yearly trend. This is useful disclosure, though it omits known caveats such as suppression for small communes.
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?
It is a single dense sentence, but front-loaded with the core purpose and scope; every clause (source, unit, comparison set, trend) carries information. Slightly packed with em-dash asides, which costs a point.
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, so the description must convey the return shape, and it does: normalized rates, comparator geographies, and yearly trend. Combined with full parameter coverage and safety annotations, an agent has enough to call it correctly; only edge-case caveats are 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 coverage is 100%, so the schema already documents all five parameters thoroughly. The description's 'by name, INSEE code or position' only loosely maps to place/commune/lat/lng without adding format or precedence detail, so the baseline 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: recorded offences from police/gendarmerie (SSMSI) for a French commune, with the exact output units. This clearly separates it from the property- and amenity-oriented siblings. It stops short of naming a sibling (e.g. commune_profile) to contrast against, so it isn't a full 5.
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: you call it to get crime statistics for a commune, addressable by name, INSEE code or position. There is no explicit when-to-use/when-not guidance and no stated alternative (commune_profile, find_place) for locating a commune first. Adequate but leaves the agent to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves a city name or postcode: its centre, extent and number of recorded sales, and the French communes of that name (INSEE codes) for crime_stats.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | City, its start, a word of its name ("Hardelot" for Neufchâtel-Hardelot) or postcode. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered without the description. The description adds what the resolution returns (centre, extent, sales count, INSEE codes) but says nothing about failure modes, ambiguous-name behaviour, or lookup scope beyond what the annotations imply.
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 dense sentence that front-loads the verb and resource and then lists outputs; nothing is padded. The stacked clauses around the colon are slightly awkward to parse but every element 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?
With no output schema, the description usefully enumerates the returned fields (centre, extent, sales count, INSEE codes), which is exactly what an agent needs to know. It falls short only on ambiguity handling (multiple communes of the same name) and on clarifying how this differs from commune_profile.
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 the single query parameter is already well documented in the schema, including the partial-name example ("Hardelot"). The description merely restates "city name or postcode" and adds no syntax or matching-behaviour detail 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?
States a specific verb ("Resolves") and resource (city name or postcode) and enumerates what is produced: centre, extent, number of recorded sales, and INSEE codes. It also implicitly differentiates itself from siblings by naming crime_stats as the consumer of its output, though it doesn't state how it differs from commune_profile or property_prices.
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 clause "(INSEE codes) for crime_stats" implies this is the geocoding step to run before crime_stats, which is useful routing context. However there is no explicit when-to-use statement, no exclusions, and no mention of what to do when a name resolves to multiple communes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
France's home-loan rates this month (L'Observatoire Crédit Logement/CSA, per 15, 20 and 25 years, excluding insurance) and, as asked: what a household can borrow (income_monthly: payments, insurance included, at most 35 % of net income less its other loans, the HCSF rule), and the budget it buys with its down payment once the purchase costs are paid; what a price (or a loan amount, loan) costs a month over each length, the income it needs at 35 % and the debt ratio it makes, with a PTZ beside the bank loan (ptz, at 0 %); a rate a bank offered (offered_rate, offered_years: a nominal rate excluding insurance, not a TAEG) against the market's for that length, its monthly payment and what the difference costs over the loan; a bridge loan on the home being sold (bridge_value): its amount and monthly interest. Purchase costs: notary, guarantee and fees, 8 % of the price for a resale, 3 % for a new home (new_build), unless purchase_costs is given (0 when the developer pays them; for a plot and a build contract, about 8 % of the plot only). Insurance: 0.30 % of the loan a year unless insurance_rate says otherwise.
| Name | Required | Description | Default |
|---|---|---|---|
| ptz | No | A zero-rate loan (PTZ) beside the bank's, in euros (the ptz tool works it out). | |
| loan | No | The bank loan's amount, in euros, when known (instead of working it out from price). | |
| price | No | A price to finance, in euros. | |
| new_build | No | A new home (VEFA): reduced notary fees. | |
| bridge_owed | No | With bridge_value: what is still owed on that home. | |
| bridge_rate | No | With bridge_value: the bank's rate for it (default the 15-year rate plus half a point). | |
| ptz_tranche | No | With ptz: its income tranche (1 to 4, from the ptz tool), for its deferral and repayment. | |
| bridge_share | No | With bridge_value: the share of its value lent (default 0.7). | |
| bridge_value | No | A bridge loan (prêt relais): the value of the home being sold, in euros. | |
| down_payment | No | Cash put in (apport), in euros; default 0. | |
| offered_rate | No | A rate a bank offered, nominal, excluding insurance (0.039 or 3.9 for 3.90 %); a TAEG is some 0.3 to 0.5 point above it. | |
| bridge_months | No | With bridge_value: months until the sale (default 12, at most 24). | |
| debts_monthly | No | Monthly payments of the household's other loans (car, consumer), in euros; default 0. | |
| offered_years | No | The length of the offered loan in years (default 25). | |
| income_monthly | No | The household's net monthly income (before income tax), in euros. | |
| insurance_rate | No | Borrower insurance a year as a share of the loan (0.003 for 0.30 %). | |
| purchase_costs | No | Purchase costs as a share of the price (0.08 for 8 %; 0 when the developer pays them), instead of the default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds substantial behavior beyond them: the HCSF 35 % rule, the 0.30 % default insurance rate, the 8 %/3 % purchase-cost defaults, the source of rates, and the fact that offered_rate excludes insurance and is not a TAEG. These assumptions materially affect results and are exactly the kind of context annotations cannot carry.
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 single dense paragraph is information-rich but structurally weak: semicolon-chained clauses mix market rates, capacity, payments, offered-rate comparison and bridge loans without headings, forcing the reader to re-parse to find the relevant mode. It is front-loaded with rates, which is arguably not the primary use case, and several clauses run long.
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 17 optional parameters and no output schema, the description carries the burden of describing outputs; it does sketch them conceptually (monthly payment, required income at 35 %, debt ratio, bridge amount and interest), which is helpful. However, it never indicates the shape or units of the returned figures, so an agent cannot fully predict the response format for a tool of this complexity.
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 schema already defines each parameter; the baseline would be 3. The description goes further by exposing cross-parameter defaults and interactions (insurance 0.30 % unless insurance_rate overrides, 8 % resale / 3 % new build unless purchase_costs is given, bridge defaults 0.7 share and 12 months), which the schema notes only partially restate.
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 concrete domain (French home-loan rates from L'Observatoire Crédit Logement/CSA) and enumerates the distinct computations it performs: borrowing capacity, monthly payments, offered-rate comparison, bridge loan, purchase costs. It is clearly distinguishable from siblings like ptz and property_prices, though the multi-mode scope makes it read more like a bundle than a single verb+resource.
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 'as asked' phrasing and the parenthetical 'the ptz tool works it out' gesture at routing, and parameter notes like 'when known (instead of working it out from price)' hint at inputs. There is no explicit statement of when to choose this tool versus ptz or property_prices, and no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Median sale price and price per m² of recorded sales within a radius, overall, per property type, per year and per number of rooms (1, 2, 3, 4, 5+), over the last years of data.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| type | No | Property type as the source names it, e.g. "Appartement" or "Maison" in France. | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| years | No | Years of sales counted back from the latest (default 5, at most 12). | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| radius_m | No | Radius in metres (default 500, at most 3000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description usefully discloses what is aggregated (recorded sales, medians, room buckets, year windows), but says nothing about data lag, coverage gaps or result size.
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 dense sentence that front-loads the two key metrics before the breakdown dimensions. Nothing is padded, though the run-on list of dimensions makes it slightly hard 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?
For a 7-parameter, 0-required, no-output-schema tool, the description does explain the shape of the returned statistics, which is valuable. It still leaves the caller without guidance on choosing between the place/address and lat/lng input modes or on how sparse results may be.
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 lat/lng/place/address/years/radius and the lat-lng precedence rule. The description adds the output-side meaning of the breakdown dimensions but no syntax or default details beyond the 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?
The description states a concrete metric set (median sale price, price per m²) and the aggregation scope (within a radius, by type/year/rooms), so an agent can tell this is a statistical summary rather than raw sales. It does not, however, explicitly differentiate itself from close siblings like street_prices, recent_sales or sales_at_address.
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 when-to-use or when-not-to-use guidance is given, and no sibling is named as an alternative. The aggregation framing implies 'use me for price statistics, not listings', but that must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a first-time buyer's PTZ may be, by the rules of offers issued from 1 April 2025 to 31 December 2027 (service-public.fr, checked 15 September 2026): the commune's zone ABC (place, address, lat/lng, or zone), the household's size (persons) and revenu fiscal de référence of year N-2 (income), the operation's cost (cost: price and works, TTC) and the home (kind: new flat in a collective building, new house, an old home with works of at least 25 % of the cost in zone B2 or C, or a social home sold to its tenant): whether the income is under the zone's ceiling, the income counted (the higher of the RFR and the cost divided by 9), the income tranche (1 to 4), the share financed, the cost ceiling, the PTZ's amount, its deferral and repayment (tranche 1: 10 years deferred then 15 years; 2: 8 then 12; 3: 2 then 13; 4: 10 years without deferral) and its monthly payments. The buyer must not have owned their main home in the last 2 years (exceptions: disability, disaster, a home made uninhabitable).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| cost | Yes | The operation's total cost, TTC: the price, and the works for an old home, in euros. | |
| kind | No | new_flat (default: a new home in a building of more than 2 homes), new_house, old_with_works (zones B2 and C), social (a social home sold to its tenant). | |
| zone | No | The zone ABC, instead of a place. | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| income | Yes | The household's revenu fiscal de référence of year N-2 (for an offer in 2026, the 2024 incomes), in euros. | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| persons | No | Persons the home will house (default 1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld=false, so safety is covered; the description adds genuinely useful behavioral context: the applicable rules version and validity window (offers from 1 April 2025 to 31 Dec 2027, checked 15 September 2026) and the fact that it returns derived eligibility outputs such as income tranche, ceiling, deferral/repayment schedule and monthly payments. This goes beyond annotations and compensates for the absence of an output schema.
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?
It is front-loaded with the purpose, and nearly every clause carries domain content, but it is delivered as a single sprawling sentence that interleaves input definitions, eligibility rules and output fields, making it hard to parse quickly. Structuring it into purpose, inputs and outputs would be far more usable.
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 sensibly enumerates the outputs (income vs ceiling, income counted, tranche, share financed, cost ceiling, PTZ amount, deferral and repayment schedule, monthly payments) and states the applicable rule set and eligibility exclusions. An agent has enough to invoke and interpret the result, though the eligibility/priority conditions are dense and the placement vs sibling tools is unclear.
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 largely restates the schema's parameter meanings (zone ABC, cost TTC including works, RFR of year N-2, person count) rather than adding syntax or format detail the schema lacks; the one genuinely extra element, the 'income counted (the higher of RFR and cost/9)', is a derived computation, not a parameter.
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 resource and computation: 'What a first-time buyer's PTZ may be, by the rules of offers issued from 1 April 2025 to 31 December 2027', which clearly separates it from sibling tools such as home_loan or appraise_listing. The purpose is recognizable, though it is framed as an open question rather than a direct verb+object statement ('compute PTZ eligibility and terms'), which slightly blurs the action.
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?
There is no guidance on when to choose this tool over alternatives like home_loan or property_prices, and no discussion of prerequisites for calling it. The eligibility rule about not having owned a main home in the last 2 years is a domain rule of the calculator, not usage guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
France's communes in a département (departement, e.g. "93"), a région (region, INSEE code, e.g. "11" for Île-de-France) or within radius_km of a place, ranked by the median price per m² of their recorded sales of a type (DVF, the latest 24 months), cheapest first, dearest first, by how it moved against the 24 months before (falling, rising), or by gross rental yield: each with its sales, the change, ANIL's asking rent per m² for the type, the gross yield, its population and distance. max_price_per_m2, or budget with surface, keeps the communes where that home is affordable. Paris, Lyon and Marseille by arrondissement.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| type | No | "Appartement" or "Maison" (default every home). | |
| limit | No | Communes returned (default 20, at most 100). | |
| order | No | price_asc (default), price_desc, falling (largest fall first), rising, yield (highest gross yield first). | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| budget | No | With surface: the price that home may cost, purchase costs aside. | |
| region | No | A région's INSEE code, e.g. "11" (Île-de-France), "84" (Auvergne-Rhône-Alpes), "93" (Provence-Alpes-Côte d'Azur). | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| surface | No | With budget: the home's floor area in m². | |
| min_sales | No | The fewest sales a commune's median needs (default 10). | |
| radius_km | No | Around place, address or lat/lng: the radius in km (default 15, at most 60). | |
| departement | No | A département's code, e.g. "93" or "2A". | |
| max_price_per_m2 | No | The dearest median price per m² kept. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real behavioral context: DVF as the source, a fixed 24-month window, the ANIL rent basis, the default min_sales=10, and the fields returned per commune. It stops short of saying what the default ranking scope is when no place/departement/region is given.
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?
It is front-loaded with the core purpose, but the first sentence is a single run-on clause chain dense enough to require re-reading, and the trailing 'Paris, Lyon and Marseille by arrondissement' fragment is unexplained. Information-dense but structurally weak.
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 14 optional parameters and no output schema, the description carries the burden well: it enumerates the returned fields and the key parameter interactions. The main gap is the absence of a default scope when no geographic anchor is provided.
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 baseline is 3, but the description adds meaning beyond the schema by grouping the order enum into families (cheapest/dearest, movement direction, yield) and explaining the budget+surface affordability interaction and the radius-around-place/address/lat-lng relationship.
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 and resource — ranking France's communes by median price per m² — and scopes it to a département, région or radius, with the ordering options spelled out. It is clearly distinguishable from siblings like property_prices or commune_profile, though it never names an alternative to route against.
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 the geography/ordering framing and the closing note that max_price_per_m2 or budget+surface filters to affordable homes, which is genuinely useful selection guidance. There is no explicit when-to-use vs. when-not, and no statement of what happens when no location parameter is supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The latest recorded sales within a radius (date, price, floor area, price per m², rooms, type, address, distance).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| type | No | Property type as the source names it, e.g. "Appartement" or "Maison" in France. | |
| limit | No | Sales returned (default 20, at most 100). | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| radius_m | No | Radius in metres (default 300, at most 2000). | |
| max_price | No | Maximum price. | |
| min_surface | No | Minimum floor area in m². |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety and determinism are covered. The description adds the 'latest recorded' recency framing and the returned field set, which is useful, but it omits geographic coverage limits, ordering guarantees, and pagination 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?
One compact sentence with the purpose front-loaded and the returned fields relegated to a parenthetical. Nothing is padded, though the field list is a dense enumeration that does little to aid tool selection.
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 returned-field enumeration partially compensates by telling the agent what comes back. But it omits the geographic scope (the schema's "in France" hint suggests a country limit), result ordering aside from 'latest', and how results behave when both coordinates and place are supplied — all relevant for a 9-parameter spatial lookup.
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% across all 9 parameters, so lat/lng/place/address precedence, defaults, and limits are all documented in the schema. The parenthetical field list adds no parameter-level meaning beyond that, so the baseline 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?
States a specific verb+resource+scope: "latest recorded sales within a radius." An agent immediately knows it returns recent transactions near a point. However, it never distinguishes itself from siblings like sales_at_address, street_prices, or property_prices, which cover overlapping ground.
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?
There is no statement of when to use this tool versus the other seven sales/price tools, no prerequisite requirements, and no exclusions. The radius framing implies a spatial lookup, but the agent must infer that on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every recorded sale at a street address (date, price, floor area, price per m², rooms, type), newest first, and a summary of its street with its latest other sales. Spellings are loose: "17 bis avenue de Saint-Mandé" finds "17 B AV DE ST MANDE". Without a number, the street's sales. When the street is not found, similar street names.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Property type as the source names it, e.g. "Appartement" or "Maison" in France. | |
| limit | No | Sales returned (default 50, at most 200). | |
| place | No | City or postcode the address is in, when the address does not say. | |
| address | Yes | Street address, with its postcode or city unless place gives it (e.g. "17 rue Gambey, 75011 Paris"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/non-destructive/openWorld=false, so safety is covered. The description adds real behavioral context beyond that: loose spelling normalization with a concrete example, newest-first ordering, a street-level fallback when no number is given, and a similar-street-name fallback when the street is not found. It stops short of noting any rate limits or how the similar-name fallback is ranked.
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-loads what is returned, then the matching semantics and fallbacks, in four tight sentences with no filler. The concrete "17 bis avenue de Saint-Mandé" example earns its space by making the fuzzy matching behavior unambiguous.
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 correctly carries the burden of describing return content (sale fields plus a street summary of latest other sales) and ordering, and it covers the main edge cases. It is slightly incomplete on the boundary with sibling street-level tools and on how the street summary differs from street_prices.
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 address, place, limit, and type; baseline 3 applies. The description adds a little (loose spellings accepted for address, numberless address means street-level), but does not clarify the type parameter's interaction with the returned 'type' field or the limit/pagination behavior.
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: recorded sales at a street address, and enumerates the returned fields (date, price, floor area, price/m², rooms, type). It is clear what the tool does, but it never names or contrasts with the obvious siblings (street_prices, recent_sales), leaving the agent to 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?
Usage is implied rather than stated: pass an address, omit the number to get street-level sales, and expect similar-name fallback if nothing matches. There is no explicit when-to-use-this-instead-of guidance relative to street_prices or recent_sales, so the agent must guess the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The sale addresses around a place whose sun goes down (or comes up) into the sea, month by month, with how far the shore is and their latest sale. Worked out from OpenStreetMap for France's sale addresses within 300 m of the coast: the sun's direction must reach the shore past no building but the home's own, no wood, no dune but a narrow one at the door, no cliff upwards, then cross open water. A ground-level estimate: floors, trees and relief are not known. An address missing here may still see the sea from upstairs; say so rather than that it has no view. The same view shows as sea_view on the sales of sales_at_address, recent_sales and appraise_listing.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| sun | No | Only addresses that see the sun set (sunset) or rise (sunrise) into the sea; default any. | |
| limit | No | Addresses returned, nearest first (default 25, at most 100). | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| radius_m | No | Radius in metres (default 1000, at most 5000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes well beyond that: it discloses the derivation (OpenStreetMap, 300 m coastal band, ray-cast to the shore past buildings, woods, dunes and cliffs), states the accuracy model (ground-level estimate; floors, trees and relief unknown), and warns that absence is not proof of no view. This is exactly the behavioural context an agent needs to interpret results honestly.
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 content is dense and mostly earns its place, but the structure is poor: the hardest, most convoluted sentence is first, and the reader must decode "around a place whose sun goes down (or comes up) into the sea, month by month" before reaching the clear material. The methodology clause is long and the stray "month by month" is dead weight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return burden — and it partly does, mentioning distance to the shore and the latest sale, plus the caveat about false negatives and where the same field reappears. For a 7-parameter, read-only search tool this is largely complete, though the exact shape of a returned record (field names, ordering beyond "nearest first") is left vague.
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 carries all seven parameters and the 3 baseline applies. The description adds only marginal value — it explains the sun concept ("whose sun goes down (or comes up) into the sea") which maps to the sun enum, and mentions distance-to-shore output — while the phrase "month by month" introduces confusion since no month parameter exists.
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 tool returns sale addresses with a sea view, and the title plus the second sentence ("France's sale addresses within 300 m of the coast") make that discernible. But the opening sentence — "The sale addresses around a place whose sun goes down (or comes up) into the sea, month by month" — is garbled and forces the agent to reconstruct the purpose rather than read it. The sibling cross-reference at the end helps distinguish it, but the core statement is not front-loaded clearly.
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 rather than stated: it tells the agent the same view surfaces as sea_view on sales_at_address, recent_sales and appraise_listing, which signals overlap, but it never says when to prefer this tool over those siblings or when it is the wrong choice. The instruction to report a negative as "may still see the sea from upstairs" is useful interpretive guidance, but no explicit when/when-not/alternative routing is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The streets around a place with their recorded sales (DVF) and median price per m² over the last 5 years, the most expensive first, or ranked by how their median moved: the latest 24 months against the 24 before (falling or rising first; only streets with at least 8 sales with a floor area in each period have a change). Each street with 5 sales or more has a page on the site (url).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (WGS84). | |
| lng | No | Longitude (WGS84). | |
| limit | No | Streets returned (default 25, at most 100). | |
| order | No | price_desc (default), price_asc, falling (largest fall first), rising, or sales (the most sold first). | |
| place | No | City, city start or postcode (e.g. "Carnac", "Paris 11e", "75011"); with address, the place it is in. Ignored when lat and lng are given. | |
| address | No | Street address with its postcode or city (e.g. "17 rue Gambey, 75011 Paris"), located where its sales were recorded (else its street's). Ignored when lat and lng are given. | |
| radius_m | No | Radius in metres (default 1000, at most 3000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real methodology beyond that: the 5-year median window, the 24-vs-24-month movement rule, the minimum of 8 sales-with-floor-area per period to register a change, and the 5-sale threshold for a street page. These are non-obvious behavioral facts an agent could not get from the schema.
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?
It is a single compact sentence with the resource front-loaded, but the nested parenthetical about the 8-sale floor-area rule is dense and hard to parse on first read. Content earns its place, but the packing harms 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?
With 7 parameters, no output schema, and no required fields, the description carries the return-value burden reasonably: it discloses the fields (sales, median price per m², url) and the 5-sale page-eligibility rule. It does not fully describe the response shape (e.g., how a street is identified or units), leaving a small gap.
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 lat/lng, limit, place, address, and radius_m. The description adds meaning only to the order modes (explaining that 'falling'/'rising' compare the latest 24 months against the prior 24) and touches the 5-year price window; otherwise it stays at the baseline set by the 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?
The description specifies the resource (streets around a place) and the payload (recorded DVF sales and median price per m² over 5 years), with the street-level granularity clearly implied by name and text. It stops short of naming competing siblings like property_prices or recent_sales, so an agent must infer the geographic-grain difference 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?
No when-to-use context is given relative to the nine sibling tools; the reader is not told why to pick street-level ranking over property_prices or recent_sales. The ordering options are described but that is invocation detail, not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
home_loanptzrank_communesappraise_listing3 fields changedInput schema / properties / by_user / descriptionPrevious value: -"\"new_build\", \"sea\" or \"new_build,sea\": what the user said themselves (it then beats the address's view and is shown as theirs)."New value: +"\"new_build\", \"sea\", \"energy\" or several joined by commas: what the user said themselves (it then beats the address's view and the words, and is shown as theirs)."Input schema / properties / description / descriptionPrevious value: -"The listing's description: its words tell a new home and a view of the sea."New value: +"The listing's description: its words tell a new home, a view of the sea and the energy label."Input schema / properties / energyAdded value: +{
+ "description": "Its energy label (DPE), when the listing gives it; \"none\": unknown (with by_user, the words are then not read).",
+ "enum": [
+ "A",
+ "B",
+ "C",
+ "D",
+ "E",
+ "F",
+ "G",
+ "none"
+ ],
+ "type": "string"
+}appraise_listing5 fields changedInput schema / properties / by_userAdded value: +{
+ "description": "\"new_build\", \"sea\" or \"new_build,sea\": what the user said themselves (it then beats the address's view and is shown as theirs).",
+ "type": "string"
+}Input schema / properties / descriptionAdded value: +{
+ "description": "The listing's description: its words tell a new home and a view of the sea.",
+ "type": "string"
+}Input schema / properties / new_buildAdded value: +{
+ "description": "Whether the home is new (sold off-plan or never lived in), when the listing says; otherwise its title and description decide.",
+ "type": "boolean"
+}Input schema / properties / seaAdded value: +{
+ "description": "Its view of the sea, when known: the sun goes down into it, the sea is seen, or none; otherwise its address's view, then its description, decide.",
+ "enum": [
+ "sunset",
+ "sea",
+ "none"
+ ],
+ "type": "string"
+}Input schema / properties / titleAdded value: +{
+ "description": "The listing's title.",
+ "type": "string"
+}copro_at_addressfind_place1 field changedInput schema / properties / query / descriptionPrevious value: -"City, city start or postcode."New value: +"City, its start, a word of its name (\"Hardelot\" for Neufchâtel-Hardelot) or postcode."amenities_nearby1 field changedInput schema / properties / place / descriptionPrevious value: -"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\", \"SW1A\"); with address, the place it is in. Ignored when lat and lng are given."New value: +"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\"); with address, the place it is in. Ignored when lat and lng are given."appraise_listing1 field changedInput schema / properties / place / descriptionPrevious value: -"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\", \"SW1A\"); with address, the place it is in. Ignored when lat and lng are given."New value: +"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\"); with address, the place it is in. Ignored when lat and lng are given."commune_profile1 field changedInput schema / properties / place / descriptionPrevious value: -"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\", \"SW1A\"); with address, the place it is in. Ignored when lat and lng are given."New value: +"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\"); with address, the place it is in. Ignored when lat and lng are given."crime_stats1 field changedInput schema / properties / place / descriptionPrevious value: -"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\", \"SW1A\"); with address, the place it is in. Ignored when lat and lng are given."New value: +"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\"); with address, the place it is in. Ignored when lat and lng are given."property_prices1 field changedInput schema / properties / place / descriptionPrevious value: -"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\", \"SW1A\"); with address, the place it is in. Ignored when lat and lng are given."New value: +"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\"); with address, the place it is in. Ignored when lat and lng are given."recent_sales1 field changedInput schema / properties / place / descriptionPrevious value: -"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\", \"SW1A\"); with address, the place it is in. Ignored when lat and lng are given."New value: +"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\"); with address, the place it is in. Ignored when lat and lng are given."sales_at_address1 field changedInput schema / properties / address / descriptionPrevious value: -"Street address, with its postcode or city unless place gives it (e.g. \"17 rue Gambey, 75011 Paris\", \"Słupska 44C, Warszawa\")."New value: +"Street address, with its postcode or city unless place gives it (e.g. \"17 rue Gambey, 75011 Paris\")."sea_views1 field changedInput schema / properties / place / descriptionPrevious value: -"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\", \"SW1A\"); with address, the place it is in. Ignored when lat and lng are given."New value: +"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\"); with address, the place it is in. Ignored when lat and lng are given."street_prices1 field changedInput schema / properties / place / descriptionPrevious value: -"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\", \"SW1A\"); with address, the place it is in. Ignored when lat and lng are given."New value: +"City, city start or postcode (e.g. \"Carnac\", \"Paris 11e\", \"75011\"); with address, the place it is in. Ignored when lat and lng are given."amenities_nearbyappraise_listingcommune_profilecrime_statsfind_placeproperty_pricesrecent_salessales_at_addresssea_viewsstreet_pricesFrench real estate data: cadastre, DVF sales, DPE energy ratings, price estimates, parcel context
French address intelligence: 18.6M sold prices, energy, risk, crime and schools — each sourced.
Données immobilières DVF France : transactions, comparables GPS et statistiques de marché.
French real-estate intelligence: prices, rents, listings, yield, rental management.
Add one secure layer between your agents and this server.
