de en es ja ko ru zh

US Government Data

Name: US Government Data
Author: CBLU2005

by CBLU2005

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

us-govdata-mcp

미국 정부 데이터용 MCP 서버 — Claude, Cursor 또는 모든 Model Context Protocol 클라이언트에서 건축 허가, 연방 계약 기회(SAM.gov), 전국 의료 제공자 등록부(NPI/NPPES)를 검색할 수 있습니다.

CBLU2005/us-govdata-mcp MCP server

License: MIT Node >= 18

세 데이터 소스 모두 공식 정부 발행 자료(도시 오픈데이터 포털, SAM.gov 공개 추출물, CMS NPPES API)입니다 — HTML 스크래핑, 로그인, 취약한 선택자가 필요 없습니다. 핵심 작업은 사용자 본인의 Apify 계정에서 실행되는 세 개의 프로덕션 Apify 액터가 수행합니다.

30초 만에 사용해보기 — 계정도, 요금도 없이

API 토큰이 필요한지 결정하기 전에, 토큰 없이 실행해보세요:

{
  "mcpServers": {
    "us-govdata": {
      "command": "npx",
      "args": ["-y", "github:CBLU2005/us-govdata-mcp"],
      "env": { "APIFY_DRY_RUN": "1" }
    }
  }
}

이것이 전체 설정입니다. 드라이런 모드에서는 모든 도구가 실제 샘플 레코드와 전송되었을 Apify API 요청을 반환하므로 — 계정을 만들거나, 토큰을 붙여넣거나, 비용을 지출하지 않고도 데이터의 실제 형태를 확인하고, 에이전트가 도구를 올바르게 호출하는지 확인하고, 각 도구 설명에 포함된 가격 정보를 읽을 수 있습니다.

에이전트에게 "이번 달 오스틴에서 발급된 50만 달러 이상 건축 허가를 찾아줘" 같은 질문을 해보고 엔드투엔드 도구 호출을 확인하세요. 실제 데이터가 필요할 때는 APIFY_DRY_RUN 줄을 삭제하고 APIFY_TOKEN을 추가하세요(아래 참조).

Related MCP server: PubRecords MCP

도구

도구	검색 대상	일반 필터	가격*
`search_building_permits`	10개 공식 도시/카운티 오픈데이터 소스(뉴욕, 시카고, LA, 오스틴, 샌프란시스코, 뉴올리언스, 배턴루지, 메릴랜드주 몽고메리 카운티, 버지니아주 노퍽)의 건축 허가 — 허가 유형, 상태, 평가액, 계약자 이름/면허	도시, 발급일 범위, 허가 유형, 전체 텍스트, 최소 평가액	$0.005 / 레코드
`search_federal_contract_opportunities`	SAM.gov의 연방 RFP, 제안요청서, 사전규격공고, 낙찰 공고 — 계약 담당관 이메일 및 전화번호 포함	키워드, NAICS, 공고 유형, 중소기업 우선(8A, WOSB, HUBZone...), 기관, 주, 날짜	$0.004 / 레코드
`search_healthcare_providers`	800만 명 이상의 미국 제공자 및 의료 기관이 등록된 공식 CMS NPI 등록부 — 전문 분야, 면허, 진료소 전화/팩스, 공인 담당자	전문 분야, 주, 도시, 우편번호(와일드카드), 제공자/기관명	$0.002 / 레코드

* 정직한 가격 공개: 이 도구들은 CBLU가 게시한 유료, 결과당 지불 방식의 Apify 액터를 실행합니다. Apify 계정에는 실제로 반환된 레코드에 대해서만 요금이 청구됩니다 — 구독료나 시작 수수료는 없습니다. 모든 도구는 호출당 기본 25개 결과를 반환하므로, 일반적인 호출 비용은 1센트 미만입니다(허가 25건 ≈ $0.13; 계약 공고 25건 ≈ $0.10; 제공자 25건 ≈ $0.05). Apify 무료 요금제에는 월별 플랫폼 크레딧이 포함되어 있어 이 도구들을 무료로 간편하게 사용할 수 있습니다. 전체 가격 정보가 포함된 액터 페이지:

