Claude、Cursor、WindsurfなどのAIツールを、80以上の米連邦政府の環境・インフラデータソースに接続します。
GeoTapは、FEMA、USGS、EPA、NOAA、USDA、USFWS、DOT、国勢調査局などのデータを集約し、MCP（Model Context Protocol）を通じてアクセス可能にします。
Webアプリ: geotapdata.com — コード不要。地図上で範囲を指定して視覚的にデータを探索できます。
Node.js (v18以降) — こちらからダウンロード
APIキー登録用のメールアドレス
geotapdata.com/developers にアクセスし、メールアドレスを登録して無料のAPIキーを取得してください。
APIキーがメールで送信されます。保存しておいてください。次のステップで使用します。
お使いのAIツールを選択し、手順に従ってください。MCPサーバーは npx を介して自動的にインストールされるため、手動ダウンロードは不要です。
Claude Desktopを開く
設定（歯車アイコン）→ 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が接続されています
以下のコマンドを実行して、Claude CodeのMCPサーバーにGeoTapを追加します：
claude mcp add geotap -- npx -y geotap-mcp-server次に、APIキーを環境変数として設定します。シェルプロファイル（~/.zshrc、~/.bashrc など）に以下を追加してください：
export GEOTAP_API_KEY="your-api-key-here"ターミナルを再起動し、Claude Codeを起動します。GeoTapツールが自動的に利用可能になります。
Cursorを開く
設定（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を開く
設定 → 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_API_KEY 環境変数を設定した状態で geotap-mcp コマンドを指定してください。
接続が完了したら、AIアシスタントに米国内の任意の場所のデータを取得するよう依頼してください。GeoTapは80以上の連邦政府ソースから一度にデータを収集します。場所を指定して、知りたいことを尋ねるだけです：
"Collect site data for 123 Main St, Austin TX"データが返ってきたら（約60〜120秒）、以下のようなフォローアップの質問が可能です：
"この場所は洪水ハザードエリアに含まれていますか？"
"ここの土壌タイプは何ですか？また、カーブナンバーはいくつですか？"
"近くに汚染の懸念はありますか？"
"100年に一度の降雨量はどれくらいですか？"
"この場所を開発するにはどのような許可が必要ですか？"
"主要な環境リスクを要約してください"
問題 | 解決策 |
サーバーが起動しない / "GEOTAP_API_KEY is required" | MCP設定の |
"npx: command not found" | npxを含む Node.js (v18+) をインストールしてください |
Claude Desktopにツールが表示されない | Claude Desktopを完全に再起動してください（ウィンドウを閉じるだけでなく、終了して再起動） |
レート制限エラー | 少し待ってから再試行してください。バースト制限は1分単位です |
Related MCP server: PropertyScoop MCP Server
機関 | 利用可能なデータ |
FEMA | 洪水ハザードエリア、FIRMパネル、洪水保険料率マップ、洪水区域境界 |
USGS | 標高（3DEP 1m/10m/30m）、地質、河川水位計、地下水、土地利用（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スケール）
洪水ハザード、湿地、汚染のスクリーニング
許認可プロセスの分析（セクション404、NPDES、洪水原開発）
フェーズI ESA（環境アセスメント）のデスクトップデータ収集（EPAサイト、水質）
湿地特定支援（NWI + 土壌 + 水文学）
絶滅危惧種の生息地スクリーニング（USFWSの重要な生息地）
水質汚濁評価（EPA ATTAINS 303(d)リスト）
貢献を歓迎します！Issueの作成やプルリクエストをお願いします。
MIT
Webアプリ: geotapdata.com
Issue: 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.
