Skip to main content
Glama
EuroScrape

EuroScrape MCP server

Official
by EuroScrape
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

France Real Estate Sold Prices (DVF): €/m², Sales & Trends

get_france_property_sales
Read-only

Fetch official French property sales data by city or postal code, including price paid, price per m2, surface, rooms, dates, energy class and median price summaries.

Instructions

Real property sales in France (official DVF data) for a city or postal code: price paid, price per m2, surface, rooms, date, with the energy class of the home when known and a median price summary. Pay per result on your Apify account: run start $0.003, property sale $0.0005.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearsNoSale years to load, between 2021 and 2025 (the State publishes DVF data with a few months of delay, in April and October).
locationsNoFrench cities, postal codes or INSEE codes: "Grenoble", "Paris", "38000", "33063"… Paris, Lyon and Marseille automatically cover all their arrondissements.
maxSurfaceNoKeep sales up to this living surface.
minSurfaceNoKeep sales with at least this living surface.
propertyTypesNohouse, apartment, commercial, land, outbuilding.
includeRentalYieldNoFor each sale: the State's asking-rent indicator of the commune for a typical home of that kind (Carte des loyers, charges included), and the gross yield it implies at the real sale price. The free summary gives median yields per city and ranks communes or arrondissements. Free, no extra time.
includeEnergyRatingNoMatches each sale to its official energy performance certificate (ADEME open data): energy class A-G, CO2 class, kWh/m²/year and certificate date. Free. A class is only attached when the address, property type, surface and date agree; about one sale in two gets one.
maxSalesPerLocationNoMost recent first. Summary statistics still use ALL matching sales. Default here: 50.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context beyond structured fields: an explicit pay-per-result pricing model (run start $0.003, $0.0005 per sale), which is actionable operational information for an Apify actor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose and output fields, with the pricing note parked at the end. Dense but every clause adds information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 fully-documented parameters, no output schema, and read-only annotations, the description covers what the tool returns, its geographic scope, and its cost model. Nothing essential for correct invocation is missing, though return-format and volume expectations are left to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 8 parameters in detail (year ranges, INSEE codes, surface filters, yield/energy flags). The description adds little parameter-level meaning beyond restating that a city or postal code is the target. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource (real property sales in France, official DVF data) plus the returned fields (price paid, price per m2, surface, rooms, date, energy class, median summary). This is clear enough to distinguish from generic data tools, though it never explicitly distinguishes itself from France-specific siblings like get_france_building_permits or get_france_energy_ratings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the scope ('for a city or postal code') but gives no when-to-use/when-not guidance and names no alternative among the France siblings. The agent must infer usage from the domain alone.

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

Deploy Server

Other Tools