빠른 시작

1. Apify 토큰 받기(무료, 약 2분 소요)

https://console.apify.com/sign-up에서 가입하세요(무료 요금제 사용 가능).
https://console.apify.com/settings/integrations에서 API 토큰을 복사하세요.

서버는 토큰 없이도 시작되어 도구 목록을 표시합니다 — 토큰은 도구가 실제로 호출될 때만 필요합니다.

2. MCP 클라이언트에 서버 추가하기

Claude Desktop (claude_desktop_config.json → 설정 → 개발자 → 구성 편집):

{
  "mcpServers": {
    "us-govdata": {
      "command": "npx",
      "args": ["-y", "github:CBLU2005/us-govdata-mcp"],
      "env": {
        "APIFY_TOKEN": "your_apify_token_here"
      }
    }
  }
}

Claude Code:

claude mcp add us-govdata -e APIFY_TOKEN=your_apify_token_here -- npx -y github:CBLU2005/us-govdata-mcp

Cursor / Windsurf / 기타 MCP 클라이언트 (Claude Desktop과 동일한 형식):

{
  "mcpServers": {
    "us-govdata": {
      "command": "npx",
      "args": ["-y", "github:CBLU2005/us-govdata-mcp"],
      "env": { "APIFY_TOKEN": "your_apify_token_here" }
    }
  }
}

로컬 클론에서:

git clone https://github.com/CBLU2005/us-govdata-mcp.git
cd us-govdata-mcp
npm install && npm run build
# then point your client at: node /path/to/us-govdata-mcp/dist/index.js

Docker:

docker build -t us-govdata-mcp .
docker run -i --rm -e APIFY_TOKEN=your_apify_token_here us-govdata-mcp        # stdio
docker run --rm -p 3000:3000 -e APIFY_TOKEN=... us-govdata-mcp --http 3000    # Streamable HTTP

3. AI 에이전트에게 다음과 같은 질문을 해보세요

"이번 달 오스틴에서 발급된 50만 달러 이상 신축 건축 허가를 계약자 이름과 함께 찾아줘."
"마감일이 오늘 이후인 활성 중소기업 우선 사이버보안 제안요청서가 있으면 계약 담당관 이메일을 포함해서 알려줘."
"마이애미 지역(우편번호 331)의 치과의사 목록을 진료소 전화번호와 함께 보여줘."*

전송 방식

stdio (기본값) — 데스크톱 MCP 클라이언트가 사용: us-govdata-mcp
Streamable HTTP — 상태 비저장 엔드포인트 POST /mcp, 상태 확인 GET /healthz: us-govdata-mcp --http 3000 (또는 MCP_HTTP_PORT=3000 설정)

환경 변수

변수	필수 여부	용도
`APIFY_TOKEN`	도구 호출 시	Apify API 토큰. 서버 시작 및 도구 목록 표시는 토큰 없이도 작동하며, 설정될 때까지 도구 호출 시 설정 안내를 반환합니다.
`APIFY_DRY_RUN`	아니요	`1`로 설정하면 네트워크 호출이나 요금 없이 샘플 레코드를 반환합니다 — 응답에는 전송되었을 Apify API 요청이 포함됩니다. 테스트 및 CI에 유용합니다.
`MCP_HTTP_PORT`	아니요	stdio 대신 이 포트에서 Streamable HTTP 모드로 시작합니다.

작동 방식

각 도구는 인수(zod)를 검증하고, 액터 입력을 구성한 후, 토큰을 사용하여 Authorization: Bearer 헤더(URL에는 절대 포함되지 않음)를 통해 Apify API의 run-sync-get-dataset-items 엔드포인트를 호출합니다. 액터는 사용자 계정으로 Apify 플랫폼에서 실행되며, 결과 데이터셋 항목이 도구 결과로 직접 반환됩니다. 이 서버는 상태를 유지하지 않으며 데이터를 단순히 전달하는 것 외에는 어떤 데이터도 보지 않습니다.

개발

npm install
npm test          # builds + runs the full smoke suite (introspection, tokenless
                  # error path, dry-run request construction, HTTP transport)

테스트 스위트는 Apify 계정이나 네트워크가 필요 없습니다 — APIFY_DRY_RUN=1을 사용합니다.

라이선스

MIT © CBLU

Available Tools

3 tools

search_building_permitsSearch US building permitsA

Search recently issued US building permits from official city open-data portals (New York City, Chicago, Los Angeles, Austin, San Francisco, New Orleans, Baton Rouge, Montgomery County MD, Norfolk VA). Returns normalized permit records: permit number, type, work description, status, issue date, address, project valuation, and contractor name/license where published. Great for construction lead generation and market research. Runs the paid Apify actor https://apify.com/cblu/us-building-permits-scraper on YOUR Apify account (requires APIFY_TOKEN; pay per result: $0.005 per permit record ($5.00 / 1,000), charged only for records actually returned).

ParametersJSON Schema

Name	Required	Description
`cities`	No	Cities/counties to search. Use ["all"] or omit for every supported source. Each city is queried up to maxResultsPerCity.
`issuedAfter`	No	Only permits issued on/after this date (YYYY-MM-DD). Recommended — keeps results fresh and runs fast.
`searchQuery`	No	Full-text search across the source dataset, e.g. 'solar', 'pool', 'demolition', 'ADU'.
`issuedBefore`	No	Only permits issued on/before this date (YYYY-MM-DD).
`minValuation`	No	Only permits with declared project value >= this USD amount (permits without a published valuation are excluded when set).
`maxResultsPerCity`	No	Max permit records per selected city (1-2000, default 25). Each returned record is billed at $0.005 per permit record ($5.00 / 1,000).
`permitTypeContains`	No	Case-insensitive substring match on permit type / class / work type, e.g. 'electrical', 'roof', 'plumbing', 'new construction'.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the tool runs on the user's Apify account requiring APIFY_TOKEN, pay-per-result pricing, and returns normalized permit records. Lacks details on error handling or rate limits but is transparent about costs and external dependence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

4-sentence description, well-structured: purpose, returned fields, use case, technical details and pricing. Front-loaded with core purpose. The last sentence is dense with pricing details but remains understandable. Efficient for the information conveyed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, supported cities, return fields, cost model, and authentication requirement. Lacks explanation of error handling if APIFY_TOKEN missing, and output structure is not described (no output schema). For 7 optional parameters and paid actor, the main gaps are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already has descriptions for all 7 parameters (100% coverage). The description adds value by explaining the use case (lead generation) and cost implications (e.g., maxResultsPerCity billable). Also adds recommended usage hint for issuedAfter. Supplements schema with decision-relevant context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches US building permits from specific cities, specifies normalized fields returned, and distinguishes from sibling tools which cover federal contracts and healthcare providers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context for construction lead generation and market research, and mentions the paid Apify actor with pricing. Does not explicitly state when not to use or compare to alternatives, but sibling tools are clearly different.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_federal_contract_opportunitiesSearch federal contract opportunities (SAM.gov)A

Search US federal contract opportunities (RFPs, solicitations, sources sought, award notices) from SAM.gov's official public data extract — including contracting-officer names, emails, and phone numbers. Filter by keyword, NAICS code, notice type, small-business set-aside, agency, place-of-performance state, and dates. Great for GovCon business development. Runs the paid Apify actor https://apify.com/cblu/sam-gov-contract-opportunities-scraper on YOUR Apify account (requires APIFY_TOKEN; pay per result: $0.004 per opportunity ($4.00 / 1,000), charged only for records actually returned).

ParametersJSON Schema

