de en es ja ko ru zh

us-gov-data-mcp

Name: us-gov-data-mcp
Author: groundtruthtools

by groundtruthtools

Overview Schema Source Related Servers Discussions Admin

Python

Remote

us-gov-data-mcp

Ein MCP-Server für US-Regierungsdaten. Fragen Sie Ihren KI-Assistenten, welche Bundesverträge auslaufen oder welche börsennotierten Unternehmen im letzten Jahr den höchsten Umsatz hatten – und erhalten Sie Antworten, die Sie anhand der offiziellen Aufzeichnungen der Regierung überprüfen können.

Basiert auf der USAspending-API des US-Finanzministeriums und den EDGAR-XBRL-Daten der SEC. Kein Scraping, kein API-Schlüssel, kein Konto, keine personenbezogenen Daten.

Warum es das gibt

Beide Quellen veröffentlichen alles und lassen Sie fast nichts davon abfragen.

usaspending.gov kann nicht nach Vertragsablaufdatum suchen. Wenn jedoch der Leistungszeitraum eines Bundesvertrags endet, muss die Arbeit in der Regel neu ausgeschrieben werden – und diese Neuausschreibungen sind die wahrscheinlichsten Gelegenheiten im öffentlichen Auftragswesen, die Monate vor jeder Ausschreibung in öffentlichen Daten sichtbar sind.

sec.gov stellt Einreichungen jeweils für ein Unternehmen bereit. Es gibt keine Möglichkeit auf der Website zu fragen, welche börsennotierten Unternehmen einen Umsatz von über 100 Milliarden Dollar hatten oder welche am meisten Bargeld halten. Die frames-API der SEC kann das in einem einzigen Aufruf für alle ~5.800 Einreicher beantworten – vorausgesetzt, man kennt bereits das XBRL-Tag und das Periodenformat.

Dieser Server beantwortet die Fragen, die diese Websites nicht beantworten können.

Related MCP server: sec-edgar-mcp

Vier Tools

`find_expiring_contracts` — Neuausschreibungen

Bundesverträge, die zur Neuvergabe anstehen, mit dem bisherigen Auftragnehmer und den verbleibenden Tagen. expiring_after_days legt Ihre Vorlaufzeit für Angebote fest, denn ein Vertrag, der nächste Woche ausläuft, ist nutzlos zur Vorbereitung.

{
  "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`

Vergebene Verträge nach Behörde, Stichwort, Datum oder Betrag. Wer gewinnt Bundesaufträge, wofür eine Behörde ausgibt, die Historie eines Wettbewerbers.

`screen_public_companies`

Ordnen Sie jedes börsennotierte US-Unternehmen nach einer beliebigen gemeldeten Finanzkennzahl ein.

„Welche Unternehmen hatten 2023 einen Umsatz von über 200 Milliarden Dollar?"

{ "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`

Die gemeldete Historie einer Kennzahl für ein Unternehmen – Umsatz, Nettogewinn, Vermögenswerte, Cashflow – dedupliziert, mit Formulartyp und Einreichungsdatum für jeden Datensatz.

Alles ist überprüfbar

Jeder Datensatz enthält eine verify_url zur behördlichen Einreichung, aus der er stammt. Öffnen Sie sie und vergleichen Sie.

Das ist besonders wichtig, wenn eine KI im Spiel ist: Wenn ein Assistent eine Dollarzahl meldet, sollten Sie sie gegen die Quelle prüfen können, statt der Kette zu vertrauen. Wenn ein Wert jemals von der offiziellen Aufzeichnung abweicht, ist das ein Fehler – bitte eröffnen Sie ein Issue.

Drei Fallstricke, die dieses Tool für Sie behandelt

Rohe SEC-Daten führen auf drei spezifische Arten in die Irre, jede davon still – Sie erhalten eine plausibel aussehende falsche Zahl, keinen Fehler.

Ein 10-Q meldet das Quartal und den Jahresverlauf mit demselben Enddatum. Der Vergleich des Nettogewinns über Einreichungen hinweg vermischt stillschweigend eine Drei-Monats-Zahl mit einer Neun-Monats-Zahl. Jeder Datensatz enthält period_type, und Sie können danach filtern.
Dieselbe Tatsache taucht in verschiedenen Einreichungen mit unterschiedlichen Werten auf. Der diesjährige 10-K stellt die Zahlen des Vorjahres neu dar. Dedupliziert auf einen Datensatz pro Periode, wobei die neueste Einreichung gewinnt – die eigene Behandlung von Neudarstellungen durch die SEC.
Unternehmen wechseln im Laufe der Zeit ihre XBRL-Tags. Microsoft meldete Revenues bis 2010 und danach ein anderes Tag. Wenn man das erste Tag nimmt, das Daten liefert, erhält man eine veraltete, unvollständige Historie; dieses Tool führt über alle hinweg zusammen.

Installation

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

Claude Desktop – fügen Sie zu claude_desktop_config.json hinzu:

{
  "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" }
    }
  }
}

Funktioniert mit jedem MCP-Client: Claude Desktop, Claude Code, Cursor, VS Code.

SEC_USER_AGENT ist eine sinnvolle Einstellung. Die Fair-Access-Richtlinie der SEC verlangt einen User-Agent mit einer Kontaktadresse, und Anfragen ohne eine solche erhalten eine 403. Ein Standardwert ist enthalten, damit die Tools sofort funktionieren, aber sich zu identifizieren ist die höfliche Art und bewahrt Sie davor, unter einer gemeinsamen Identität zu laufen.

Eine Eigenheit, die wir auf die harte Tour gelernt haben: Setzen Sie keine URL in diese Zeichenkette. Die SEC gibt für jeden User-Agent mit einer URL eine 403 zurück. Ihr Name ihre@email.com funktioniert; das Hinzufügen von github.com/... nicht.

Noch nicht auf PyPI, daher Installation aus dem Repository. Wenn es dort ankommt, wird daraus ein einfaches uvx us-gov-data-mcp.

Ehrliche Grenzen

Verträge: vergeben, nicht offene Ausschreibungen. Für veröffentlichte Angebote nutzen Sie SAM.gov.
Verträge: nur Bundesebene, keine Daten vor dem Haushaltsjahr 2008.
Die Neuausschreibungssuche umfasst Verträge mit Aktivität im letzten Jahr, weil USAspending begrenzt, wie tief Ergebnisse durchsucht werden können. Ein seit langem ruhender Vertrag erscheint möglicherweise nicht, und eine zu breite Suche sagt das, statt eine selbstbewusst leere Liste zurückzugeben.
SEC: Die XBRL-Abdeckung beginnt etwa 2009 und umfasst nur Konzepte, die Unternehmen tatsächlich getaggt haben. Kleinere Einreicher taggen weniger.
Es berichtet; es rechnet nicht. Keine Kennzahlen, Wachstumsraten oder abgeleitete Metriken – das wäre unsere Arithmetik statt der Einreichung, und Sie könnten sie nicht gegen die Quelle überprüfen.
Keine Anlageberatung. Es ist ein Datenaufbereitungswerkzeug.

Auch auf Apify

Dieselbe Logik läuft als gehostete Tools, keine Installation erforderlich:

Datenquellen und Lizenz

Verträge: USAspending.gov, US-Finanzministerium, veröffentlicht unter dem DATA Act. Finanzdaten: SEC EDGAR, US-Börsenaufsicht (SEC). Beide gemeinfrei. 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.

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

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

A3.9/5.0

Scored 2026-08-21 00:31 across 4 tools

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

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

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
SignalTender B2B, GovCon & LegalTech MCP Server A
io.github.aarbchen
B2B, GovCon & LegalTech MCP server for live RFPs, contract parsing, compliance & proposal tools.
Legal & Compliance Government Data
171
secedgar-mcp-server A
io.github.cyanheads
Query SEC EDGAR filings, XBRL financials, and company data via MCP. STDIO or Streamable HTTP.
Finance Government Data Open Data
16211
Usaspending A
io.github.pipeworx-io
USAspending MCP — Federal spending data from USAspending.gov API
Government Data Open Data Search
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 18 days ago (2026-10-03 09:11 UTC)
21
1,051 PyPI
373
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 4 months ago (2026-06-11 08:39 UTC)
6 npm
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 7 months ago (2026-03-20 02:50 UTC)
6
1
-
USAspending MCP Server
Government Data Open Data
haydentbs
A
license
A
quality
D
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 4 months ago (2026-06-19 08:40 UTC)
12
MIT

us-gov-data-mcp

Warum es das gibt

Vier Tools

find_expiring_contracts — Neuausschreibungen

search_federal_contracts

screen_public_companies

company_financial_history

Alles ist überprüfbar

Drei Fallstricke, die dieses Tool für Sie behandelt

Installation

Ehrliche Grenzen

Auch auf Apify

Datenquellen und Lizenz

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`find_expiring_contracts` — Neuausschreibungen

`search_federal_contracts`

`screen_public_companies`

`company_financial_history`