Skip to main content
Glama

Search Property Transactions

search_property_transactions
Read-only

Search French property transactions (Demandes de Valeurs Foncières).

REQUIRED: You MUST provide at least one location filter:

  • code_postal (e.g., "75011" for Paris 11e)

  • commune (e.g., "PARIS 11", "LYON", "MARSEILLE" - uppercase; Paris uses arrondissements: "PARIS 01"–"PARIS 20")

  • code_departement (e.g., "75" for Paris, "69" for Rhône)

  • latitude + longitude for radius search (e.g., 48.8566, 2.3522 for Paris center)

  • address + code_postal for automatic geocoding (e.g., address: "12 rue de Rivoli", code_postal: "75001")

Common examples:

  • Paris 11e apartments: {commune: "PARIS 11", type_local: "Appartement"}

  • Near a location: {latitude: 48.8566, longitude: 2.3522, radius_m: 500}

  • By postal code: {code_postal: "69001", type_local: "Maison"}

  • By address: {address: "12 rue de Rivoli", code_postal: "75001", radius_m: 300}

Options:

  • summary_only=true: Get stats + 3 samples (~500 tokens vs ~3500 for full results) — use this for overviews. The stats cover every matching sale, identical to analyze_market_statistics (same date cap), unless prix_*/surface_*/pieces_min filters are set: then summary.basis = "sample" and they describe the returned page only.

  • limit: 1-100 results (default: 5)

  • type_local: "Appartement", "Maison", "Terrain", "Local commercial"

Note: radius_m > 1000m is automatically restricted to the last 12 months of data.

Cost: 5 credits per call

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_property_transactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of results (default: 5)
offsetNoOffset for pagination
addressNoStreet address for automatic geocoding — alternative to explicit lat/lon. Example: '12 rue de Rivoli'. Best used with code_postal for precision. Resolves via api-adresse.data.gouv.fr.
communeNoCity/commune name (e.g., 'Paris', 'Lyon')
date_finNoEnd date (YYYY-MM-DD)
latitudeNoLatitude for radius search (requires longitude)
prix_maxNoMaximum price in EUR
prix_minNoMinimum price in EUR
radius_mNoRadius in meters for location search (default: 500)
longitudeNoLongitude for radius search (requires latitude)
date_debutNoStart date (YYYY-MM-DD)
pieces_minNoMinimum number of rooms
type_localNoProperty type
code_postalNoPostal code (e.g., '75001')
deduplicateNoGroup duplicate sales (same date, address, price) into single entries
surface_maxNoMaximum surface area in m²
surface_minNoMinimum surface area in m²
exclude_vefaNoExclude VEFA (new-build, vente en l'état futur d'achèvement) sales (default: true — keeps 'ancien' results from double-counting new-build activity)
summary_onlyNoReturn only summary statistics with 3 sample transactions instead of full list (reduces context usage)
code_departementNoDepartment code (e.g., '73' for Savoie, '83' for Var)
use_original_typeNoUse original type_local instead of smart computed_type_local (default: false)
exclude_bulk_salesNoExclude bulk sales and aggregated transactions (default: true for clean market data)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / exclude_outliers
      Removed value: -{
      -  "default": true,
      -  "description": "Exclude price outliers (default: true for clean market data)",
      -  "type": "boolean"
      -}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses a cost of 5 credits, the hidden rule that radius_m > 1000m is silently truncated to the last 12 months, the ~500 vs ~3500 token tradeoff for summary_only, and the critical caveat that summary.basis flips to 'sample' when prix_*/surface_*/pieces_min filters are applied. These are behaviors an agent could not recover from annotations or schema and that materially affect whether results are trustworthy.

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?

Front-loaded with the hard requirement, then examples, then options — a structure that lets an agent stop reading early. It loses a point for restating structured data the schema already carries verbatim (the type_local enum values and the limit 1-100/default 5 range).

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?

For a 22-parameter tool with no output schema, it covers the invocation-side gaps well (filter requirement, formats, defaults, cost, radius restriction) and hints at return shape via 'stats + 3 samples'. It is thinner on what a full result record actually contains and on pagination via offset, which an agent must infer from the schema alone.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely non-obvious semantics: commune values must be uppercase with Paris expressed as arrondissements ("PARIS 01"–"PARIS 20"), radius_m has a 12-month behavioral side effect, and summary_only changes the meaning of the returned statistics. It does not document every one of the 22 parameters, but it explains the ones whose format or side effects the schema does not convey.

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

Purpose5/5

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

States a specific verb and resource plus the underlying dataset (Demandes de Valeurs Foncières), and repeatedly anchors itself against the sibling analyze_market_statistics when explaining summary_only. An agent can distinguish this record-level search from the aggregate-statistics sibling without opening a schema.

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

Usage Guidelines5/5

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

Gives an explicit precondition (at least one location filter) and enumerates the five mutually interchangeable filter modes, including the geocoding alternative of address + code_postal versus raw lat/lon. Four concrete call examples and an explicit 'use summary_only for overviews' rule remove the main routing ambiguities.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources