Skip to main content
Glama
malonestar

gov-data-mcp

by malonestar

hifld-grid-proximity-screener

Given lat/lon sites, returns distance to nearest transmission line, substation, power plant, serving utility, ISO/RTO, and nearby generation. Ideal for data-center, renewable, BESS, and EV siting.

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. 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.
Behavior4/5

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

The description discloses several behavioral aspects: it reads live government data, explains billing per row, details failure modes (e.g., truncated line fallback, simulated outage diagnostics), and clarifies how optional flags affect output. This goes beyond basic annotations, though rate limits or exact failure conditions are not fully specified.

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?

The description is a single dense paragraph that front-loads the main purpose and lists outputs. It is not overly verbose, though it includes many details. It is well-structured and avoids redundancy.

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?

Given the complexity (12 parameters, no output schema), the description covers the core behavior, data sources, billing, and failure modes. It is reasonably complete, though it could briefly mention the expected output shape or typical use-cases more explicitly.

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?

The input schema already provides extensive per-parameter descriptions (coverage 100%). The description adds context about data sources (official government source) and overall purpose, but does not significantly enhance parameter understanding beyond the schema. Since schema coverage is high, the baseline is 3; the added context justifies a 4.

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?

The description clearly states the tool's functionality: it calculates distances to transmission lines, substations, power plants, and utility/ISO information for given coordinates. It explicitly lists outputs and use cases (data-center, renewable, BESS, EV siting), making its purpose unambiguous.

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

Usage Guidelines2/5

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

The description does not explicitly mention when to use this tool versus alternatives (e.g., other proximity screeners). It implies suitability for grid-related siting through examples, but lacks direct comparative guidance or criteria for selection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/malonestar/gov-data-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server