HelpMyAgent

French Real-estate Transactions

real_estate_fr_transactions

Searches published French geolocated DVF property transactions by address area or municipality, with date, type and amount filters. Use when: Find actual French property sales around an address or in a municipality. Avoid when: Do not use for current property listings or asking prices. Limitations: Geolocated DVF reflects published transactions and can include complex mutations; HelpMyAgent only calculates price per square metre for single-house or single-apartment mutations. DVF does not cover Alsace, Moselle or Mayotte; requests in those areas therefore return an empty result. Price: 0.010 USD per call via x402. Paid-call behavior: source records are not modified, but a successful invocation can consume the advertised x402 payment; the payment-required challenge is free, and repeating the tool after a completed paid invocation may require a new payment. Accepted x402 networks: eip155:8453, xrpl:0.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of records returned by this call. (minimum 1; maximum 100; default 20).
`address`	No	Optional value for “address” as defined by this API contract. (minimum length 5; maximum length 250).
`date_to`	No	Optional value for “date to” as defined by this API contract.
`radius_m`	No	Optional value for “radius m” as defined by this API contract. (minimum 100; maximum 650; default 500).
`date_from`	No	Optional value for “date from” as defined by this API contract.
`code_insee`	No	Optional value for “code insee” as defined by this API contract.
`max_amount`	No	Optional value for “max amount” as defined by this API contract. (minimum 0).
`min_amount`	No	Optional value for “min amount” as defined by this API contract. (minimum 0).
`property_type`	No	Optional value for “property type” as defined by this API contract. (default all; allowed values: all, house, apartment).	all

Output Schema

TableJSON Schema

Name	Required	Description
`location`	Yes	Structured value returned for “location” as defined by this API contract.
`radius_m`	Yes	Structured value returned for “radius m” as defined by this API contract.
`truncated`	Yes	Whether additional matching records existed beyond the returned result limit.
`limitations`	No	Known interpretation, source-coverage or freshness limitations for this result.
`generated_at`	Yes	UTC timestamp at which this derived result was generated.
`transactions`	Yes	Structured value returned for “transactions” as defined by this API contract.
`property_type`	Yes	Structured value returned for “property type” as defined by this API contract.
`source_status`	Yes	Availability status of the relevant upstream public source. (allowed values: ok).
`coverage_scope`	Yes	Structured value returned for “coverage scope” as defined by this API contract. (allowed values: radius, commune).
`returned_count`	Yes	Number of records included in this response.
`source_total_count`	Yes	Structured value returned for “source total count” as defined by this API contract.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 16, 2026

changedOutput schema / required

Previous value: -[
-  "location",
-  "coverage_scope",
-  "radius_m",
-  "property_type",
-  "source_status",
-  "source_total_count",
-  "returned_count",
-  "truncated",
-  "transactions",
-  "generated_at",
-  "limitations"
-]New value: +[
+  "location",
+  "coverage_scope",
+  "radius_m",
+  "property_type",
+  "source_status",
+  "source_total_count",
+  "returned_count",
+  "truncated",
+  "transactions",
+  "generated_at"
+]

AddedSep 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Despite all annotations being false, the description discloses critical behavioral aspects: paid-call behavior via x402, that source records are not modified, the payment-required challenge is free, and repeat calls may require new payment. It also explains the price per sqm limitation and empty results for excluded areas, going well beyond annotations.

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?

The description is well-structured with clear sections (purpose, use/avoid, limitations, pricing, paid-call behavior). It is slightly long but each section serves a purpose, especially given the payment details. The main purpose is front-loaded.

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

Completeness5/5

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

Given 9 parameters, no annotation hints, and an output schema present, the description covers essential operational details: what data is returned (transactions), geographic exclusions, payment implications, and the price-per-sqm limitation. It is comprehensive enough for an agent to call correctly, with output format delegated to the schema.

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

Parameters4/5

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

Schema coverage is 100%, so parameters are documented. The description adds meaningful context by clarifying that searching is by address area or municipality and that date, type, and amount filters are available, which maps to specific parameters. This adds value beyond the generic schema descriptions, though not exhaustive.

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?

The description states a specific verb ('Searches') with a clear resource ('published French geolocated DVF property transactions') and lists key filters (date, type, amount). It clearly distinguishes from sibling tools like real_estate_fr_market or real_estate_fr_valuation by focusing on transactions.

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?

Explicitly provides 'Use when' and 'Avoid when' conditions, naming the exact use case (actual sales around an address or municipality) and the exclusion (current listings/asking prices). It also highlights limitations (areas not covered) to prevent misuse.

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

All HelpMyAgent tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?