How do I use us-gov-data-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@us-gov-data-mcp which federal contracts expire within 90 days with the highest value?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

us-gov-data-mcp

by groundtruthtools

Overview Schema Related Servers Score Discussions

Python

Remote

us-gov-data-mcp

An MCP server for US government data. Ask your AI assistant which federal contracts are expiring, or which public companies had the most revenue last year — and get answers you can verify against the government's own records.

Built on the US Treasury's USAspending API and the SEC's EDGAR XBRL data. No scraping, no API key, no account, no personal data.

Why this exists

Both of these sources publish everything and let you query almost none of it.

usaspending.gov cannot search by contract end date. But when a federal contract's period of performance ends, the work usually has to be re-competed — and those recompetes are the highest-probability opportunities in government contracting, visible in public data months before any solicitation appears.

sec.gov serves filings one company at a time. There is no way on the site to ask which public companies had revenue over $100 billion, or which hold the most cash. The SEC's frames API can answer that across all ~5,800 filers in one call, if you already know the XBRL tag and the period format.

This server answers the questions those sites can't.

Related MCP server: sec-edgar-mcp

Four tools

`find_expiring_contracts` — recompetes

Federal contracts coming up for re-bid, with the incumbent and days remaining. expiring_after_days sets your bid lead time, because a contract ending next week is useless to prepare for.

{
  "days_until_expiry": 120,
  "recipient": "PERATON ENTERPRISE SOLUTIONS LLC",
  "amount_usd": 682369225.00,
  "awarding_agency": "General Services Administration",
  "verify_url": "https://www.usaspending.gov/award/..."
}

`search_federal_contracts`

Awarded contracts by agency, keyword, date, or dollar amount. Who is winning federal work, what an agency spends, a competitor's history.

`screen_public_companies`

Rank every US public company by any reported financial metric.

"Which companies had revenue over $200 billion in 2023?"

{ "company": "Walmart Inc.", "value": 648125000000, "unit": "USD",
  "period_end": "2023-12-31", "period_type": "annual",
  "verify_url": "https://www.sec.gov/Archives/edgar/data/104169/..." }

`company_financial_history`

One company's reported history of a metric — revenue, net income, assets, cash flow — deduplicated, with the form type and filing date on each record.

Everything is verifiable

Each record carries a verify_url to the government filing it came from. Open it and compare.

That matters most with an AI in the loop: when an assistant reports a dollar figure, you should be able to check it against the source rather than trust the chain. If a value ever disagrees with the official record, that is a bug — please open an issue.

Three traps this handles for you

Raw SEC data misleads in three specific ways, each silent — you get a plausible wrong number, not an error.

A 10-Q reports the quarter and the year-to-date with the same end date. Comparing net income across filings silently mixes a three-month figure with a nine-month one. Every record carries period_type, and you can filter on it.
The same fact recurs across filings with different values. This year's 10-K restates last year's figures. Deduplicated to one record per period, most recent filing winning — the SEC's own treatment of restatements.
Companies switch XBRL tags over time. Microsoft filed Revenues until 2010 and a different tag afterwards. Taking the first tag that returns data yields a stale partial history; this merges across all of them.

Install

uvx --from git+https://github.com/groundtruthtools/us-gov-data-mcp us-gov-data-mcp

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "us-gov-data": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/groundtruthtools/us-gov-data-mcp",
        "us-gov-data-mcp"
      ],
      "env": { "SEC_USER_AGENT": "Your Name your@email.com" }
    }
  }
}

Works with any MCP client: Claude Desktop, Claude Code, Cursor, VS Code.

SEC_USER_AGENT is worth setting. SEC's fair-access policy requires a User-Agent containing a contact address, and requests without one get a 403. A default is included so the tools work out of the box, but identifying yourself is the polite thing and keeps you off a shared identity.

One quirk, learned the hard way: do not put a URL in that string. SEC returns 403 for any User-Agent containing one. Your Name your@email.com works; adding github.com/... does not.

Not on PyPI yet, so install from the repository. When it lands there this becomes a plain uvx us-gov-data-mcp.

Honest limits

Contracts: awarded, not open solicitations. For published bids, use SAM.gov.
Contracts: federal only, no data before fiscal year 2008.
Recompete search covers contracts with activity in the past year, because USAspending caps how deep results can be paged. A long-dormant contract may not appear, and an over-broad search says so rather than returning a confidently empty list.
SEC: XBRL coverage starts around 2009, and only covers concepts companies actually tagged. Smaller filers tag less.
It reports; it does not compute. No ratios, growth rates, or derived metrics — those would be our arithmetic rather than the filing, and you could not verify them against the source.
Not investment advice. It is a data-reformatting tool.

Also on Apify

The same logic runs as hosted tools, no install required:

Data sources and licence

Contracts: USAspending.gov, US Department of the Treasury, published under the DATA Act. Financials: SEC EDGAR, US Securities and Exchange Commission. Both public domain. Code: MIT.

Available Tools

4 tools

company_financial_historyA

One company's reported history of a financial metric.

Deduplicated to one record per period, taking the most recent filing -- this year's 10-K restates last year's figures, so raw SEC data repeats periods with different values.

Every record carries the form type, filing date, and a verify_url.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many periods to return, 1-200.
`metric`	No	revenue, net_income, assets, cash, operating_cash_flow, eps_diluted, and others. A raw XBRL tag also works.	revenue
`company`	Yes	Ticker like AAPL, or a CIK number.
`period_type`	No	annual gives one figure per fiscal year; quarterly gives three-month figures. Use this -- a 10-Q reports both the quarter AND the year-to-date with the same end date, so 'any' mixes 3-month and 9-month numbers.	annual

TDQS

A3.8/5.0

Behavior4/5

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

Without annotations, the description carries the transparency burden. It discloses two key behaviors: deduplication to the most recent filing per period, and the inclusion of form type, filing date, and verify_url in each record. This is solid but does not mention potential errors, rate limits, or data ordering.

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

Conciseness5/5

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

The description is succinct, with three short paragraphs that directly convey purpose, deduplication logic, and record contents. No redundant or vague phrasing.

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 there is no output schema, the description adequately explains what each record contains (form type, filing date, verify_url) and the deduplication rule. It lacks details on sorting, error handling, or metric value units, but the core context is covered.

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

Parameters3/5

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

All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The tool description adds no new parameter-specific meaning beyond what the schema already states; it only reinforces the single-company scope implicitly via 'One company'.

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's function: retrieving a single company's reported history of a financial metric. It is distinct from sibling tools (e.g., search_federal_contracts) by focusing on company financials, and the verb+resource structure is specific.

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

Usage Guidelines2/5

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

The description does not provide explicit guidance on when to use this tool over alternatives. It implies single-company scope but never states conditions like 'use when you need historical financial data' or contrasts with sibling tools.

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

find_expiring_contractsA

Find federal contracts expiring soon -- recompete opportunities.

When a federal contract's period of performance ends, the work usually has to be re-competed, and the incumbent is beatable. These are the highest-probability opportunities in government contracting, visible in public data months before any solicitation is published.

Each result includes days_until_expiry and the current incumbent.

Note: usaspending.gov itself cannot filter by end date. This walks the end-date-sorted results to find the window, so it takes a few seconds.

ParametersJSON Schema

Name	Required	Description
`limit`	No	How many contracts to return, 1-100.
`keyword`	No	Free-text search across descriptions and recipients.
`agencies`	No	Awarding agency names to restrict to.
`min_amount`	No	Only contracts at or above this dollar amount. Strongly recommended: it narrows the search and makes it faster.
`expiring_after_days`	No	Skip contracts ending sooner than this. A contract ending next week is too late to bid on; 120 is typical lead time.
`expiring_within_days`	No	Return contracts whose period of performance ends within this many days. 365 is a typical planning horizon.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that each result includes days_until_expiry and the incumbent, that usaspending.gov cannot filter by end date, and that the tool walks end-date-sorted results and takes a few seconds. It also signals a read-only operation through 'Find'.

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

Conciseness5/5

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

The description is about 90 words, front-loaded with the core purpose, then provides market context, result fields, and a performance note in separate short paragraphs. Every sentence adds useful context for selection and expectation-setting.

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?

The tool has 6 optional parameters and no output schema, but the description names the key result fields (days_until_expiry, current incumbent) and explains latency and data-source constraints. It is complete enough for a read-only search tool with richly documented params, though a full result-shape list would be even safer.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter already well-documented including defaults, ranges, and intent. The description reinforces the 'window' concept and output fields, but does not need to add parameter-level detail.

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 opens with 'Find federal contracts expiring soon' which clearly specifies the resource (expiring federal contracts) and action (find). The mention of 'recompete opportunities' distinguishes this from the general sibling search_federal_contracts by emphasizing the specific use case.

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 strong context: federal contracts whose performance period ends must usually be re-competed, and incumbents are beatable. This explains why an agent would choose this tool, though it does not explicitly name alternative tools or state when not to use it.

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

