DeepPVMapper

count_detections

Get exact counts of DeepPVMapper detections matching filters without downloading rows. Returns matching totals and percentage for how-many questions.

Instructions

Count detections matching a set of filters, exactly, without downloading rows (fast, no row cap). Use this for "how many ..." questions, e.g. "how many installations have an RNB id?" -> has_rnb_id=true; "how many are identified by 2+ sources?" -> quality_filter=true; "how many come from OpenStreetMap?" -> sources_include=[2]. Returns the matching count, the unfiltered registry total and the percentage. Counts are DETECTED systems, not an inventory. 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.
`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.
`breakdown_rnb_id`	Yes	If true, also return how many of the matching detections do / do not have an rnb_id (ignores has_rnb_id for this breakdown).
`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.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does: exactness, the absence of a row cap, the returned values (count, unfiltered registry total, percentage), the quality_filter semantics specific to this server, the alias caveat, and substantive dataset caveats (detection dataset, recall ~0.6, model-estimated kwp/surface/tilt/azimuth). This is unusually rich behavioral disclosure for a mutation-free read tool.

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?

Well front-loaded: purpose, usage, return shape, then caveats. The data-quality block is somewhat repetitive — the 'not an exhaustive inventory' point and the 'missing detection' point restate each other, and the recall figure is duplicated in spirit by the pointer to get_data_quality_reference.

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?

For a 24-parameter tool with no annotations and no output schema, the description covers what it returns, how the two required parameters behave, the dataset's fitness caveats, and points to the reference tool for the deeper contract. Nothing an agent needs to decide whether to call it is missing.

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; the description goes beyond it by translating concrete questions into concrete parameter values (has_rnb_id=true, quality_filter=true, sources_include=[2]) and by clarifying that quality_filter means 2+ sources in this server specifically. It leaves breakdown_rnb_id and the cross_validated alias to the schema.

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 (count detections) plus a distinguishing capability: exact counting without downloading rows and without a row cap. That contrast implicitly separates it from search_detections and the other list/aggregate siblings, and the opening clause is front-loaded.

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

Usage Guidelines4/5

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

Explicitly routes 'how many ...' questions to this tool and gives three worked mappings from natural-language questions to parameters. It also tells the agent to consult get_data_quality_reference before assessing fitness. It never names the row-returning alternative (search_detections) outright, so the negative case is only implied.

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

Deploy Server

count_detections

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools