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

MCP-сервер для данных правительства США. Спросите своего ИИ-ассистента, какие федеральные контракты истекают или у каких публичных компаний была самая большая выручка в прошлом году — и получите ответы, которые можно проверить по официальным записям правительства.

Построен на API USAspending Казначейства США и данных EDGAR XBRL SEC. Без скрейпинга, без API-ключа, без аккаунта, без персональных данных.

Зачем это существует

Оба этих источника публикуют всё, но почти ничего не позволяют запрашивать.

usaspending.gov не умеет искать по дате окончания контракта. Но когда срок исполнения федерального контракта истекает, работу обычно приходится выставлять на повторный конкурс — и эти повторные конкурсы являются возможностями с наибольшей вероятностью успеха в госзакупках, видными в открытых данных за месяцы до появления любого извещения.

sec.gov отдаёт отчётности по одной компании за раз. На сайте нет способа узнать, у каких публичных компаний выручка превысила 100 миллиардов долларов или у кого больше всего денежных средств. API frames SEC может ответить на это по всем ~5 800 эмитентам одним запросом, если вы уже знаете тег XBRL и формат периода.

Этот сервер отвечает на вопросы, на которые эти сайты ответить не могут.

Related MCP server: sec-edgar-mcp

Четыре инструмента

`find_expiring_contracts` — повторные конкурсы

Федеральные контракты, которые скоро будут выставлены на повторные торги, с указанием действующего подрядчика и оставшихся дней. expiring_after_days задаёт ваш запас времени на подготовку заявки, потому что контракт, истекающий на следующей неделе, бесполезен для подготовки.

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

Заключённые контракты по ведомству, ключевому слову, дате или сумме в долларах. Кто выигрывает федеральные заказы, на что тратит ведомство, история конкурента.

`screen_public_companies`

Ранжирует все публичные компании США по любому отчётному финансовому показателю.

«У каких компаний выручка превысила 200 миллиардов долларов в 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`

История одного показателя одной компании — выручка, чистая прибыль, активы, денежный поток — без дубликатов, с типом формы и датой подачи по каждой записи.

Всё проверяемо

Каждая запись содержит verify_url на государственный документ, из которого она взята. Откройте его и сравните.

Это особенно важно, когда в цикле участвует ИИ: когда ассистент сообщает сумму в долларах, вы должны иметь возможность сверить её с источником, а не доверять цепочке. Если значение когда-либо разойдётся с официальной записью — это ошибка, пожалуйста, откройте issue.

Три ловушки, которые этот сервер обрабатывает за вас

Сырые данные SEC вводят в заблуждение тремя конкретными способами, каждый из которых незаметен — вы получаете правдоподобное неверное число, а не ошибку.

Форма 10-Q отчитывается за квартал и за период с начала года с одной и той же датой окончания. Сравнение чистой прибыли по разным отчётностям незаметно смешивает трёхмесячный показатель с девятимесячным. Каждая запись содержит period_type, и вы можете фильтровать по нему.
Один и тот же факт повторяется в разных отчётностях с разными значениями. Годовой отчёт 10-K за этот год пересчитывает показатели прошлого года. Дедупликация до одной записи на период, приоритет у самой свежей отчётности — так же, как сам SEC обрабатывает пересмотры.
Компании со временем меняют теги XBRL. Microsoft подавала Revenues до 2010 года, а после — другой тег. Если взять первый тег, вернувший данные, получится устаревшая неполная история; здесь же выполняется объединение по всем тегам.

Установка

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

Claude Desktop — добавьте в 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" }
    }
  }
}

Работает с любым MCP-клиентом: Claude Desktop, Claude Code, Cursor, VS Code.

SEC_USER_AGENT задать стоит. Политика добросовестного доступа SEC требует User-Agent с контактным адресом, и запросы без него получают 403. Значение по умолчанию включено, чтобы инструменты работали из коробки, но идентифицировать себя — это вежливо и не даёт оказаться в общей группе.

Один нюанс, усвоенный на горьком опыте: не вставляйте URL в эту строку. SEC возвращает 403 на любой User-Agent, содержащий URL. Ваше Имя your@email.com работает; добавление github.com/... — нет.

На PyPI пока нет, поэтому устанавливайте из репозитория. Когда появится, это станет обычным uvx us-gov-data-mcp.

Честные ограничения

Контракты: заключённые, а не открытые извещения. За опубликованными торгами — на SAM.gov.
Контракты: только федеральные, нет данных до 2008 финансового года.
Поиск повторных конкурсов охватывает контракты с активностью за последний год, потому что USAspending ограничивает глубину прокрутки результатов. Давно неактивный контракт может не появиться, а слишком широкий поиск скажет об этом, а не вернёт уверенно пустой список.
SEC: покрытие XBRL начинается примерно с 2009 года и охватывает только те концепты, которые компании действительно тегировали. Мелкие эмитенты тегируют меньше.
Сервер сообщает, а не вычисляет. Никаких коэффициентов, темпов роста или производных показателей — это была бы наша арифметика, а не отчётность, и вы не смогли бы проверить её по источнику.
Не инвестиционная рекомендация. Это инструмент переформатирования данных.

Также на Apify

Та же логика работает как хостинговые инструменты, без установки:

Источники данных и лицензия

Контракты: USAspending.gov, Министерство финансов США, опубликовано в соответствии с DATA Act. Финансовые данные: SEC EDGAR, Комиссия по ценным бумагам и биржам США. Оба источника — общественное достояние. Код: 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
131
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
16210
Usaspending A
io.github.pipeworx-io
USAspending MCP — Federal spending data from USAspending.gov API
Government Data Open Data Search
472

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)
13 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

Зачем это существует

Четыре инструмента

find_expiring_contracts — повторные конкурсы

search_federal_contracts

screen_public_companies

company_financial_history

Всё проверяемо

Три ловушки, которые этот сервер обрабатывает за вас

Установка

Честные ограничения

Также на Apify

Источники данных и лицензия

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`find_expiring_contracts` — повторные конкурсы

`search_federal_contracts`

`screen_public_companies`

`company_financial_history`