Skip to main content
Glama

hifld-grid-proximity-screener

Screen lat/lon sites for nearest transmission lines, substations, power plants, serving utility, ISO/RTO, and nearby generation or battery-storage MW.

Instructions

Transmission Line & Substation Distance API by Coordinates. For each lat/lon site: distance to the nearest transmission line (kV, owner, overhead/underground), nearest substation, nearest power plant, the serving utility and its ISO/RTO, plus generation and battery-storage MW nearby. Includes sub-100 kV. Data-center, renewable, BESS and EV siting. Reads live from the official government source. COST AND SIDE EFFECTS: read-only with respect to the government source — it never writes to any external system — but each call starts a metered run on YOUR Apify account, billed $0.01 per result ($10 per 1,000). Lower on paid Apify plans, down to $3.00 per 1,000. Nothing is charged when a run fails. Store page: https://apify.com/malonestar/hifld-grid-proximity-screener

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assetsYesSites to screen for grid access. Each entry is an object { "lat": number, "lon": number, "label": "optional name" }. Also accepts "lat,lon" strings or [lat, lon] arrays. One dataset row (one billed result) is produced per asset; a bad entry yields an ERROR row and the run continues. Example: [{"lat":39.017,"lon":-77.46,"label":"Ashburn VA data center site"},{"lat":33.4484,"lon":-112.074,"label":"Phoenix AZ site"}].
eiaApiKeyNoOptional. A free EIA API key (https://www.eia.gov/opendata/register.php) enables the state industrial and commercial electricity price columns. Everything else works without it — leave this empty and those two columns are simply null. One lookup per distinct state, not per site.
maxResultsNoMaximum number of assets processed in one run (1-2000). One result row is emitted (and billed) per asset. Default 500. Applied by default if omitted: 500.
radiusMilesNoRadius around each asset to search for transmission lines, substations and power plants, in miles (1-50). Features beyond this distance are ignored. Default 5. Example: 10. Applied by default if omitted: 5.
minVoltageKvNoOptional. Only count/consider transmission lines at or above this many kV. Since v1.2 the underlying layer includes sub-100 kV sub-transmission (69/46/34.5 kV), so values below 100 are now meaningful — leave empty to include every line, or set 115/230 to screen for high-voltage access only. Lines with an unknown voltage are excluded when this is set. Does not filter substations or power plants.
skipErrorRowsNoWhen true, assets that could not be screened are logged but not written to the dataset, so you are not billed for them. Default false, which keeps every asset accounted for as an ERROR row. Note that a run in which EVERY asset fails always fails outright and bills nothing, regardless of this setting. Applied by default if omitted: false.
includePlannedNoAdvanced/opt-in. Also check a 'planned transmission line' scratch layer that carries NO owner/voltage/status metadata. It is NOT an authoritative planned-line dataset — the planned_line_nearby flag is a low-confidence 'a planned-line geometry exists nearby' hint only. Default false. Applied by default if omitted: false.
includeUtilityNoAlso resolve which retail electric utility serves each site, its ownership type, holding company, customer count and summer peak, plus the balancing authority and ISO/RTO (PJM, ERCOT, CAISO, MISO, SPP, ISO-NE, NYISO). Where service territories overlap, the largest utility by summer peak load is reported as primary. On by default — one extra lookup per site. Example: true.
simulateOutageNoDiagnostic seam for verifying the reliability behaviour on demand rather than waiting for a real outage. "none" (default) is a genuine no-op. "primary" forces the primary line layer to appear down; "drift" forces the live drift gate to measure a truncated layer (the run then fails and bills nothing); "gate" forces the drift probes to be unreachable; "both" combines primary and gate. Leave as none for normal use. Applied by default if omitted: "none".
includePowerPlantsNoAlso report the nearest power plant (name, distance, fuel, technology, capacity MW, EIA plant code) plus total generation, battery-storage, solar and wind MW within the radius. Sourced from EIA's monthly plant inventory. On by default — set to false to skip and speed up large batches. Example: true.
includeSubstationsNoAlso report the nearest electric substation (name, distance, max/min voltage, connected line count) plus substations within the radius. On by default — set to false to skip substation screening and speed up large batches. Example: true.
allowTruncatedLineFallbackNoThe transmission-line answer comes from a national layer of 94,619 lines. If that layer is unavailable, the only backup is a 2023 copy that contains NO line below 100 kV — 44.8% of the US grid, and the sub-transmission most mid-size solar, BESS and EV-charging projects actually interconnect to. At Storm Lake IA it reports the nearest line 2.545 mi away at 161 kV when the truth is 0.649 mi at 69 kV. By default (false) such a run FAILS and bills nothing. Set true to receive rows instead, in which every complete-universe field (nearest_line_distance_miles, lines_within_radius, max_voltage_within_radius_kv, ...) is null, grid_tier reads DEGRADED, and only the nearest_ge100kv_line_* columns are populated. Applied by default if omitted: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A4.2/5.0
Behavior4/5

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

Goes well beyond the annotations: discloses metered billing ($0.01/result, $10/1k, down to $3/1k), that failed runs bill nothing, reads live from the official source, and explains the DEGRADED fallback behavior. The readOnlyHint=false annotation is not contradicted in spirit (writes happen to the agent's own Apify run storage, not external systems) but the description's 'read-only with respect to the government source' wording could be clearer about the run-storage side effect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, but the description is long and the COST AND SIDE EFFECTS block plus the extensive allowTruncatedLineFallback narrative make it dense. Much of the cost detail is essential, but the store page URL and some repetition (e.g., billing rules restated) add noise.

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 12-parameter read tool with no output schema, the description covers billing, data sources, fallback behavior, and default-on vs off semantics well. It could more explicitly enumerate the returned columns or clarify the readOnlyHint=false annotation's meaning, but an agent has enough to invoke it correctly.

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 baseline is 3; the description adds meaningful semantics beyond the schema — notably the billing consequence of skipErrorRows, the low-confidence nature of includePlanned, and the DEGRADED fallback semantics of allowTruncatedLineFallback. This lifts it above baseline.

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 (distance to transmission lines, substations, power plants by coordinates) with concrete output fields (kV, owner, overhead/underground, utility, ISO/RTO, MW nearby). Clearly distinguishable from siblings like interconnection-queue-tracker or fws-wetlands-proximity-screener, which cover different resources.

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?

Names intended use cases (data-center, renewable, BESS, EV siting) which implies when to use it, and the include* flags let an agent scope the screening. It does not, however, explicitly compare against sibling tools or state when NOT to use this one.

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