Skip to main content
Glama
malonestar

gov-data-mcp

by malonestar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

hifld-grid-proximity-screener

Screen US sites by coordinates for nearby grid infrastructure: transmission lines, substations, power plants, serving utility/ISO, and generation/battery 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. Call describe-gov-data-tool (free) for a verified example input. 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.3/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that the call starts a metered run on the caller's Apify account at $0.01/result, that failed runs bill nothing, that read-only applies only to the government source, and it documents degraded-mode behavior (allowTruncatedLineFallback nulling complete-universe fields, grid_tier DEGRADED) plus a diagnostic simulateOutage seam. This is exactly the kind of cost/failure/auth context annotations cannot carry.

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?

Long but front-loaded: capability and outputs come first, then usage contexts, then a clearly labeled COST AND SIDE EFFECTS block. The store-page URL is the only line that doesn't earn its place, but overall it is dense rather than padded.

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?

With 12 parameters, no output schema, and no annotation-level cost disclosure, the description does the heavy lifting: it explains billing model, failure accounting, and named output columns (grid_tier, nearest_ge100kv_line_*). It is nearly complete, missing only a full return-shape summary, which the absence of an output schema makes slightly more important.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema itself documents every parameter in depth (including the sub-100 kV nuance and the planned-line caveat), so the description need not repeat them. The description adds only marginal param-level context ('Includes sub-100 kV'), so baseline 3 is appropriate.

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 ('Transmission Line & Substation Distance API by Coordinates') and enumerates the concrete outputs: nearest line with kV/owner/overhead-underground, nearest substation, nearest plant, serving utility and ISO/RTO, nearby MW. This is clearly distinguishable from siblings like interconnection-queue-tracker or fws-wetlands-proximity-screener.

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 the use contexts explicitly (data-center, renewable, BESS and EV siting) and routes the agent to describe-gov-data-tool for a verified example. It stops short of stating when to prefer a sibling tool (e.g. vs interconnection-queue-tracker) or any exclusion conditions, so it lacks the 5-level routing guidance.

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