Is this listing too expensive? French property sales (DVF), crime, rents, risks, schools
Scored across 11 tools
Most tools have clearly distinct scopes: place resolution, radius price aggregates, recent sales, address-level sales, street rankings, commune statistics, crime, copropriété records, amenities, sea views, and listing appraisal. The main overlap is that appraise_listing aggregates outputs also available through several specialist tools, and the sales/price tools differ mainly by radius/address/street granularity, but their descriptions make the boundaries mostly clear.
All names use consistent snake_case, which is predictable and readable. Most are noun-based resource names while appraise_listing and find_place are verb-led actions, so the set is not a pure verb_noun convention but the deviation is minor.
Eleven tools is well within the appropriate range for a French property due-diligence server. Each tool covers a distinct analytical layer, and none feels redundant enough to remove.
The surface covers valuation, comparables, commune profiles, taxes, risks, crime, copropriété data, amenities, sea views, and financing. Minor gaps exist because some data such as energy, tax, risk, and financing details are embedded inside appraise_listing or commune_profile rather than exposed as standalone tools, but agents can still work around this.
Schools (maternelle, primaire, collège/lycée), bakeries, night clubs, noisy bars and every bar or café within a radius (France), and golf courses within 3 km (a point in a home's favour): 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 declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds real context beyond that: the France scoping, the special rule that golf courses are evaluated at a fixed 3 km, and the fact that results are per-kind counts plus nearest instances (important since no output schema exists). Gaps remain around unresolved-place behavior and any rate limits.
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 no filler, but the core action is buried at the end after a long category list and three parentheticals, so front-loading is weak. The heavy nesting makes it harder to parse than a two-clause split would be.
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 read-only, idempotent query with no output schema, the description adequately conveys what is returned (counts per kind plus nearest ones) and the domain scope. Missing details are minor: behavior when 'place' cannot be resolved and confirmation that all categories are France-limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by distinguishing scope: the radius applies to the schools/bars/cafés categories in France, while golf courses are measured at a fixed 3 km — a nuance the radius_m field alone does not convey. It adds nothing about lat/lng/place/address beyond what the schema already documents.
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 enumerates the exact resources covered (schools, bakeries, night clubs/noisy bars, cafés, golf courses) and states the output shape ('count per kind and the nearest ones'), so the agent knows this is a proximity/amenity-count tool rather than a price or safety tool. It does not explicitly name a sibling it differs from, though the nuisance framing implicitly separates it from crime_stats and sea_views.
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 alternatives, and no prerequisites or exclusions. The only implicit guidance is the parenthetical '(a point in a home's favour)' for golf courses, which hints at relevance but not at selection between this and crime_stats or commune_profile.
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) 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 already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), so the bar is lower, yet the description adds substantial behavioral context: comparables more than 2.5x off the median price/m² are excluded as 'no market price', a 500 m amenity radius, a specific rate source and month for financing, and inferred attributes marked 'unverified'. It stops short of any latency, rate-limit, or failure-mode disclosure, but the added operational detail is well above the annotation baseline.
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 gigantic run-on sentences with deeply nested parentheses pack dozens of clauses each; the reader cannot scan for the core purpose or the parameter interactions. The content is largely informative, but the structure is hostile to an agent trying to extract the one or two facts it needs, and nothing is front-loaded beyond the first clause.
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 carries the full return-value burden, and it does so exhaustively: estimate with IQR, gap and verdict, comparable set, French headline phrasing, trend, crime rates, rent and gross yield, DPE passoire share, natural risks, local tax rates, internet and per-operator 4G, 500 m amenities, sea view, and a financing breakdown. An agent knows exactly what it will get back.
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 genuinely enriches parameter meaning: it explains fallback precedence (by_user beats the address's view, which beats the words; title/description supply DPE, new-build, and sea), and clarifies that type drives comparability ('others compare with every sale'). This is meaning the schema does not fully carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb and resource — comparing a French listing's asking price with recent DVF sales of the same type and size — and enumerates the appraisal outputs (estimate, IQR, gap, verdict, headline). It is unmistakably an aggregate valuation tool rather than a raw-data sibling, though the distinguishing scope is buried rather than stated as a positioning claim.
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 when-to-use statement and no routing against the many siblings (property_prices, recent_sales, sales_at_address, sea_views, crime_stats, amenities_nearby), even though this tool aggregates all of them. The agent must infer from the output list that this is the 'all-in-one appraisal' tool, which is exactly the kind of inference a usage section should remove.
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: 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), 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, and openWorldHint=false, so the safety profile is clear. The description adds substantial context about data sources, timeframes, and caveats (e.g., G-rated passoires may not be let since 2025, F from 2028; TEOM null where a fee pays for it; copper_closed means no new subscribers). This goes well beyond the annotations, but it doesn't discuss return format, pagination, or rate limits.
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, extremely long sentence packed with nested details, making it hard to parse. It is not front-loaded; the core purpose is buried in an exhaustive list of data points. While information-dense, it lacks structure and readability, which harms its utility.
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 complexity of the tool (5 optional parameters, no output schema) and the breadth of data it returns, the description is fairly complete. It covers all major data categories and includes important caveats. However, it doesn't explain how the different inputs (lat/lng vs place/address/commune) interact beyond what the schema notes, nor does it clarify prioritization when multiple inputs are given.
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 parameters thoroughly. The description only mentions 'by name, INSEE code or position' but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is extremely specific about what the tool returns: rents, energy ratings, natural risks, local taxes, sales prices, and internet coverage for a French commune. It clearly states the verb (spelling out what data is fetched) and the resource. It doesn't explicitly differentiate from siblings like property_prices or recent_sales, though the breadth of the 'commune profile' distinguishes it in practice.
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's no explicit guidance on when to use this tool versus alternatives like property_prices or crime_stats. The description implies it's a comprehensive profile tool, but it doesn't tell the agent when to choose this over more focused siblings, nor does it provide exclusion criteria.
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.
Median sale price and price per m² of recorded sales within a radius, overall, per property type and per year, 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that figures derive from recorded sales over a bounded historical window, hinting at data-recency limits, but says nothing about empty/sparse results, latency, or how the radius cap behaves in practice.
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 with no filler, front-loaded on the returned metrics before the breakdown dimensions. The trailing phrase 'over the last years of data' is slightly imprecise, but nothing is wasted or repeated.
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 does reasonably well: it states the metrics and the groupings returned. It stops short of describing result shape (counts, per-type/per-year nesting) or behavior when no sales are recorded in the radius, which is the main remaining gap for a zero-required-parameter aggregate query.
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 every parameter (lat/lng, place, address, type, years, radius_m) is already documented with defaults and bounds in the schema. The description's 'within a radius' and 'per property type and per year' merely echo those parameters, adding no syntax or precedence detail 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 names the concrete returned metrics (median sale price and price per m²) and the aggregation axes (overall, per property type, per year), which is far more specific than the title's vague 'prices around a place'. It does not however differentiate itself from close siblings such as street_prices, recent_sales or sales_at_address, which also concern recorded 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?
There is no when-to-use guidance and no mention of alternatives, even though the sibling list contains three overlapping sales tools (recent_sales, sales_at_address, street_prices). The only implicit cue is 'within a radius', leaving the agent to infer that this is the aggregated-statistics variant rather than the raw-listing variant.
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_communeshome_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 property data: cadastral parcels, DVF sales, DPE, PLU zoning, permits, legal owners
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é.
Add one secure layer between your agents and this server.
