Skip to main content
Glama
gabrielkasmi

DeepPVMapper

by gabrielkasmi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

aggregate_detection_capacity

Sum estimated installed PV capacity (kWp) and count detections for filters like département, commune, capacity range, or cross-validation across sources and imagery vintages.

Instructions

Compute the total estimated installed capacity (kWp) and count of detections matching a set of filters — département, commune, capacity range, and cross-validation across sources (cross_validated) or imagery vintages (min_vintages) — plus a quality_summary for the summed sample. Unlike get_department_capacity_stats, which is a fixed pre-computed département-wide aggregate with no other filters, this tool sums a live filtered subset, up to max_rows detections. Example: "installed capacity in Gironde confirmed by at least two sources" -> dpt="33", cross_validated=true. 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

NameRequiredDescriptionDefault
dptNoFrench département code, e.g. "33".
inseeNoINSEE commune code.
max_kwpNoMaximum estimated installed capacity, in kWp.
min_kwpNoMinimum estimated installed capacity, in kWp.
max_rowsYesCap on the number of matching detection rows fetched to compute the capacity sum. If the true match count exceeds this, total_kwp is a partial lower bound and `truncated` is true — increase max_rows or narrow the filters (e.g. add dpt or insee) for an exact total.
max_tiltNoMaximum estimated tilt from horizontal, in degrees.
min_tiltNoMinimum estimated tilt from horizontal, in degrees.
has_rnb_idNotrue = only detections matched to an RNB building identifier (rnb_id not null); false = only detections without one.
max_azimuthNoMaximum estimated azimuth, degrees clockwise from true north (180 = south).
max_surfaceNoMaximum estimated PV array area, in m².
min_azimuthNoMinimum estimated azimuth, degrees clockwise from true north (180 = south).
min_surfaceNoMinimum estimated PV array area, in m².
max_vintagesNoMaximum number of imagery vintages (e.g. 1 = seen in a single year only).
min_vintagesNoMinimum 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_seenNoUpper bound on last_seen imagery year.
min_last_seenNoLower bound on last_seen imagery year.
has_frpv_probaNotrue = 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_seenNoUpper bound on first_seen imagery year.
min_first_seenNoEarliest imagery year of first detection, lower bound (e.g. 2018). Not an installation date.
min_frpv_probaNoMinimum 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_filterYesIf 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_validatedNoAlias of quality_filter, kept for backward compatibility.
sources_includeNoOnly 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_statusNoflagged = 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.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does disclose substantive behavior: the dataset is a detection dataset with ~0.6 recall rather than an exhaustive inventory, missing detections do not imply absence of PV, and kwp/surface/tilt/azimuth are model estimates. It also surfaces the max_rows truncation caveat (partial lower bound) and that cross_validated is an alias of quality_filter. It stops short of cost/latency or permissions context, so not 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 the sibling contrast before moving to example, data-quality caveats, and the reference pointer. It is on the long side and partially repeats what the schema already says (quality_filter semantics, cross_validated alias, truncation), which costs it a point, but each sentence carries information.

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 and no annotations, the description supplies the essential caveats an agent needs: the detection-vs-inventory framing, recall figure, model-estimate status of key metrics, and the truncation/partial-total behavior. It is reasonably complete, with only minor gaps around result shape and the semantics of the quality_summary it mentions.

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 description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by tying filters together into a worked example and clarifying in prose that quality_filter=true means 'identified by 2 or more sources' and that cross_validated is a backward-compat alias. It doesn't re-derive every one of the 24 parameters, which is appropriate given the schema already documents them.

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+resource (compute total estimated installed capacity and count of matching detections) and enumerates the filter dimensions that define the subset. It explicitly distinguishes itself from the sibling get_department_capacity_stats (fixed pre-computed aggregate, no filters) versus this tool's live filtered sum, so an agent can route between them 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 explicit when-to-use-vs-alternative guidance by contrasting with get_department_capacity_stats, supplies a concrete worked example ("installed capacity in Gironde confirmed by at least two sources" -> dpt="33", cross_validated=true), and names the prerequisite reference tool (get_data_quality_reference) for fitness assessment. Nothing is left to inference.

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