In this piece
Mireye Land Search and Enrich API: MCP, Pricing and Parcel Screening
Header illustration: © 2026 Wavect.
A useful land-search agent should return a shortlist someone can investigate: identifiable parcels, explicit selection criteria, traceable evidence and unanswered questions. Mireye's new Land Search and Enrich API provides building blocks for that workflow through REST and the Model Context Protocol (MCP).
In its launch announcement, Mireye reports more than 160 million U.S. parcels, 550 available data fields, billions of indexed data points and four million historical Fetch calls. Those are vendor figures. The practical news is the combination of parcel discovery, selected-property enrichment and free access to supported public location fields.
Checked on : we reviewed primary documentation and retrieved the three public field catalogs. We did not run authenticated parcel searches, benchmark latency or independently audit nationwide coverage. The examples below are proposed workflows and derived costs.
Mireye Search vs Enrich vs Fetch: which API should an agent use?
Use Search to discover parcels, Enrich to investigate a selected parcel, and Fetch for supported public facts at a known location. The endpoint determines the available evidence as well as the bill.
| Operation | Best starting point | What you receive | Usage price |
|---|---|---|---|
| Search | State, acreage and other supported requirements | Matching parcels and selected field values | $0.20 per completed page |
| Enrich | One U.S. address or coordinate | A parcel match and selected fields with source, confidence and interpretation hints | $0.02 per matched parcel when at least one field is returned |
| Fetch | A known location and eligible public fields | Structured public data with field-level provenance and status | Free through standard authenticated access |
| Ask | A natural-language location question | A generated answer with citations | $0.10 per completed answer |
The current pricing page lists a one-time $10 signup balance without expiry. Paid plans start at $49 per month with included usage and lower Search and Enrich rates. The Free plan's name does not make its parcel operations free.
Free Fetch excludes licensed parcel records, including parcel identity, ownership, parcel boundaries and parcel zoning, plus calculations that depend on those records. Authentication and capacity limits still apply. The separate API-key-free x402 payment route costs $0.001 USDC per successful Fetch call. “Free Fetch” therefore needs the access-method and field-scope qualification.
How much does a Mireye parcel shortlist cost?
At Free-plan rates, five completed Search pages plus 20 chargeable Enrich calls cost $1.40 in Mireye usage. This is an illustrative budget, not the measured cost of finding 20 suitable properties.
| Step | Assumption | Calculation |
|---|---|---|
| Discover candidates | Five paid Search pages | 5 × $0.20 = $1.00 |
| Investigate finalists | 20 Enrich operations returning at least one field each | 20 × $0.02 = $0.40 |
| Additional public location checks | Eligible standard authenticated Fetch calls | $0.00 in Fetch usage |
| Mireye subtotal | These operations only | $1.40 |
Search includes the output fields requested on that page. Returning a field through Search does not automatically add a separate Enrich charge. A page can return fewer parcels than requested, including zero; the example does not assume five full pages or an exhaustive search. Model tokens, orchestration, paid driving calculations and human investigation are outside this subtotal.
The $10 welcome balance corresponds arithmetically to 50 Search pages or 500 chargeable Enrich operations at these rates, if spent entirely on one operation. For production economics, measure cost per accepted agent outcome: a cheap API call has little value if its parcel match or evidence must be repaired.
Are all 550 advertised fields searchable?
Do not treat the launch total as a filter schema. Our public-catalog check returned version 0.18.0 with these endpoint-specific inventories:
- Search catalog: 529 returnable entries, of which 510 had at least one filter operator.
- Enrich catalog: 525 fields.
- Fetch catalog: 351 fields.
These are different sets, so comparing their totals does not establish that the launch figure is wrong. More usefully, the Search discovery contract distinguishes filter_ops from returnable. In the retrieved catalog, parcel_flood_sfha_fraction could be returned but had no filter operators. An agent should request that result and evaluate it afterwards, rather than invent a server-side filter.
Catalog discovery is unauthenticated and free. Through MCP, use mireye_list_fields with the relevant endpoint and an optional search term. Check the catalog when constructing a workflow; avoid permanently embedding launch-era field counts in application logic.
How do you connect Mireye to Claude Code through MCP?
The supported MCP connection is hosted at https://api.mireye.com/mcp, using Streamable HTTP and OAuth. For Claude Code:
claude mcp add --transport http --scope user mireye-earth https://api.mireye.com/mcpThen open /mcp and complete authorization. Other clients need support for the remote transport and authorization flow. The older local adapter and device-login instructions are retired.
Search and Enrich authorization also depends on current terms and licensed-data permissions. Existing connections may need reauthorization; an old OAuth grant does not acquire the new permissions automatically. Direct HTTP API keys and hosted MCP OAuth tokens have different roles.
A bounded MCP workflow for U.S. land screening
1. Turn the brief into explicit constraints
For an illustrative solar-screening brief, start with a named county, an acreage range and the evidence needed for a first review. Separate hard requirements from preferences. “Between 100 and 1,000 acres” is an explicit filter; “good grid access” needs a defined measure and further investigation. Keep U.S. acreage units in requests even when the interface is localized.
The hosted tool contract puts paid request bodies inside req, with idempotency_key beside it. This example is a request to mireye_search, not a recorded API result:
{
"req": {
"filters": [
{"field": "state2", "op": "eq", "value": "AZ"},
{"field": "county", "op": "eq", "value": "04013"},
{"field": "pvd_gisacre", "op": "between", "value": [100, 1000]}
],
"fields": ["owner", "zoning", "parcel_flood_sfha_fraction"],
"limit": 10,
"max_cost_usd": "0.20"
},
"idempotency_key": "az-parcel-screen-example-page-001"
}The county FIPS code remains a string so its leading zero survives. The flood fraction is requested as output. Replace the illustrative operation key for a new search; preserve it when retrying the same request.
2. Track completion and spending separately
The Search reference specifies a required state filter, a default page size of 10 and a maximum of 100. It returns first matches, so an agent must apply its own ranking.
- Continue while
next_cursoris non-null, even after a short or empty page, unless the workflow's total budget requires a stop. - Keep filters and requested fields unchanged across pages. Each new page needs a new operation key; retries reuse the original key and body.
- Read
remarksfor incomplete checks or unavailable fields. A final cursor alone does not erase a completeness warning. - Allow at least 210 seconds at the client. Cursors expire after one hour, and pages are not a frozen snapshot.
max_cost_usd caps an individual operation. Our proposed controller also counts pages, accumulates receipts and stops at a total run budget. If it stops early, the report should say “best of the candidates examined” and record the stop reason. It should not claim to have found the best parcels nationwide.
3. Confirm identity before combining Search and Enrich
Enrich resolves an address or coordinate to a parcel; it does not simply accept the Search APN as a guaranteed join key. Search's stored analysis_point can fall outside the boundary, and a new spatial match can therefore identify a different property.
Follow the documented identity check: require a matched result and compare parcel number, address, state and county FIPS before merging evidence. Preserve uncertain matches for review. APNs can repeat across counties, and a plausible address is insufficient proof of identity.
Requesting selected values directly in Search avoids that second match. Use separate Enrich when you need its field-level source, confidence and interpretation hints. Request the identity fields needed for the comparison as well as the decision fields.
What does a sourced parcel result actually prove?
Keep the endpoint's evidence structure intact. Fetch distinguishes ok, absent and failed, and exposes source URLs, retrieval times and dataset vintage where available. A recent fetched_at does not make an older underlying dataset current. Search returns plain values; standalone Enrich can omit unavailable fields and does not expose Fetch's full status envelope.
Our engineering rule is to preserve unknown, false and zero as different states. Add source links and dates only where the response or a checked source actually supplies them. Do not fabricate a citation URL from a source label.
The field definitions make spatial scope especially important: within_floodplain_polygon describes a point, while parcel_flood_sfha_fraction concerns the full boundary. A useful agent preserves that distinction in both its ranking and its prose.
| Observed signal | Reasonable next action |
|---|---|
| No mapped hazard at the sampled point | Check parcel-wide overlap and coverage before making a property-wide statement. |
| Missing zoning or ownership field | Request the relevant record; keep the decision unresolved. |
| Nearby substation or transmission line | Investigate the applicable utility, connection process and project requirements. |
| Recent retrieval of an older dataset | Keep both dates and ask whether the decision needs a newer record. |
FEMA's flood-zone guidance explains that lower-risk zones still carry risk and undetermined risk means analysis is missing. FERC's generator-interconnection explainer distinguishes preliminary information from connection studies and network upgrades. Our inference for screening is straightforward: proximity alone cannot establish usable grid capacity.
How should an agent rerank land for solar, storage or data centers?
Filter clear requirements first, then rank eligible candidates with explicit preferences and a separate evidence-completeness assessment. Do not reward missing evidence by treating it as a favorable zero.
Consider three hypothetical solar candidates. Parcel A meets the acreage brief and has reviewed hazard evidence. Parcel B looks attractive on terrain but lacks a parcel-wide flood result. Parcel C fails a confirmed acreage requirement. A can enter the evaluated shortlist, B belongs in a review queue, and C is excluded for the recorded reason. A single blended score would hide why those decisions differ.
Keep each shortlist row useful to the next person: parcel identity, evaluated location, satisfied requirements, preference score and its version, supporting sources, unavailable evidence, search-completeness notes and the next verification action. Store permitted evidence and follow the applicable data-use terms when sharing results.
Solar, battery storage and data centers should use different briefs. A developer should define the project-specific power, land, access and operational requirements before choosing fields or weights. Reusing a solar score for a data center merely because both need grid context gives the agent a misleading objective.
Mireye's own Texas solar-carport demonstration illustrates why these checks matter. It searches Texas public parcel files with custom code and then uses Fetch batch calls; this is not a benchmark of the new Search and Enrich endpoints. The project describes screening 1,187 sites and discusses repeated Fetch passes, duplicate opportunities and an unvalidated scoring formula. Some missing ERCOT queue values reflect sites outside ERCOT territory. That is a reason to inspect applicability before penalizing a null. The project is a vendor demonstration, not a Wavect performance result.
When is Mireye a useful fit?
Mireye is worth evaluating when an agent needs to discover U.S. parcels and assemble structured evidence for a human site-selection or acquisition process. Start with a bounded pilot in the counties and use cases that matter to you. Measure correct parcel matching, required-field availability, unresolved evidence, reviewed shortlist quality and total cost.
The documented geographic scope is U.S.-focused. The drive-time tools' additional Canadian coverage does not imply Canadian parcel coverage. A German, Spanish or Chinese user interface does not extend the parcel dataset to those countries.
For a production integration, connect the data contract, ranking rules, spending limits and review handoff. Wavect's AI integration service covers the surrounding application work; our enterprise MCP authorization guide explains the broader access boundary.