Open registry of 1.14M+ rooftop-solar detections across France, queryable by natural language.
Scored across 8 tools
Most tools have clearly distinct purposes, and the descriptions explicitly contrast similar pairs like aggregate_detection_capacity vs. get_department_capacity_stats and search_detections vs. get_detections_in_bbox. However, an agent might briefly hesitate between the two capacity-aggregation tools or the two detection-list tools before reading the fine print.
All tool names follow a consistent snake_case verb_noun pattern, with get_* used for retrieval and search_/aggregate_ used for query-like operations. The naming is predictable and scannable, with no mixed conventions or vague standalone verbs.
Eight tools is well-scoped for a PV-detection data server: spatial search, attribute search, aggregation, departmental stats, yearly trends, community contributions, and data-quality reference. Each tool covers a distinct query mode without redundancy or bloat.
The surface covers the core read-only domain well: search, spatial query, aggregation, departmental statistics, yearly trends, community contributions, and quality documentation. Minor gaps exist, such as no direct fetch-by-ID tool and no detailed per-commune stats endpoint, but agents can compose existing tools to work around these.
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. Call get_data_quality_reference for the full picture before assessing fitness for a specific use case.
| Name | Required | Description | Default |
|---|---|---|---|
| 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_rows | Yes | Cap 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. | |
| 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. | |
| quality_filter | Yes | If true (default), only include detections with frpv_proba >= 0.1, the threshold recommended in the data contract for a good precision/recall trade-off. | |
| cross_validated | No | If true, only include detections confirmed by at least two independent sources (e.g. the automated DeepPVMapper pipeline plus OpenStreetMap or the FRPV reference dataset), not just a single pipeline. This is a stronger confidence signal than min_vintages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and meets it: it reveals that the result is a live sum capped by max_rows, and discloses two non-obvious data traits — estimated recall ~0.6 with missing detections not implying absence, and kwp/surface/tilt/azimuth being model estimates rather than surveyed values. This materially prevents misinterpretation of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: core purpose, sibling contrast, worked example, then data-quality caveats. The main statement is front-loaded, and the length is justified by the tool's complexity and the absence of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter aggregation tool with no annotations and no output schema, the definition is remarkably complete: it covers what is computed, how to filter, the truncation cap (with schema detail), output components (quality_summary, total_kwp, truncated), and essential data caveats, and points to get_data_quality_reference for the full quality picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value on top by grouping the eight parameters into filter categories (département, commune, capacity range, cross-validation, vintages) and by running a worked example that maps 'confirmed by at least two sources' to cross_validated=true, which helps an agent translate a request into parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Compute the total estimated installed capacity (kWp) and count of detections') and enumerates the supported filters. It also differentiates from get_department_capacity_stats by contrasting a live filtered subset with a fixed pre-computed aggregate, so an agent can distinguish the siblings at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative get_department_capacity_stats and the condition that selects it (fixed pre-computed aggregate with no filters vs live filtered sum), provides a concrete natural-language-to-parameter example (dpt="33", cross_validated=true), and directs the agent to get_data_quality_reference before assessing fitness for a use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a snapshot of ongoing community contribution activity on the map: how many corrections are currently pending moderation, their breakdown by action type (add / modify / delete), and the most recent submissions (timestamp, action, target). Submitted free-text comments are intentionally excluded from this tool. This reflects unmoderated, unverified user activity, not the registry itself — do not present it as confirmed detection data.
| Name | Required | Description | Default |
|---|---|---|---|
| recent_limit | Yes | How many of the most recent pending contributions to list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does this well by stating that comments are intentionally excluded and that the data reflects unmoderated, unverified user activity rather than the authoritative registry. This goes beyond a simple 'get' description. It could still mention that this is a read-only operation with no side effects, but the snapshot framing largely conveys that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the purpose and enumerates the output contents, and the following sentences provide important limitations and usage caveats. There is no filler or redundant information; every sentence contributes to correct invocation and interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides enough information for an agent to understand what data will be returned and how to interpret it. It clearly lists the three output categories and includes the critical caveat about unverified data. The only notable gap is the lack of an explicit relationship to the area-scoped sibling tool, but this is not essential for basic correctness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, recent_limit, is already fully documented in the schema with description, default, maximum, and exclusivity constraints. The tool description does not add new parameter semantics, but it does not need to because the schema coverage is 100%. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get a snapshot') and the resource ('community contribution activity'), and it enumerates the specific outputs: pending correction counts, breakdown by action type, and recent submissions. It also distinguishes this from the registry by emphasizing unmoderated, unverified user activity. However, it does not explicitly differentiate itself from the nearby sibling get_community_activity_in_area, so the distinction is mostly inferable rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context about when to use this tool: it returns unmoderated, unverified contribution activity and explicitly warns not to present it as confirmed detection data. It also notes that free-text comments are intentionally excluded. However, it does not explicitly state when to use this tool instead of a sibling like get_community_activity_in_area or search_detections, so the guidance is more implied than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find pending, unmoderated community contributions relevant to a specific area, to answer "has anyone flagged anything here that is not in the registry yet?" Two independent filters: dpt finds pending edits/deletions (action=modify/delete) targeting existing detections in that département; a full bounding box (min_lon/min_lat/max_lon/max_lat) finds pending new additions (action=add) whose proposed footprint centroid falls inside it. Combine with get_department_capacity_stats / search_detections / get_detections_in_bbox for the confirmed registry picture, and present this separately and clearly as unverified, pending community input — not confirmed detection data. Free-text comments are never included.
| Name | Required | Description | Default |
|---|---|---|---|
| dpt | No | Filter pending edits/deletions of EXISTING detections (action=modify or delete) to this département. Does not apply to proposed new additions (action=add), which have no département recorded on the pending item itself — use the bbox parameters for those. | |
| max_lat | No | ||
| max_lon | No | ||
| min_lat | No | ||
| min_lon | No | ||
| scan_limit | Yes | How many recent proposed additions (action=add) to scan for a bbox match. Only relevant when all four bbox parameters are given — there is no server-side spatial index on pending items, so matching is done by fetching this many of the most recent ones and checking their centroid against the box. | |
| recent_limit | Yes | Maximum number of matching items to return per category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It compensates by explicitly labeling results as pending, unmoderated, unverified community input, and not confirmed detection data. It also discloses that free-text comments are never included and explains the different semantics of dpt-based vs. bbox-based matching. A brief explicit read-only statement would make this fully complete, but the description is already strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: purpose, filter semantics, relationship to confirmed-registry tools, and the critical presentational caveat. The most decision-relevant information is front-loaded. The prose is dense and structured so an agent can act on it without re-reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description covers nearly everything needed to call it correctly: filter modes, parameter meanings, spatial-matching approach, and how results should be framed. Minor gaps remain, such as an explicit all-or-none rule for the bbox parameters and any description of the return structure, but these are inferable from the schema and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (43%), and the four bbox parameters are undescribed in the schema. The description compensates by explaining that min_lon/min_lat/max_lon/max_lat define a full bounding box and that matching uses the proposed footprint centroid. It also clarifies that dpt applies only to modify/delete actions and not to additions. The scan_limit and recent_limit parameters are already well documented in the schema, so the prose does not need to repeat them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Find pending, unmoderated community contributions relevant to a specific area." It also gives a concrete motivating question and clearly separates this tool from the confirmed-registry tools named as siblings. The purpose is immediately distinguishable even without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to surface unverified pending community input) and explicitly names the confirmed-registry alternatives to combine with. It also states how the two filter modes are used: dpt for pending edits/deletions, bbox for pending additions. The caveat to present results separately and not as confirmed data provides a clear when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the DeepPVMapper/OpenPVMapper registry's documented data-quality characteristics: estimated detection recall, which fields are model-derived estimates vs. structural/observed fields, the source-encoding table, the recommended confidence threshold, confidence signals, and licensing/liability terms. Call this before advising how much to trust a result for a specific use case (e.g. exploratory research vs. a commercial or regulatory decision) — pair it with the quality_summary attached to search_detections / aggregate_detection_capacity results, which reflects the specific query rather than the registry as a whole.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It makes the scope explicit: this returns registry-level documented characteristics, not query-specific quality information, and it is a pure retrieval operation ('Return'). It does not discuss auth, rate limits, or error behavior, but for a zero-parameter read-only reference tool the disclosed scoping is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause earns its place: the first sentence lists the return contents, and the second provides actionable usage context. It is front-loaded with the core purpose and avoids repetition of schema or annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete: it specifies the full set of returned information, explains when to use it, and distinguishes it from query-specific alternatives. An agent has everything needed to decide whether to invoke this tool and what to expect from it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there is no parameter information for the description to add. The baseline of 4 applies because the description appropriately focuses on what the tool returns rather than trying to document nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies the exact resource (the DeepPVMapper/OpenPVMapper registry's documented data-quality characteristics), then enumerates the contents. It is clearly distinct from the sibling tools, which operate on detections, capacity, or community activity rather than registry-level quality metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call this tool ('before advising how much to trust a result for a specific use case') and contrasts it with the query-specific quality_summary attached to search_detections / aggregate_detection_capacity results. This gives an agent clear routing guidance relative to its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get installed rooftop-PV capacity (total kWp) and system counts for one or all French départements, from the DeepPVMapper/OpenPVMapper registry. This is a fixed, pre-computed department-wide aggregate with no other filters — use aggregate_detection_capacity instead if you need a filtered subset (e.g. only cross-validated detections). 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. Call get_data_quality_reference for the full picture before assessing fitness for a specific use case.
| Name | Required | Description | Default |
|---|---|---|---|
| dpt | No | French département code, e.g. "33" for Gironde. Omit for all départements. | |
| top_n | No | If set and dpt is omitted, return only the top N départements by installed capacity. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It openly states the dataset is not exhaustive (recall ~0.6), that missing detections are not proof of absence, and that key fields are model estimates rather than surveyed values. These caveats are exactly the behavioral context an agent needs before interpreting results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then names the alternative, then gives data-quality caveats in logical order. Every sentence adds necessary context for interpretation or safe use, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must supply return semantics and caveats; it does, covering kWp, system counts, recall, and estimate status. It also gives a clear next step (get_data_quality_reference), making the tool safely callable even without reading sibling schemas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because both dpt and top_n have inline descriptions. The tool description reinforces that department selection is the only real filter, but adds little beyond what the schema already documents for the parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence uses a specific verb ('Get') with a clear resource ('installed rooftop-PV capacity (total kWp) and system counts') and scope ('one or all French départements'). It explicitly differentiates itself from aggregate_detection_capacity, so an agent can distinguish it from the closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names aggregate_detection_capacity as the alternative when a filtered subset is needed, and instructs the agent to call get_data_quality_reference before assessing fitness for a specific use case. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get yearly system counts and capacity by département, based on first-seen imagery year. Useful for tracking apparent PV deployment growth over time. 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. Call get_data_quality_reference for the full picture before assessing fitness for a specific use case.
| Name | Required | Description | Default |
|---|---|---|---|
| dpt | No | French département code, e.g. "33". Omit for all départements. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it exceeds expectations: it states the dataset is detection-based with estimated recall ~0.6, warns that a missing detection does not mean no installation exists, and flags kwp/surface/tilt/azimuth as model estimates. This is substantive data-quality disclosure well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The action, use case, and caveats are front-loaded in a compact note; no sentence is wasted. The data-quality explanation earns its place because it prevents misinterpretation of the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter tool with no output schema, the description covers what is returned (yearly counts and capacity by département based on first-seen year), how to interpret estimates, and where to get context (get_data_quality_reference). No critical gap remains for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already defines dpt as a French département code with 'Omit for all département'. The description adds no parameter-level detail beyond 'by département', so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a concrete resource ('yearly system counts and capacity by département'), and a distinguishing aggregation key ('first-seen imagery year'). It is clear what the tool returns, but it does not explicitly contrast itself with the closely named sibling get_department_capacity_stats, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear use case ('tracking apparent PV deployment growth over time') and explicitly instructs the caller to consult get_data_quality_reference before assessing fitness. It does not spell out when to prefer get_department_capacity_stats or aggregate_detection_capacity instead, so exclusions and alternatives are incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get rooftop-PV detections within a geographic bounding box (WGS84 lon/lat), including footprint geometry. Intended for map-style spatial queries over a small area. 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. Call get_data_quality_reference for the full picture before assessing fitness for a specific use case.
| Name | Required | Description | Default |
|---|---|---|---|
| max_lat | Yes | ||
| max_lon | Yes | ||
| min_lat | Yes | ||
| min_lon | Yes | ||
| max_count | Yes | Maximum number of detections to return (max 500 here; the underlying API defaults to 2000, capped lower to keep responses manageable for an LLM). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does this well by candidly warning that this is a detection dataset with estimated recall ~0.6, that missing detections are not proof of absence, and that kwp, surface, tilt, and azimuth are model estimates. It does not cover response truncation, ordering, or error behavior, but the disclosed data-quality caveats are substantial and high-value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and every sentence adds value: the core purpose, the intended use, the critical recall caveat, the model-estimate warning, and the pointer to get_data_quality_reference. It is front-loaded with the action and scope and keeps secondary warnings in natural supporting positions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description names the key return aspects: footprint geometry and the attributes kwp, surface, tilt, and azimuth. It also gives a necessary caution about interpreting those values. It does not describe the response envelope or coordinate validation, but for a bbox query tool with a clear purpose and data-quality caveats, the essential context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%; only max_count is explained in the schema. The description compensates partially by specifying WGS84 lon/lat and indicating a small-area query, but it does not define the bounding-box corner semantics, coordinate order, or edge cases such as antimeridian crossing. For a tool with five required coordinate parameters, more parameter-level detail would be needed to fully bridge the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get rooftop-PV detections within a geographic bounding box (WGS84 lon/lat), including footprint geometry.' This makes the spatial scope and return content clear. It also gives an intended context ('map-style spatial queries over a small area') that distinguishes it from broader sibling tools like search_detections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when the tool is appropriate: 'Intended for map-style spatial queries over a small area.' It also explicitly directs the agent to a sibling, get_data_quality_reference, before assessing fitness for a use case. It does not fully spell out when not to use this tool versus search_detections, so it falls just short of exhaustive routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Call get_data_quality_reference for the full picture before assessing fitness for a specific use case.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| 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. | |
| quality_filter | Yes | If true (default), only include detections with frpv_proba >= 0.1, the threshold recommended in the data contract for a good precision/recall trade-off. | |
| cross_validated | No | If true, only include detections confirmed by at least two independent sources (e.g. the automated DeepPVMapper pipeline plus OpenStreetMap or the FRPV reference dataset), not just a single pipeline. This is a stronger confidence signal than min_vintages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It warns that this is a detection dataset, not an exhaustive inventory (recall ~0.6), that missing detections do not imply absence of PV, and that fields like kwp are model estimates rather than surveyed values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but every sentence carries useful information: the action, the return shape, the alternative tool, and data caveats. It is front-loaded with the main purpose and then layered with guidance, though it could be slightly tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description covers the essential invocation context: return shape, filtering logic, sibling differentiation, and data quality limitations. It does not detail the contents of quality_summary or the output record fields, but this is a minor gap for a search tool whose parameters are fully schema-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters in detail. The description only paraphrases the filter categories without adding new parameter-level meaning beyond the schema, which meets the baseline for full coverage but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Search individual rooftop-PV detections') and enumerates the filter dimensions (département, INSEE code, capacity range, confidence). It also distinguishes itself from the sibling get_detections_in_bbox by explicitly routing spatial/map queries there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-not-to-use guidance: 'use get_detections_in_bbox instead for map/spatial queries with geometry.' It also directs the agent to call get_data_quality_reference before assessing fitness, providing clear context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
aggregate_detection_capacityget_community_activityget_community_activity_in_areaget_data_quality_referenceget_department_capacity_statsget_department_yearly_statsget_detections_in_bboxsearch_detectionsRooftop solar potential, RGE installer search and quote requests. France only, no API key.
French real estate data: cadastre, DVF sales, DPE energy ratings, price estimates, parcel context
French address intelligence: 18.6M sold prices, energy, risk, crime and schools — each sourced.
Indicative commercial rooftop solar assessments for Australian buildings, from open map data.
Add one secure layer between your agents and this server.
