DeepPVMapper

search_detections

Filter rooftop solar PV detections by French department, commune, capacity, and cross-validation confidence, then return records with a sample quality summary.

Instructions

Search individual rooftop-PV detections by département, commune (INSEE code), estimated capacity range, and/or cross-validation confidence (min_vintages, cross_validated). Returns a bounded list of detection records plus a quality_summary for the returned sample (use get_detections_in_bbox instead for map/spatial queries with geometry). Data quality note: this is a detection dataset, not an exhaustive inventory (estimated recall ~0.6). A missing detection does not mean no PV installation exists there. kwp, surface, tilt and azimuth are model estimates, not surveyed values. In this server, quality_filter=true keeps only detections identified by 2 or more sources (see source_encoding in get_data_quality_reference). Call get_data_quality_reference for the full picture before assessing fitness for a specific use case.

Input Schema

Name	Required	Description
`dpt`	No	French département code, e.g. "33".
`insee`	No	INSEE commune code.
`limit`	Yes	Maximum number of records to return (max 200).
`max_kwp`	No	Maximum estimated installed capacity, in kWp.
`min_kwp`	No	Minimum estimated installed capacity, in kWp.
`max_tilt`	No	Maximum estimated tilt from horizontal, in degrees.
`min_tilt`	No	Minimum estimated tilt from horizontal, in degrees.
`has_rnb_id`	No	true = only detections matched to an RNB building identifier (rnb_id not null); false = only detections without one.
`max_azimuth`	No	Maximum estimated azimuth, degrees clockwise from true north (180 = south).
`max_surface`	No	Maximum estimated PV array area, in m².
`min_azimuth`	No	Minimum estimated azimuth, degrees clockwise from true north (180 = south).
`min_surface`	No	Minimum estimated PV array area, in m².
`max_vintages`	No	Maximum number of imagery vintages (e.g. 1 = seen in a single year only).
`min_vintages`	No	Minimum number of distinct imagery vintages (years) the installation was independently detected in. Use 2+ as a persistence/confidence signal, since a one-off detection in a single vintage is more likely to be a transient artifact.
`max_last_seen`	No	Upper bound on last_seen imagery year.
`min_last_seen`	No	Lower bound on last_seen imagery year.
`has_frpv_proba`	No	true = only detections that have an FRPV comparison (frpv_proba not null); false = only those without one. A null frpv_proba means "no comparison available", not probability 0.
`max_first_seen`	No	Upper bound on first_seen imagery year.
`min_first_seen`	No	Earliest imagery year of first detection, lower bound (e.g. 2018). Not an installation date.
`min_frpv_proba`	No	Minimum frpv_proba. The data contract recommends 0.1 as a precision/recall trade-off. Note: detections with a null frpv_proba (no FRPV comparison available) are excluded when this is set; null does not mean probability 0.
`quality_filter`	Yes	If true, only include detections identified by 2 OR MORE sources(the `sources` field lists at least two codes, e.g. "0,1" = DeepPVMapper pipeline + FRPV reference, "0,2" = pipeline + OpenStreetMap). Default false: all detections are included, including those found by a single source (typically the automated pipeline alone).
`cross_validated`	No	Alias of quality_filter, kept for backward compatibility.
`sources_include`	No	Only include detections present in ALL of these sources. Accepts names or codes, case-insensitive: dpvm/deeppvmapper/kasmi (0), frpv/thebault (1), osm/openstreetmap (2), manual/annotation (3), recall (4). Examples: ["osm"] = detections that are in OpenStreetMap; ["dpvm","frpv"] = present in both DeepPVMapper and FRPV. See get_source_reference for what each source is and where it comes from.
`false_positive_status`	No	flagged = false_positive is true; not_flagged = false_positive is false; unrecorded = false_positive is null (no status recorded — NOT a confirmed true positive).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 18, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does it well: it warns the dataset is a detection set with ~0.6 recall, that a missing detection is not evidence of no PV, that kwp/surface/tilt/azimuth are model estimates, and that it returns a quality_summary alongside a bounded record list. It does not cover auth, rate limits, or pagination behavior, so it stops short of a 5.

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 core purpose and filters, then the routing alternative, then a compact data-quality caveat block. Every sentence earns its place, though the final pointer sentence is a slightly soft close and the caveat block is on the long side.

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 24-parameter tool with no output schema, the description covers the return shape at a high level (bounded record list plus quality_summary) and supplies the caveats an agent needs to interpret results honestly. It is close to complete; it could say more about how limit interacts with the quality_summary and whether results are ordered or paginated.

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 the baseline is 3, but the description adds interpretive framing beyond the schema: it groups the filters into semantic families and explains how quality_filter relates to the 2-plus-source rule and to cross_validated. That helps an agent choose filter values rather than merely pass them through.

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 ('Search individual rooftop-PV detections') and enumerates the discriminating filter families (département, INSEE commune, capacity range, cross-validation confidence). It also explicitly names the sibling it is not, get_detections_in_bbox, for spatial queries, so an agent can separate the two without opening either 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 alternative and the condition that selects it ('use get_detections_in_bbox instead for map/spatial queries with geometry'), and routes the agent to get_data_quality_reference before assessing fitness. It also frames min_vintages/cross_validated as confidence-tuning levers, so the when-to-use surface is complete.

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

Deploy Server

search_detections

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools