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

按任何已报告的财务指标对所有美国上市公司进行排名。

"哪些公司在 2023 年收入超过 2000 亿美元？"

{ "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。打开并对比。

当 AI 参与其中时这一点最为重要：当助手报告一个美元数字时，你应该能够对照来源进行核实，而不是信任整个链条。如果某个数值与官方记录不一致，那就是一个 bug——请提交 issue。

它为你处理的三个陷阱

原始 SEC 数据在三个方面具有误导性，每一种都是静默的——你得到的是一个看似合理的错误数字，而不是报错。

10-Q 报告了季度和截至同一天的年累计数据。 跨申报文件比较净利润会静默地混淆三个月的数据和九个月的数据。每条记录都带有 period_type，你可以据此过滤。
同一事实在不同申报文件中以不同数值重复出现。 今年的 10-K 会重述去年的数据。去重为每个期间一条记录，以最近的申报文件为准——这正是 SEC 自己对重述的处理方式。
公司会随时间更换 XBRL 标签。 Microsoft 在 2010 年之前申报的是 Revenues，之后换成了不同的标签。只取第一个返回数据的标签会得到过时且不完整的历史；本工具会合并所有标签的数据。

安装

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 对任何包含 URL 的 User-Agent 都会返回 403。Your Name your@email.com 可以；加上 github.com/... 就不行。

尚未发布到 PyPI，因此请从仓库安装。当它发布到 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.

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.

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.

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.

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

ActivityStale

ResponsivenessNo issues

Resources

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
https://tango.dev/mcp
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
581
https://b2b-contract-parser-api.onrender.com/mcp
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
https://secedgar.caseyjhand.com/mcp
Usaspending A
io.github.pipeworx-io
USAspending MCP — Federal spending data from USAspending.gov API
Government Data Open Data Search
512
https://gateway.pipeworx.io/usaspending/mcp

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 a month ago (2026-10-03 09:11 UTC)
21
661 PyPI
375
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 5 months ago (2026-06-11 08:39 UTC)
11 npm
1
MIT
filed-mcp-server
Government Data Open Data Search
mgrantley
A
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
MIT
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`