F
licenseB
qualityD
maintenanceTypeScript MCP server for accessing Department of Labor enforcement data, OSHA inspections, and SAM.gov contract opportunities via natural language queries.
28
-
US Government Data
by CBLU2005
us-govdata-mcp
用于美国政府数据的 MCP 服务器 — 从 Claude、Cursor 或任何 Model Context Protocol 客户端搜索建筑许可证、联邦合同机会（SAM.gov）和国家医疗保健提供者注册中心（NPI/NPPES）。
所有三个数据源均来自官方政府出版物（城市开放数据门户、SAM.gov 的公共数据提取、CMS NPPES API）——无需 HTML 抓取、无需登录、无需脆弱的 CSS 选择器。繁重的工作由三个生产级 Apify Actor 完成，这些 Actor 在您自己的 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
工具
工具 | 搜索内容 | 典型筛选条件 | 价格* |
| 来自 10 个官方城市/县开放数据源的建筑许可证（纽约市、芝加哥、洛杉矶、奥斯汀、旧金山、新奥尔良、巴吞鲁日、马里兰州蒙哥马利县、弗吉尼亚州诺福克）——许可证类型、状态、估价、承包商姓名/执照 | 城市、签发日期范围、许可证类型、全文搜索、最低估价 | $0.005 / 条记录 |
| 来自 SAM.gov 的联邦 RFP、招标书、寻找来源和授标通知——包含合同官员的电子邮件和电话 | 关键词、NAICS、通知类型、预留类别（8A、WOSB、HUBZone...）、机构、州、日期 | $0.004 / 条记录 |
| 官方 CMS NPI 注册中心，包含 800 多万美国医疗提供者和医疗机构——专业、执照、执业电话/传真、授权官员 | 专业、州、城市、邮政编码（通配符）、提供者/机构名称 | $0.002 / 条记录 |
* 诚实的定价说明： 这些工具运行由 CBLU 发布的付费、按结果计费的 Apify Actor。您的 Apify 账户仅按实际返回的记录收费——没有订阅费或启动费。每个工具默认每次调用返回 25 条结果，因此一次典型调用的成本不到一分钱（25 条许可证 ≈ $0.13；25 条合同通知 ≈ $0.10；25 条提供者信息 ≈ $0.05）。Apify 的免费计划包含每月平台积分，足以让您免费随意使用这些工具。包含完整定价详情的 Actor 页面：
快速开始
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-mcpCursor / 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.jsDocker：
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 HTTP3. 向您的 AI 代理询问类似问题
"查找本月在奥斯汀签发的价值超过 50 万美元的新建建筑许可证，并包含承包商名称。"
"是否有任何活跃的小型企业预留网络安全招标，且响应截止日期在今天之后？请包含合同官员的电子邮件。"
"列出大迈阿密地区（邮政编码 331）的牙医及其执业电话号码。"*
传输方式
stdio（默认）——桌面 MCP 客户端使用的传输方式：
us-govdata-mcpStreamable HTTP——无状态端点，位于
POST /mcp，健康检查位于GET /healthz：us-govdata-mcp --http 3000（或设置MCP_HTTP_PORT=3000）
环境变量
变量 | 必需 | 用途 |
| 用于工具调用 | 您的 Apify API 令牌。服务器启动和工具列表无需此令牌即可工作；在设置令牌之前，工具调用将返回设置指南。 |
| 否 | 设置为 |
| 否 | 在此端口上以 Streamable HTTP 模式启动，而不是 stdio。 |
工作原理
每个工具都会验证其参数（zod），构建 Actor 输入，并通过 Authorization: Bearer 标头（绝不放在 URL 中）使用您的令牌调用 Apify API 的 run-sync-get-dataset-items 端点。Actor 在您的账户下的 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。
相关资源
Apify Store 上所有 CBLU Actor 的个人资料：https://apify.com/cblu
Model Context Protocol：https://modelcontextprotocol.io
许可证
MIT © CBLU
Available Tools
3 toolssearch_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 | Default |
|---|---|---|---|
| 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 | Default |
|---|---|---|---|
| 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 | Default |
|---|---|---|---|
| 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 updates
v0.1.0- First observed
search_building_permits - First observed
search_federal_contract_opportunities - First observed
search_healthcare_providers
TDQS
A4.3/5.0
Scored 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
Related MCP Connectors
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
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.
MCP access to the U.S. federal procurement graph: contracts, opportunities, entities, and more.
Search verified-open US grants (federal, state, foundation). Read-only MCP for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAggregate US business filings, SEC reports, federal court cases, federal spending awards, and professional licenses through a single MCP server.1MIT
whetstone-mcpofficial
AlicenseAqualityDmaintenanceAn MCP server for U.S. public-records data, enabling AI agents to search business registrations, screen names against government watchlists, and pull federal awards.423 npmMIT- AlicenseAqualityCmaintenanceMCP 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.4MIT