screen_public_companiesA

Rank every US public company by a financial metric.

Answers questions sec.gov structurally cannot: which companies had revenue over $100 billion last year, which hold the most cash, which reported the largest losses. EDGAR serves filings one company at a time; this compares all of them at once.

Every record carries a verify_url to the filing the figure came from.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many companies to return, 1-200.
`order`	No	desc or asc.	desc
`metric`	No	revenue, net_income, assets, liabilities, equity, cash, operating_income, gross_profit, eps_diluted, operating_cash_flow, capex, long_term_debt, inventory, goodwill, rd_expense, shares_outstanding, and more. A raw XBRL tag such as 'Revenues' also works.	revenue
`period`	No	Calendar year like CY2024, or a quarter like CY2024Q1. Balance-sheet metrics are adjusted automatically.	CY2024
`max_value`	No	Only companies at or below this figure.
`min_value`	No	Only companies at or above this figure. Negative values are legal -- losses are real figures.
`period_type`	No	Filter by reporting period length: any, quarterly, half_year, nine_month, annual, instant.	any

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: 'Every record carries a verify_url to the filing the figure came from.' It also establishes the scope (all US public companies) and implies read-only screening. It does not mention rate limits or error handling, but for a read-oriented tool these are not critical. The description adds meaningful context beyond what annotations would provide.

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

Conciseness5/5

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

The description is concise: the first sentence states the purpose, the second paragraph gives concrete use cases, and the third adds one valuable detail (verify_url). It is front-loaded and every sentence earns its place. No wasted words or repetition of schema information.

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 the tool's complexity (7 params, no output schema), the description is fairly complete. It explains the tool's purpose, gives examples, and hints at output structure ('Every record carries a verify_url'). It doesn't detail all return fields, but that might be implied by the metric and ranking. The description is adequate for an agent to understand when and what to expect.

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

Parameters3/5

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add extra parameter semantics beyond what's already in the schema. The examples like 'revenue over $100 billion' reiterate the metric and period parameters but do not add new meaning. Therefore, it does not exceed the baseline.

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's function: 'Rank every US public company by a financial metric.' This is a specific verb+resource. It also distinguishes from siblings by emphasizing cross-company comparisons ('this compares all of them at once') and contrasts with SEC.gov/EDGAR. This differentiates it from company_financial_history, which likely focuses on individual company data.

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 gives clear context on when to use it: 'Answers questions sec.gov structurally cannot: which companies had revenue over $100 billion last year...' It implies this is for cross-company screening. However, it does not explicitly mention when not to use it or name alternatives like company_financial_history for single-company history, so it stops short of explicit exclusion. This earns a 4, not a 5.

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

search_federal_contractsA

Search awarded US federal government contracts.

Returns contracts the government has already awarded, largest dollar value first. Use this to see who is winning federal work, what an agency spends, or a specific company's contract history.

For contracts coming up for re-bid, use find_expiring_contracts instead.

ParametersJSON Schema

Name	Required	Description
`limit`	No	How many awards to return, 1-100.
`keyword`	No	Free-text search across award descriptions and recipient names, e.g. 'cybersecurity'. Omit to search all.
`agencies`	No	Awarding agency names, e.g. ['Department of Defense'].
`end_date`	No	Latest award action date, YYYY-MM-DD.
`min_amount`	No	Only awards at or above this dollar amount.
`start_date`	No	Earliest award action date, YYYY-MM-DD. No earlier than 2007-10-01.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations supplied, the description carries the behavioral disclosure burden. It discloses that results are limited to already-awarded contracts and that they are sorted 'largest dollar value first,' which goes beyond the schema. It does not mention pagination, output fields, or rate limits, but for a search/read tool the key behavioral traits are adequately surfaced.

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

Conciseness5/5

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

The description is concise and front-loaded: the first sentence states the tool's purpose, the second adds result ordering and use cases, and the final sentence points to an alternative. Every sentence earns its place with no filler or 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?

The tool has six optional, well-documented parameters and no output schema, so the description needs to convey scope and return behavior. It covers scope, sort order, and common use cases, but it does not enumerate the contract fields returned. Still, for selection and invocation, the description is sufficiently complete.

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

Parameters3/5

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