Name	Required	Description
`keyword`	No	Case-insensitive match against notice title, solicitation number, and description, e.g. 'janitorial', 'cybersecurity', 'drone'.
`popStates`	No	Two-letter place-of-performance state codes, e.g. ['TX', 'FL'].
`setAsides`	No	Small-business set-aside codes or label text, e.g. 'SBA' (total small business), '8A', 'WOSB', 'SDVOSBC', 'HZC' (HUBZone).
`activeOnly`	No	Only notices SAM.gov currently marks active (not archived). Set false for historical/award research.
`maxResults`	No	Max opportunities to return (1-5000, default 25). Each returned record is billed at $0.004 per opportunity ($4.00 / 1,000).
`naicsCodes`	No	NAICS industry codes; prefixes work, e.g. '541511' or just '54' for all professional services.
`noticeTypes`	No	Notice types (case-insensitive substring), e.g. 'Solicitation', 'Presolicitation', 'Sources Sought', 'Combined Synopsis', 'Award Notice'.
`postedAfter`	No	Only notices posted on/after this date (YYYY-MM-DD). Strongly recommended — makes runs much faster.
`postedBefore`	No	Only notices posted on/before this date (YYYY-MM-DD).
`agencyContains`	No	Case-insensitive substring match on department/sub-tier/office, e.g. 'VETERANS AFFAIRS', 'FOREST SERVICE', 'DEFENSE'.
`responseDueAfter`	No	Only notices whose response deadline is on/after this date — set to today for opportunities still open for bids.
`includeDescription`	No	Include the notice's full description text on every record.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses pricing ($0.004 per opportunity), that it runs on an Apify actor, and requires APIFY_TOKEN. This is good transparency, though it could mention error handling or 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that is front-loaded with the tool's purpose. It is concise and contains no wasted words, though it could be slightly more structured with bullet points for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain return values. It mentions some output fields (contracting-officer names, emails) but does not fully describe the structure of returned records. Given the tool's complexity (12 parameters), it is somewhat incomplete on outputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all 12 parameters have descriptions). The tool description adds value beyond schema by explaining the pricing implication of maxResults and recommending postedAfter for performance. It does not introduce new parameters but enriches understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches US federal contract opportunities from SAM.gov, listing specific notice types (RFPs, solicitations, etc.) and data included. It distinguishes itself from sibling tools (building permits, healthcare providers) by targeting federal contracts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for GovCon business development and lists filters but does not explicitly state when to use it over alternatives or when not to use it. It provides context but lacks direct exclusions or comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_healthcare_providersSearch US healthcare providers (NPI registry)A

Search the official CMS NPPES NPI Registry of all US healthcare providers and organizations. Returns NPI number, provider/organization name, specialty (taxonomy), state license, practice address with phone and fax, and for organizations the authorized official's name/title/phone. Filter by specialty, state, city, ZIP (wildcards like '331*'), or name. Great for healthcare sales lists, provider verification, and directory enrichment. Runs the paid Apify actor https://apify.com/cblu/npi-healthcare-providers-scraper on YOUR Apify account (requires APIFY_TOKEN; pay per result: $0.002 per provider record ($2.00 / 1,000), charged only for records actually returned).

ParametersJSON Schema

Name	Required	Description
`city`	No	Practice-location city, e.g. 'Austin'.
`state`	No	Two-letter US state code of the practice location, e.g. 'TX'.
`lastName`	No	Provider last name (individual lookups). Trailing wildcard supported.
`firstName`	No	Provider first name (individual lookups). Trailing wildcard supported, e.g. 'jo*'.
`maxResults`	No	Max provider records to return (1-5000, default 25). Each returned record is billed at $0.002 per provider record ($2.00 / 1,000).
`postalCode`	No	Practice-location ZIP. Prefix wildcards supported: '331*' matches all ZIPs starting 331 (greater Miami).
`enumerationType`	No	'individual' (NPI-1: physicians, dentists, nurses...) or 'organization' (NPI-2: clinics, hospitals, pharmacies...). Omit for both.
`organizationName`	No	Organization name (NPI-2 lookups). Trailing wildcard supported, e.g. 'mayo*'.
`taxonomyDescription`	No	Provider specialty / taxonomy, e.g. 'Dentist', 'Family Medicine', 'Chiropractor', 'Physical Therapist', 'Pharmacy'. Exact taxonomy codes also work.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses the tool runs a paid Apify actor on the user's account, requires APIFY_TOKEN, and explains billing ($0.002 per record). This covers safety and cost implications well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat long but structured with key info upfront (what it is, what it returns, filters). Every sentence adds value: purpose, returned data, filters, use cases, and billing details. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no output schema, and no annotations, the description provides sufficient context: it lists return fields, explains all filter parameters, and covers cost. It lacks only explicit mention of pagination or error handling, but overall it is quite complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptive parameter definitions. The description adds value by explaining wildcard usage (e.g., '331*', 'mayo*') and billing implications of maxResults. This enhances the agent's understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches the official CMS NPPES NPI Registry for US healthcare providers and organizations, listing returned fields and filter criteria. It distinguishes itself from sibling tools (building permits, federal contracts) by its specific domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases: 'healthcare sales lists, provider verification, and directory enrichment.' It does not specify when not to use this tool, but the clear purpose and unrelated siblings make this adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.1.0Jul 12, 2026
- First observedsearch_building_permits
- First observedsearch_federal_contract_opportunities
- First observedsearch_healthcare_providers

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored 2026-07-12 15:55 across 3 tools

