将 Claude、Cursor、Windsurf 和其他 AI 工具连接到 80 多个美国联邦环境和基础设施数据源。
GeoTap 聚合了来自 FEMA、USGS、EPA、NOAA、USDA、USFWS、DOT、人口普查局等机构的数据，并通过 MCP（模型上下文协议）进行访问。
Web 应用：geotapdata.com — 无需代码，在地图上绘制即可直观地探索数据。
Node.js (v18 或更高版本) — 在此下载
一个用于注册 API 密钥的电子邮箱地址
前往 geotapdata.com/developers 并使用您的邮箱注册以获取免费的 API 密钥。
您的 API 密钥将发送到您的邮箱。请保存好它 — 您将在下一步中使用它。
在下方选择您的 AI 工具并按照说明操作。MCP 服务器通过 npx 自动安装 — 无需手动下载。
打开 Claude Desktop
前往 Settings（齿轮图标） → Developer → Edit Config
这将打开您的 claude_desktop_config.json 文件。添加以下内容（将 your-api-key-here 替换为您实际的密钥）：
{
"mcpServers": {
"geotap": {
"command": "npx",
"args": ["-y", "geotap-mcp-server"],
"env": {
"GEOTAP_API_KEY": "your-api-key-here"
}
}
}
}配置文件位置：
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
完全重启 Claude Desktop（退出并重新打开）
您应该会在聊天输入框中看到一个锤子图标 (🔨) — 这意味着 GeoTap 已连接
运行此命令将 GeoTap 添加到您的 Claude Code MCP 服务器中：
claude mcp add geotap -- npx -y geotap-mcp-server然后将您的 API 密钥设置为环境变量。将其添加到您的 shell 配置文件（~/.zshrc、~/.bashrc 等）中：
export GEOTAP_API_KEY="your-api-key-here"重启您的终端，然后启动 Claude Code。GeoTap 工具将自动可用。
打开 Cursor
前往 Settings（Mac 上为 ⌘ + ,，Windows 上为 Ctrl + ,） → 搜索 "MCP"
点击 "Edit in settings.json" 或添加到您的 .cursor/mcp.json 文件中：
{
"mcpServers": {
"geotap": {
"command": "npx",
"args": ["-y", "geotap-mcp-server"],
"env": {
"GEOTAP_API_KEY": "your-api-key-here"
}
}
}
}重启 Cursor
打开 AI 聊天面板 — GeoTap 工具将出现在可用工具列表中
打开 Windsurf
前往 Settings → MCP Servers（或直接编辑 ~/.codeium/windsurf/mcp_config.json）
添加：
{
"mcpServers": {
"geotap": {
"command": "npx",
"args": ["-y", "geotap-mcp-server"],
"env": {
"GEOTAP_API_KEY": "your-api-key-here"
}
}
}
}重启 Windsurf
对于任何 MCP 客户端，服务器都可以直接运行：
# Install globally
npm install -g geotap-mcp-server
# Run with your API key
GEOTAP_API_KEY=your-api-key-here geotap-mcp服务器通过 stdio 进行通信 — 将您的 MCP 客户端指向 geotap-mcp 命令，并设置 GEOTAP_API_KEY 环境变量。
连接后，让您的 AI 助手提取任何美国地点的相关数据。GeoTap 会同时从所有 80 多个联邦来源收集数据 — 只需提供一个地点，然后询问您想知道的任何内容：
"Collect site data for 123 Main St, Austin TX"数据返回后（约 60-120 秒），您可以询问后续问题，例如：
“这个地点在洪水区吗？”
“这里的土壤类型是什么，曲线数（curve number）是多少？”
“附近有任何污染隐患吗？”
“百年一遇的降雨量是多少？”
“开发这个地点需要什么许可证？”
“总结一下主要的环境风险”
问题 | 解决方案 |
服务器无法启动 / "GEOTAP_API_KEY is required" | 确保您的 API 密钥已在 MCP 配置的 |
"npx: command not found" | 安装 Node.js (v18+)，其中包含 npx |
工具未出现在 Claude Desktop 中 | 完全重启 Claude Desktop（退出并重新打开，不仅仅是关闭窗口） |
速率限制错误 | 等待片刻后重试 — 突发限制是按分钟计算的 |
Related MCP server: PropertyScoop MCP Server
机构 | 可用数据 |
FEMA | 洪水区、FIRM 图板、洪水保险费率图、洪泛区边界 |
USGS | 高程（1m/10m/30m 的 3DEP）、地质、河流监测站、地下水、土地利用 (NLCD)、StreamStats、国家河流流量统计 (NSS) |
EPA | 水质 (ATTAINS)、超级基金场地、棕地、TRI 有毒物质排放、UST、NPDES 排污口 |
NOAA | 降雨量 (Atlas 14)、IDF 曲线、潮汐站、气候预测 (CMIP6)、气象站、雷达 |
USDA/NRCS | 土壤 (SSURGO)、曲线数、水文土壤组、TR-55 参数 |
USFWS | 湿地 (NWI)、濒危物种、关键栖息地 |
DOT | 桥梁、隧道、国家桥梁清单 |
人口普查局 | 人口统计、边界、TIGER 地理数据 |
USACE | 大坝、堤坝、航道 |
NHD | 河流流线、水文、流域边界 (HUC-8/10/12) |
其他 | 发电厂、矿山、部落土地、建筑轮廓等 |
每条响应都包含来源归属 — 联邦机构、数据集名称和参考 URL。
变量 | 描述 | 必需 |
| 注册时获取的 API 密钥 | 是 |
| 自定义 API 端点（高级） | 否 |
雨水设计：降雨量（Atlas 14、IDF 曲线、雨型）、曲线数、汇流时间、峰值流量
洪水分析：Bulletin 17C 洪水频率、流量历时曲线、区域回归估计
流域划分和水文建模输入 (HEC-HMS, SWMM)
NPDES 许可证的低流量分析 (7Q10, 7Q2, 调和平均流量)
针对基础设施韧性的气候调整设计暴雨
房地产交易的环境尽职调查
地点可行性和可开发性评分（0-100 分）
洪水区、湿地和污染筛查
许可证路径分析 (Section 404, NPDES, 洪泛区开发)
第一阶段环境现场评估 (ESA) 桌面数据收集（EPA 场地、水质）
湿地划定支持 (NWI + 土壤 + 水文)
濒危物种栖息地筛查 (USFWS 关键栖息地)
水质损害评估 (EPA ATTAINS 303(d) 清单)
欢迎贡献！请提交 issue 或 pull request。
MIT
Web 应用: geotapdata.com
问题反馈: GitHub Issues
npm: geotap-mcp-server
Collect comprehensive environmental data from ALL 80+ federal data sources for a site. Accepts an address, lat/lng coordinates, or a GeoJSON geometry (Point or Polygon). Returns a jobId — poll with get_results until complete (60-120 seconds).
Data returned covers: flood zones, wetlands, soils, geology, contamination sites, water quality, seismic risk, rainfall, infrastructure, ecology, energy, demographics, and much more.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | US street address (e.g., "123 Main St, Houston TX"). If provided, the site is geocoded automatically. Use this OR lat/lng OR geometry. | |
| lat | No | Latitude of the site (e.g., 34.8441). Use with lng. | |
| lng | No | Longitude of the site (e.g., -82.4010). Use with lat. | |
| geometry | No | GeoJSON geometry (Point or Polygon). For advanced use — most users should use address or lat/lng instead. | |
| bufferAcres | No | Site area in acres when using a point location. Creates a circular buffer. Default: 1 acre. Range: 0.1–640. | |
| searchRadiusMiles | No | How far to search for nearby features (contamination, infrastructure, etc.). Default: 3 miles. Range: 0.5–10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses async behavior, polling requirement, time estimate, and broad data coverage. It does not mention rate limits or availability constraints.
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 concise with two front-loaded paragraphs. Every sentence adds value with no redundancy or waste.
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 no output schema, the description covers the return format (jobId), polling mechanism, and data categories. It is fairly complete but could mention error handling or limits.
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 coverage is 100% with descriptions for each parameter. The description adds value by summarizing the OR condition among address/lat-lng/geometry and providing default ranges for bufferAcres and searchRadiusMiles.
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 collects comprehensive environmental data from 80+ federal sources, accepting address, lat/lng, or geometry. It uses a specific verb-resource combo and distinguishes from siblings like get_results.
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 explains how to use the tool (provide location input, receive jobId, poll with get_results) and gives typical completion time. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the GeoTap API discovery document. Returns a structured description of all data sources and capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the return value but omits side effects, authentication needs, rate limits, or other behavioral traits.
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 sentences with no filler. Every sentence adds value: first states the verb and resource, second describes the return content.
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?
Without an output schema, the description should fully describe the return value. It says 'structured description' but lacks detail on format or structure, which is a gap for a tool that only outputs data.
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?
With zero parameters, schema coverage is 100% automatically. The description adds no parameter details, but baseline for 0 params is 4, which 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 it gets the GeoTap API discovery document, specifying the resource and action. It distinguishes from siblings 'collect_site_data' and 'get_results', which imply different operations.
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?
No guidance on when to use this tool versus alternatives. It does not mention that it should be used to discover capabilities before performing other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a data collection job and retrieve results. Poll every 10 seconds until status is "completed".
When complete, present results as a SCANNABLE ENGINEERING DOCUMENT — not a data dump. An engineer needs to answer: (1) What kills the project? (2) What complicates permitting? (3) What's the baseline context?
CRITICAL FLAGS — scan results FIRST and lead with these if present:
FEMA Zone AE/AO/VE or SFHA=true → "Site intersects SFHA — Zone [X]" (CRITICAL)
Floodway present → "Regulatory floodway — no-rise certification required" (CRITICAL)
Superfund count > 0 → "NPL Superfund site within search radius" (CRITICAL)
Wetland count > 10 → "High wetland density — Section 404 permitting likely" (HIGH)
303(d) impaired water → "TMDL required, stricter discharge limits" (HIGH)
Brownfields > 3 → "Phase I ESA recommended" (MODERATE)
Soils with HSG D → "Poorly draining soils — stormwater design impact" (MODERATE)
SECTION ORDER (skip sections with no data):
Site overview — address, coordinates, county, elevation range, land cover, area
FEMA flood zones — table: zone | subtype | SFHA | risk level
Soils — per unit: HSG, drainage class, slope, flood frequency, building/septic limitations
Atlas 14 rainfall — IDF table (rows: 15min, 1hr, 6hr, 12hr, 24hr, 3day; cols: 2yr–100yr). Bold the 24hr row. Include Atlas 14 volume.
Natural hazard risk — NRI ratings by hazard type
Wetlands — count, type breakdown, Section 404 note
Water resources — streams with distances, impaired waters
Contamination — Superfund, brownfields (with distances/status), USTs, NPDES
Seismic & dams — ASCE 7-22 params (SDS, SD1, SDC), nearby dams with hazard rating
Infrastructure — hospitals, fire stations, schools, EMS counts
Demographics — population, median income, vacancy rate
FORMATTING:
Use markdown tables for flood zones, rainfall IDF, soils, brownfields
Cite source agencies (FEMA, NRCS, NOAA Atlas 14, EPA) not just "GeoTap"
Include distances and bearings for nearby features (e.g., "0.8 mi NW")
"_noData: true" means queried but nothing found — mention where relevant ("no Superfund sites" is positive)
End with: "Data sourced from US federal agencies via GeoTap. Verify critical findings before engineering or regulatory decisions."
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Job ID returned from collect_site_data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description must disclose behavior. It explains polling mechanism and that it returns results, but does not mention failure modes, timeouts, or potential side effects. Still, it provides more than minimal info.
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?
Description is extremely long (500+) with extensive output formatting instructions. While front-loaded with purpose, the verbosity reduces conciseness. Could be more succinct.
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?
No output schema, so description fully specifies output handling: critical flags, section order, formatting, and source attribution. Complete guidance for the agent to present results correctly.
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?
Only one parameter with 100% schema coverage. Schema description is adequate. Description does not add new meaning to the parameter beyond the schema, maintaining baseline.
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 checks status and retrieves results from a data collection job, with specific polling advice. It distinguishes from sibling tools like collect_site_data.
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?
Gives explicit polling guidance (every 10 seconds until completed) and implies use after collect_site_data. Lacks explicit when-not-to-use or alternatives, but context is sufficient.
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.
v3.0.5collect_site_dataget_llms_txtget_resultsScored across 3 tools
Each tool has a distinct purpose: collect_site_data starts data collection, get_results polls job status, and get_llms_txt provides API documentation. No overlap in functionality.
Tool names follow a consistent verb_noun pattern (e.g., collect_site_data, get_results), but get_llms_txt uses an abbreviation (llms) that is slightly less conventional, though still clear.
With only three tools, the server is minimal but appropriate for its focused scope: initiating data collection, polling for results, and accessing API documentation. It could benefit from a cancellation tool, but the count is reasonable.
The tool set covers the core workflow: submit job (collect_site_data), retrieve results (get_results), and discover capabilities (get_llms_txt). Missing options like canceling a job or listing previous jobs are minor omissions for a single-purpose API.
Weather, climate, terrain, fire and flood risk data for any point or polygon on Earth. Free tier.
Federal environmental records near any US location, with dates and provenance; never a safety score.
US site diligence for agents: parcels, power, flood, zoning rules and more, each with its source.
FEMA flood zone, hazard history and demographics for any US address, with sources on every answer.
