The hosted Mireye MCP server provides cited US-coordinate answers and field-level data retrieval with provenance.
Ask Mireye (mireye_ask): answer natural-language questions about a US coordinate, returning citations and per-source provenance.
Fetch Mireye fields (mireye_fetch): retrieve specific catalog fields or named presets at a US coordinate, with value, source, source URL, fetched_at, and confidence per field.
Use US coordinates: latitude 18–72, longitude -180 to -65.
Discover fields: field descriptions are available through MCP resources such as mireye://catalog/fields and mireye://field/{name}.
Read-only and safe: both tools are annotated read-only, idempotent, non-destructive, and open-world.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mireye-mcp is 123 Main St in a flood zone?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mireye-mcp 0.7.3 configures Claude Code, Codex and Cursor to connect directly to
https://api.mireye.com/mcp, and installs the use-mireye skill. The package
runs no MCP server. Its default invocation refuses the retired local stdio
transport; device login and local data tools are not included.
Sign in at Mireye agent setup, accept the current customer terms, copy the private setup prompt and paste it into your agent. The prompt supplies the scoped API key through standard input, never a process argument. The helper validates the account and exact setup-key identity before saving the key or changing client configuration.
# The agent supplies the private key on stdin, without echoing or logging it.
uvx --from mireye-mcp==0.7.3 mireye-mcp connect --all --api-key-stdin --attempt-id '<attempt-id>' --token-id '<token-id>'
uvx --from mireye-mcp==0.7.3 mireye-mcp doctor --proofconnect writes native hosted configurations, without API keys or local launch
commands. Restart your agent and authorize its hosted MCP connection using the
client's OAuth sign-in. OAuth credentials remain managed by that client.
doctor --proof verifies the installed configuration and skill, checks the saved
API key's account, and makes one free REST Fetch for elevation at 40.7128,
-74.0060. It requires a finite value, ok status, source URL and timestamp before
reporting the data proof. The API records the successful Fetch against the setup
attempt. This proves the REST key/data path; it does not authorize or verify
hosted MCP OAuth. Confirm the connected client's tools after OAuth sign-in.
Client / purpose | Configuration | Skill / credentials |
Claude Code |
|
|
Codex |
|
|
Cursor |
|
|
Helper API key | — |
|
Setup ownership | — |
|
Setup preserves unrelated configuration, refuses custom conflicting entries or
modified skills, and backs up changed configuration files. A process lock and
content rechecks protect concurrent edits. Repeating connect reuses the saved
key and files; it does not issue credentials or grant another promotional
balance. An inherited shell key cannot replace an existing managed account.
To switch accounts, remove the managed connection, run logout, then connect
from that account's setup page. Authorize the correct account separately in the
MCP client's OAuth flow.
# Preview only: no key read, API requests, login save, lock or file changes.
uvx --from mireye-mcp==0.7.3 mireye-mcp connect --all --dry-run
# Reuse the saved key; --client can be repeated.
uvx --from mireye-mcp==0.7.3 mireye-mcp connect --client codex
# Read a redacted diagnostic report.
uvx --from mireye-mcp==0.7.3 mireye-mcp doctor --proof --json
# Remove unchanged owned entries/skills, retaining the helper API key.
uvx --from mireye-mcp==0.7.3 mireye-mcp connect --all --remove
# Remove the helper's saved key. --revoke also revokes its server-verified key ID.
uvx --from mireye-mcp==0.7.3 mireye-mcp logout--all skips absent supported clients; explicitly selecting an absent client
fails. Existing identical manual entries remain unmanaged, including on removal.
No project instructions or shell profiles are changed. Custom CODEX_HOME and
CLAUDE_CONFIG_DIR locations require manual setup; use --config-home PATH for
isolated tests. --base-url accepts the production API or loopback only and
binds saved keys to that origin. Redirects never forward a key to another host.
Legacy --api-key input remains accepted for compatibility; prefer stdin so the
key cannot appear in process listings.
Native configurations follow the client documentation: Claude Code, Codex, and Cursor.
The official MCP registry entry is hosted-only. This package is not a local transport distribution, and installing it does not add a second data service.
The hosted mireye_enrich tool returns the same compact response as
POST /v1/enrich. Each returned field contains value, source, confidence,
and interpretation_hints, with unit only when defined. Failed fields are
omitted. A matched parcel can return fields: {}.
Coordinates, geocode evidence, the analysis point, parcel match status and
billing are included. mireye_enrich takes preset as a list of one or more
bundle names, such as ["power", "water"].
mireye_search returns scalar filter values and every requested public Search or
Enrich field as plain values in each match's fields, excluding top-level identity
duplicates, using the matched parcel record's lat/lon pair. Every response carries
remarks ([] when clean; branch on code and path) and next_cursor (null on the
last page). Fetch and Ask have their own contracts.
See the Enrich reference for the
525-field inventory, selectors and examples.
Answer a natural-language question about a US coordinate, with citations to authoritative federal data sources. Returns the answer plus per-citation provenance (source, source URL, fetched_at, confidence). Use this when the caller has a specific question about a place (e.g. 'is this in a flood zone?', 'what's the wildfire risk here?', 'what kind of building is at this address?').
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees inside the supported US envelope. | |
| lng | Yes | Longitude in decimal degrees inside the supported US envelope. | |
| question | Yes | Natural-language question about the coordinate. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds valuable context about the return format (answer plus per-citation provenance with source, URL, fetched_at, confidence) and confirms the tool uses authoritative federal data. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first explains what the tool does and what it returns, the second provides usage guidance with examples. Every sentence adds value, and the structure is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (mentioned in context), the description appropriately focuses on the tool's purpose and return structure. It covers all necessary aspects: what it does, when to use it, and the key output elements. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema provides clear descriptions for lat, lng, and question (including bounds and length constraints). The tool description adds that the question is 'natural-language' but does not provide additional meaning beyond what the schema already conveys. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool answers natural-language questions about US coordinates with citations. Examples like 'is this in a flood zone?' help convey the purpose. However, it does not explicitly differentiate from the sibling tool mireye_fetch, so clarity is high but not maximal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use the tool ('when the caller has a specific question about a place') with concrete examples. It does not mention when not to use it or provide alternatives (e.g., mireye_fetch for raw data), but the guidance is still actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch specific data fields at a US coordinate with full provenance per field. Use this when the caller knows exactly which fields they need (e.g. 'elevation and slope at this point') or wants to power a custom workflow. Each field includes its value, source, source URL, fetched_at timestamp, and confidence.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees inside the supported US envelope. | |
| lng | Yes | Longitude in decimal degrees inside the supported US envelope. | |
| fields | No | ||
| preset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe, read-only behavior. The description adds valuable behavioral details: each field includes its value, source, source URL, fetched_at timestamp, and confidence. This goes beyond annotations by explaining the provenance structure, though it does not cover all edge cases like rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and usage guidance. Every sentence is necessary and adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with 2 required, no enums, an output schema, and sibling tools, the description covers the main purpose, usage context, and return format. It lacks explicit mention of the 'preset' parameter and how it relates to 'fields'. However, the output schema likely covers return values, so completeness is high but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (lat, lng, fields have descriptions; preset only has enum list). The description mentions fetching 'specific data fields' and 'each field includes...', which partly explains the 'fields' parameter, but does not explicitly describe 'lat', 'lng', or 'preset'. The description adds some value but does not fully compensate for the schema's lack of explanation for some parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'specific data fields at a US coordinate', and adds detail about provenance. It differentiates from the sibling 'mireye_ask' by specifying this tool is for when the caller knows exactly which fields they need.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this when the caller knows exactly which fields they need...or wants to power a custom workflow.' It provides an example and implies that for less specific needs, the sibling 'mireye_ask' might be more appropriate, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0mireye_askmireye_fetchScored across 2 tools
The two tools have clearly distinct purposes: mireye_ask handles natural-language questions with implicit field selection, while mireye_fetch retrieves explicitly specified data fields. There is no overlap or ambiguity.
Both tools follow the same 'mireye_<verb>' pattern with snake_case, using descriptive verbs ('ask' and 'fetch'). The naming is consistent and predictable.
With only two tools, the server is minimal but scoped appropriately for its purpose of US coordinate data queries. It could potentially benefit from a metadata tool, but the count is not unreasonable for the stated domain.
The server covers the two primary interaction modes: asking questions and fetching specific fields. It may lack a discovery or listing tool, but the existing tools provide a full workflow for obtaining data with provenance.
Remote MCP endpoint for U.S. home forecasts, public benchmark data, and permit or zoning readiness.
Geocoding, routing, isochrones, traffic, weather, and place search for AI agents. 19 MCP tools.
Flood, wildfire, soils, terrain, power grid, utilities and parcels for any US location, sourced.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