Disambiguation5/5

Each tool targets a distinct and clearly separate domain: building permits, federal contract opportunities, and healthcare providers. There is no overlap in functionality or purpose.

Naming Consistency5/5

All three tools follow the same 'search_<domain>' naming pattern, making them predictable and easy to understand. The convention is consistent throughout.

Tool Count5/5

With only three tools, the set is small but well-scoped for the specific data sources it covers. Each tool serves a clear, valuable purpose without unnecessary bloat.

Completeness2/5

Despite the server name 'US Government Data' implying broad coverage, it only provides access to three narrow datasets (building permits from select cities, federal contracts, and healthcare providers). Many major government data categories are missing, such as census, federal spending, or regulations.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

openfolio
io.github.dodenbach
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Government Data Open Data Search
1
AutomationNation data tools (via Apify)OAuth
io.github.retracn
17 data tools in one MCP server, run on Apify: Google Shopping, Flights, Hotels, News, Images, Videos, Ads Transparency, Jobs and Trends; YouTube transcripts; AI visibility checks; Google Maps leads; App Store and Google Play reviews. Pay per result. Sign in with Apify (OAuth) or an API token.
Research & Data Search Web Scraping
1
TangoOAuth
dev.tango
MCP access to the U.S. federal procurement graph: contracts, opportunities, entities, and more.
Government Data Open Data
2
GrantSonar A
io.github.romulusfoundry
Search verified-open US grants (federal, state, foundation). Read-only MCP for AI agents.
Government Data Open Data
92

Related MCP Servers

DOL WHD MCP
Government Data Search Open Data
UHQ-Actual
F
license
B
quality
D
maintenance
TypeScript MCP server for accessing Department of Labor enforcement data, OSHA inspections, and SAM.gov contract opportunities via natural language queries.
Updated 5 months ago (2026-05-10 19:19 UTC)
28
-
PubRecords MCP
Government Data Open Data Legal & Compliance
bch1212
A
license
Not graded
quality
C
maintenance
Aggregate US business filings, SEC reports, federal court cases, federal spending awards, and professional licenses through a single MCP server.
Updated 16 days ago (2026-10-01 15:49 UTC)
1
MIT
whetstone-mcpofficial
Government Data Open Data Search
whetstone-tools
A
license
A
quality
D
maintenance
An MCP server for U.S. public-records data, enabling AI agents to search business registrations, screen names against government watchlists, and pull federal awards.
Updated 4 months ago (2026-06-17 03:36 UTC)
4
23 npm
MIT
us-gov-data-mcp
Government Data Finance Open Data
groundtruthtools
A
license
A
quality
C
maintenance
MCP server for querying US federal contracts and public company financial data from USAspending and SEC EDGAR. Enables searching expiring contracts, screening companies by metrics, and retrieving financial histories.
Updated 2 months ago (2026-08-20 07:32 UTC)
4
MIT

us-govdata-mcp

30초 만에 사용해보기 — 계정도, 요금도 없이

도구

빠른 시작

1. Apify 토큰 받기(무료, 약 2분 소요)

2. MCP 클라이언트에 서버 추가하기

3. AI 에이전트에게 다음과 같은 질문을 해보세요

전송 방식

환경 변수

작동 방식

개발

관련 링크

라이선스

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

DOL WHD MCP

PubRecords MCP

whetstone-mcpofficial

us-gov-data-mcp