Claude, Cursor, Windsurf 및 기타 AI 도구를 80개 이상의 미국 연방 환경 및 인프라 데이터 소스에 연결하세요.
GeoTap은 FEMA, USGS, EPA, NOAA, USDA, USFWS, DOT, 인구조사국 등에서 데이터를 집계하며, MCP(Model Context Protocol)를 통해 액세스할 수 있습니다.
웹 앱: geotapdata.com — 코딩 없이 지도에 그림을 그려 데이터를 시각적으로 탐색할 수 있습니다.
Node.js (v18 이상) — 여기서 다운로드
API 키 등록을 위한 이메일 주소
**geotapdata.com/developers**에 접속하여 이메일로 등록하고 무료 API 키를 받으세요.
API 키가 이메일로 전송됩니다. 저장해 두세요 — 다음 단계에서 필요합니다.
아래에서 사용하는 AI 도구를 선택하고 지침을 따르세요. MCP 서버는 npx를 통해 자동으로 설치되므로 수동 다운로드가 필요하지 않습니다.
Claude Desktop을 엽니다.
설정(톱니바퀴 아이콘) → 개발자 → 설정 편집으로 이동합니다.
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초 소요), 다음과 같은 후속 질문을 할 수 있습니다:
"이 부지가 홍수 구역에 포함되나요?"
"이곳의 토양 유형은 무엇이며 곡선 번호(curve number)는 얼마인가요?"
"근처에 오염 우려 사항이 있나요?"
"100년 빈도 강우량은 얼마인가요?"
"이 부지를 개발하려면 어떤 허가가 필요한가요?"
"주요 환경 위험 요소를 요약해 주세요"
문제 | 해결 방법 |
서버가 시작되지 않음 / "GEOTAP_API_KEY is required" | MCP 설정의 |
"npx: command not found" | npx가 포함된 Node.js(v18+)를 설치하세요 |
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점)
홍수 구역, 습지 및 오염 심사
허가 경로 분석 (섹션 404, NPDES, 홍수터 개발)
1단계 환경 현장 조사(ESA) 데스크톱 데이터 수집 (EPA 부지, 수질)
습지 구분 지원 (NWI + 토양 + 수문)
멸종 위기 종 서식지 심사 (USFWS 핵심 서식지)
수질 악화 평가 (EPA ATTAINS 303(d) 목록)
기여를 환영합니다! 이슈를 열거나 풀 리퀘스트를 보내주세요.
MIT
웹 앱: 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.
