Skip to main content
Glama
azmartone67

DC Hub — Data Center & Energy Intelligence

Analyze Parcel

analyze_parcel
Read-onlyIdempotent

Supply a parcel's GeoJSON boundary or a lat/lon point to get its total acreage, member breakdown, contiguous flag, and representative centroid for site and water-risk handoff.

Instructions

Structured read of a parcel BOUNDARY — pass your own GeoJSON Polygon/MultiPolygon, OR just lat+lon and DC Hub finds the containing parcel in its HOSTED parcel-boundary layer (free county/state GIS polygons, rolling out by data-center market — Loudoun County VA first; a point outside hosted coverage returns an honest 404 with the coverage list, never a guess). Returns _entity=parcel_analysis: geodesic total_acres, a per-member acreage breakdown, a contiguous flag, representative_point = the centroid of the LARGEST-area member (never the multi-part geometric center, which can land off-parcel on a highway median or river and poison every point-keyed read), and hosted_parcel {parcel_id, county, state, acres_per_source} when the polygon came from the hosted layer. Also returns a site_evaluation_handoff to pipe into analyze_site + get_water_risk at that anchor. Use when you HAVE a boundary or a point on a specific parcel and want it anchored + sized; for a general lat/lon site score use analyze_site; for the interconnection-queue survivor set use get_refined_queue (queue rows carry NO parcel identity, so they never auto-join to hosted parcels).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoLatitude of a point ON the parcel — used with lon when geometry is omitted to look up the containing parcel from the hosted county/state GIS layer
lngNoAlias for lon — either name works
lonNoLongitude of a point ON the parcel (used with lat when geometry is omitted)
geometryNoGeoJSON Polygon or MultiPolygon parcel boundary, e.g. {"type":"Polygon","coordinates":[[[lng,lat],[lng,lat],...]]} — a MultiPolygon carries discontinuous parcels as one envelope. Omit to look up the hosted parcel containing lat/lon instead
latitudeNoAlias for lat — either name works
longitudeNoAlias for lon — either name works
capacity_mwNoOptional target load in MW to pass through into the site_evaluation_handoff

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
quotaNoCaller quota state (remaining calls, tier) when available.
_entityNoPayload class discriminator (e.g. facility|market|iso_grid|queue_results|deal|report|response) — branch on this before parsing the rest.
citationNoMachine-readable citation: how to attribute DC Hub (dchub.cloud) for this payload. Normally an OBJECT {source, url, license, cite_as, retrieved_at}; a bare string is accepted and carries the attribution line itself.
provenanceNoCollection-level provenance block: {source, method, as_of, verification_counts, cite_url_template, license, cite_as}. Quote the verification level when citing.
_front_doorNoIn-band front-door hint (first workflow-entry tool of a session): call plan_query(intent) first for the ordered multi-step plan.
_return_loopNoSuggested next-session delta call (get_changes since=24h) so you pull only what changed.
site_evaluation_handoffNoPre-built follow-up calls (analyze_site / get_water_risk args) when the payload carries coordinates — an array of {tool, parameters, why} entries.
Behavior5/5

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

Annotations already indicate read-only and idempotent. The description significantly adds beyond that: guaranteed honest 404 with coverage list, never a guess; representative_point selected as centroid of the largest-area member to avoid off-parcel placement; and queue rows never auto-joining to hosted parcels. These edge-case disclosures are critical and not present in annotations.

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 long but front-loaded with the core action and every sentence contributes operational value: input modes, hosted-layer caveat, return fields, centroid rationale, and sibling usage. It could be slightly trimmed, but it earns its length given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 optional parameters, a hosted-layer lookup path, and specific return-field semantics, the description covers all essential aspects: inputs, behavior on missing coverage, output highlights, and downstream integration (site_evaluation_handoff). No major gaps remain for an agent to select and invoke 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% with detailed parameter descriptions. The description adds meaningful contextual semantics by explaining the OR relationship between geometry and lat/lon, the hosted-layer coverage limitation, and how capacity_mw flows through to the site_evaluation_handoff. This elevates it above the high-coverage 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?

The description opens with 'Structured read of a parcel BOUNDARY', a specific verb+resource that exactly captures the tool's function. It further distinguishes from siblings by explicitly naming analyze_site and get_refined_queue as alternatives for different scenarios.

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?

Provides explicit when-to-use guidance: 'Use when you HAVE a boundary or a point on a specific parcel and want it anchored + sized.' It also names alternatives with differentiating reasoning: 'for a general lat/lon site score use analyze_site; for the interconnection-queue survivor set use get_refined_queue (queue rows carry NO parcel identity...)'.

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/azmartone67/dchub-mcp-server'

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