The input schema already provides thorough descriptions for all six parameters (e.g., 'Free-text search across award descriptions and recipient names'), so the description does not need to repeat them. It adds minimal parameter-level value beyond schema, but the schema coverage is 100%, meeting the baseline.

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 'Search awarded US federal government contracts' and immediately distinguishes it from expiring-contract searches with 'Use this to see who is winning federal work.' It names specific use cases and references the sibling find_expiring_contracts, so an agent can tell this tool from alternatives.

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

Usage Guidelines5/5

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

Explicit guidance is given on when to use this tool: for seeing who is winning federal work, what an agency spends, or a company's contract history. It also gives an explicit exclusion: 'For contracts coming up for re-bid, use find_expiring_contracts instead.' This clearly orients selection among siblings.

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. Dates show when Glama detected each change.

4 tool updatesv1.0.0Aug 21, 2026
- First observedcompany_financial_history
- First observedfind_expiring_contracts
- First observedscreen_public_companies
- First observedsearch_federal_contracts

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: search_federal_contracts finds awarded contracts, find_expiring_contracts identifies expiring ones, screen_public_companies ranks companies by metrics, and company_financial_history retrieves a single company's historical financials. No overlapping functionality exists between the four tools.

Naming Consistency2/5

The naming pattern is inconsistent. The first three tools use a verb-noun structure (search_, find_, screen_), but the fourth uses a noun-noun structure (company_financial_history). Additionally, the verbs 'search', 'find', and 'screen' are near-synonyms, which could confuse users about their exact purposes. The pattern is not uniform across the set.

Tool Count4/5

With only 4 tools, the server is reasonably scoped for its niche of government contracts and public company financials. It is slightly on the low end but within the acceptable 3–15 range, and each tool serves a distinct query need without unnecessary bloat.

Completeness4/5

The tool surface covers the primary queries for the domain: searching awarded contracts, finding expiring ones, screening companies by financial metrics, and retrieving a company's financial history. There are minor gaps (e.g., no tool for detailed contract metadata or company fundamentals beyond history), but agents can accomplish core tasks without dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

TangoOAuth
dev.tango
MCP access to the U.S. federal procurement graph: contracts, opportunities, entities, and more.
Government Data Open Data
2
secedgar-mcp-server A
io.github.cyanheads
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
Finance Government Data Open Data
1629
Usaspending A
io.github.pipeworx-io
USAspending MCP — Federal spending data from USAspending.gov API
Government Data Open Data Search
382
PrimeRFP SCOUT — Govcon Intelligence MCP
com.primerfp.scout
Federal+SLED govcon MCP: SAM, USASpending, recompete, hearings, policy intel, search. Private AI.
Government Data Open Data
2

Related MCP Servers

SEC EDGAR MCP
Finance Government Data
stefanoamorelli
A
license
C
quality
B
maintenance
MCP server for accessing SEC EDGAR filings. Connects AI assistants to company filings, financial statements, and insider trading data with exact numeric precision.
Updated 16 days ago (2026-08-21 10:17 UTC)
21
355
AGPL 3.0
sec-edgar-mcp
Finance Government Data Open Data
guptaprakhariitr
A
license
Not graded
quality
D
maintenance
Hosted MCP server that gives AI agents real-time access to SEC EDGAR filings search, 10-K/8-K reading, XBRL financial facts, and insider-trade (Form 4) alerts.
Updated 3 months ago (2026-06-11 08:39 UTC)
25
1
MIT
filed-mcp-server
Government Data Open Data Search
mgrantley
F
license
A
quality
D
maintenance
An MCP server that gives AI agents access to US business entity data, enabling searches across 9 state registries, SEC EDGAR filings, federal contracts, and lobbying disclosures.
Updated 6 months ago (2026-03-20 02:50 UTC)
6
1
-
USAspending MCP Server
Government Data Open Data
haydentbs
A
license
A
quality
C
maintenance
Read-only MCP server for exploring US federal spending data via the USAspending.gov API, enabling natural language queries on awards, agencies, recipients, and spending trends.
Updated 3 months ago (2026-06-19 08:40 UTC)
12
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/groundtruthtools/us-gov-data-mcp'

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

us-gov-data-mcp

Why this exists

Four tools

find_expiring_contracts — recompetes

search_federal_contracts

screen_public_companies

company_financial_history

Everything is verifiable

Three traps this handles for you

Install

Honest limits

Also on Apify

Data sources and licence

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`find_expiring_contracts` — recompetes

`search_federal_contracts`

`screen_public_companies`

`company_financial_history`