What can you do with this server?

This server lets you search three major US government data sources — building permits, federal contract opportunities, and healthcare providers — using paid Apify actors. * Search Building Permits (search_building_permits): Query official open-data portals across 9 sources (NYC, Chicago, LA, Austin, SF, New Orleans, Baton Rouge, Montgomery County MD, Norfolk VA). Filter by city, permit type, issue date range (issuedAfter/issuedBefore), minimum valuation, and full-text keyword. Returns permit number, type, work description, status, address, valuation, and contractor details. Costs $0.005/record. * Search Federal Contract Opportunities (search_federal_contract_opportunities): Query SAM.gov for RFPs, solicitations, sources sought, and award notices. Filter by keyword, NAICS codes, notice type, small-business set-asides (8A, WOSB, HUBZone, SDVOSBC), agency, place-of-performance state, and posted/response-due dates. Returns contracting officer names, emails, phone numbers, and full notice descriptions. Costs $0.004/record. * Search Healthcare Providers (search_healthcare_providers): Query the CMS NPPES NPI Registry (8M+ providers). Filter by specialty/taxonomy, state, city, ZIP (wildcard supported, e.g. 331*), provider name, organization name, and enumeration type (individual/organization). Returns NPI number, specialty, state license, practice address, phone, fax, and authorized official details. Costs $0.002/record. General notes: * All data comes from official government sources — no scraping or logins required * Runs on your own Apify account (free plan includes monthly credits) * Supports dry-run mode (APIFY_DRY_RUN=1) for testing without charges * Default: 25 records per call (typical calls cost fractions of a cent)

de en es ja ko ru zh

US Government Data

by CBLU2005

Overview Schema Related Servers Score Discussions

TypeScript

Remote

us-govdata-mcp

MCP server for US government data — search building permits, federal contract opportunities (SAM.gov), and the national healthcare provider registry (NPI/NPPES) from Claude, Cursor, or any Model Context Protocol client.

CBLU2005/us-govdata-mcp MCP server

License: MIT Node >= 18

All three data sources are official government publications (city open-data portals, SAM.gov's public extract, the CMS NPPES API) — no HTML scraping, no logins, no fragile selectors. The heavy lifting is done by three production Apify actors that run on your own Apify account.

Try it in 30 seconds — no account, no charge

Before you decide whether this is worth an API token, run it with none:

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

That is the whole setup. In dry-run mode every tool returns realistic sample records plus the exact Apify API request it would have sent — so you can see the real shape of the data, confirm your agent calls the tools correctly, and read the pricing disclosure in each tool description, without creating an account, pasting a token, or spending anything.

Ask your agent something like "find building permits over $500k issued in Austin this month" and watch the tool call happen end to end. When you want live data, delete the APIFY_DRY_RUN line and add an APIFY_TOKEN (below).

Related MCP server: PubRecords MCP

Tools

Tool	What it searches	Typical filters	Price*
`search_building_permits`	Building permits from 10 official city/county open-data sources (NYC, Chicago, LA, Austin, SF, New Orleans, Baton Rouge, Montgomery Co. MD, Norfolk VA) — permit type, status, valuation, contractor name/license	cities, issued date range, permit type, full-text, min valuation	$0.005 / record
`search_federal_contract_opportunities`	Federal RFPs, solicitations, sources-sought and award notices from SAM.gov — with contracting-officer emails and phones	keyword, NAICS, notice type, set-aside (8A, WOSB, HUBZone...), agency, state, dates	$0.004 / record
`search_healthcare_providers`	The official CMS NPI registry of 8M+ US providers and healthcare organizations — specialty, license, practice phone/fax, authorized officials	specialty, state, city, ZIP (wildcards), provider/organization name	$0.002 / record

* Honest pricing disclosure: these tools run paid, pay-per-result Apify actors published by CBLU. Your Apify account is charged only for records actually returned — there are no subscriptions or start fees. Every tool defaults to 25 results per call, so a typical call costs a fraction of a cent (25 permits ≈ $0.13; 25 contract notices ≈ $0.10; 25 providers ≈ $0.05). Apify's free plan includes monthly platform credit, which is enough to use these tools casually at no cost. Actor pages with full pricing details:

Quick start

1. Get an Apify token (free, ~2 minutes)

Sign up at https://console.apify.com/sign-up (free plan works).
Copy your API token from https://console.apify.com/settings/integrations.

The server starts and lists its tools without a token — the token is only needed when a tool is actually called.

2. Add the server to your MCP client

Claude Desktop (claude_desktop_config.json → Settings → Developer → Edit Config):

{
  "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 / other MCP clients (same shape as Claude Desktop):

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

From a local clone:

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. Ask your AI agent things like

"Find building permits for new construction over $500k issued in Austin this month, with contractor names."
"Any active small-business set-aside cybersecurity solicitations with a response deadline after today? Include the contracting officer's email."
"List dentists in the greater Miami area (ZIP 331) with their practice phone numbers."*

Transports

stdio (default) — what desktop MCP clients use: us-govdata-mcp
Streamable HTTP — stateless endpoint at POST /mcp, health check at GET /healthz: us-govdata-mcp --http 3000 (or set MCP_HTTP_PORT=3000)

Environment variables

Variable	Required	Purpose
`APIFY_TOKEN`	For tool calls	Your Apify API token. Server start & tool listing work without it; tool calls return a setup guide until it is set.
`APIFY_DRY_RUN`	No	Set to `1` to return canned sample records without any network call or charge — the response includes the exact Apify API request that would have been sent. Useful for testing and CI.
`MCP_HTTP_PORT`	No	Start in Streamable HTTP mode on this port instead of stdio.

How it works

Each tool validates its arguments (zod), builds the actor input, and calls the Apify API's run-sync-get-dataset-items endpoint with your token via an Authorization: Bearer header (never in the URL). The actor runs on the Apify platform under your account and the resulting dataset items are returned directly as the tool result. This server keeps no state and sees no data beyond passing it through.

Development

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

The test suite needs no Apify account and no network — it uses APIFY_DRY_RUN=1.

Apify Store profile with all CBLU actors: https://apify.com/cblu
Model Context Protocol: https://modelcontextprotocol.io

License

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

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

ActivityMaintained

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
ahel
io.ahel
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Government Data Cryptocurrency Open Data
2
Tango
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
2

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 4 months ago (2026-05-10 19:19 UTC)
28
PubRecords MCP
Government Data Open Data Legal & Compliance
bch1212
A
license
Not graded
quality
D
maintenance
Aggregate US business filings, SEC reports, federal court cases, federal spending awards, and professional licenses through a single MCP server.
Updated 4 months ago (2026-05-13 13:40 UTC)
MIT
whetstone-mcpofficial
Government Data Open Data Search
whetstone-tools
A
license
A
quality
B
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 3 months ago (2026-06-17 03:36 UTC)
4
46
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 15 days ago (2026-08-20 07:32 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CBLU2005/us-govdata-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

us-govdata-mcp

Try it in 30 seconds — no account, no charge

Tools

Quick start

1. Get an Apify token (free, ~2 minutes)

2. Add the server to your MCP client

3. Ask your AI agent things like

Transports

Environment variables

How it works

Development

Related

License

Available Tools

TDQS

TDQS

TDQS

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

DOL WHD MCP

PubRecords MCP

whetstone-mcpofficial

us-gov-data-mcp

Latest Blog Posts

MCP directory API