@pipeworx/us-auctions

实时美国拍卖拍品，涵盖市场的两半——约 1,900 家商业拍卖行，以及所有可达的政府剩余物资、扣押资产和欠税产权来源——可按关键词、州或距某个 ZIP 的距离搜索，外加拍卖网站在拍品结束时删除的成交价。

属于 Pipeworx 的一部分——一个 MCP 网关，将 AI 代理连接到 1481+ 个实时数据源。

工具

• us_auctions_search(keyword?, state?, asset_type?, segment?, source?, auction_house?, near_zip?, radius_miles?, max_price?, closing_within_hours?, limit?) — 通用拍品搜索。传入 near_zip 后，结果会按距离排序，每行带上 distance_miles。

• us_auctions_closing_soon(...) — 同一个数据池按最快结拍排序，带 hours_remaining。回答“我现在还能对什么出价”。

• us_auction_events(state?, keyword?, auction_house?, closes_after?, closes_before?, min_lots?, limit?) — 搜索拍卖会本身，而不是拍品。“我附近下周有哪些拍卖会。”

• us_auction_houses(state?, keyword?, limit?) — 我们覆盖哪些拍卖行、每家有多少在售拍品，按拍品数量排名。把一个拍卖行名字回填到上面两个工具中。

• us_auctions_sold_comps(keyword?, asset_type?, state?, segment?, limit?) — 最低 / 中位 / 平均 / 最高成交价，以及近期实例。这是差异化亮点。

• us_auctions_coverage() — 按来源计数、进行中拍卖数量、保留的成交对照、各来源最后刷新时间。

Related MCP server: GovAuctions MCP server

认证

对调用方无需密钥。网关在每次调用时注入该数据包的数据凭证；数据包本身无状态，不持有任何机密。

与相邻数据包的关系

• gov-auctions — 同一个存储，过滤为 segment='government'。之所以单独保留，是因为它以那个更窄的契约发布到 npm 和 MCP Registry，而一个想要剩余皮卡的调用方绝不能开始收到遗产拍卖的古董。

• gsa-auctions — GSA 联邦剩余物资实时 API。没有数据库后端，因此它的拍品不在这个存储中，也不会出现在这里。

数据源

由 workers/auction-scraper 摄取（每个来源一个适配器，在 cron 触发之间通过游标续传）。各来源的具体陷阱请参见该 worker。

• hibid — 商业。GraphQL，无需认证。约 1,900 家美国拍卖行。

• govdeals、allsurplus — 州/地方及企业剩余物资。allsurplus 也涵盖 govliquidation.com 和 go-dove.com，它们是同一个目录，只是通过不同域名提供——不要为它们构建适配器。

• publicsurplus、bid4assets、irs、txauction — 政府这一半的其余部分。

否则下一个人还要踩坑才能重新发现的事情

• 聚合函数和 group= 在此项目上被禁用（PGRST123）。 没有 count()。精确计数来自 Prefer: count=exact 和 Content-Range 尾部；us_auction_houses 中的按拍卖行汇总是在数据包内对一次有界行拉取进行计算的，而不是由数据库完成。

• 必须用 final_price > 0，绝不能只是 not.is.null。 结拍清扫会从最后已知出价冻结 final_price；一个无人出价的商业拍品会冻结为零。把那些当作成交对照，会把每个中位数都拖向 $0，而响应看起来仍然完全正常。

• 事件日期是本地日历日期，不是时间点。 closes_on / starts_on 是日期，因为 HiBid 发布的拍卖时间不带时区。拍品级别的 closes_at 是真正的时间点（由倒计时推导而来），所以 closing_within_hours 以拍品为准，而 us_auction_events 以日期为准。不要通过解析本地字符串来“修复”这一点——那会悄悄把西海岸晚间的拍卖会移到第二天。

• 无过滤搜索是两个查询，而不是一个 or=。 在将 closes_at >= now() 与 closes_at IS NULL 进行 OR 的同时按 closes_at 排序，无法用索引来服务；在最简单的调用上，它扫描了整个活跃数据池，超出了 8 秒语句超时——在硬 500 和 静默空结果 之间交替。拆分后的查询会以相同顺序返回相同的行。

• 坐标是 ZIP 质心。 大多数来源只发布 ZIP，没有更精确的信息，因此拍品的位置就是其城镇的位置。distance_miles 是城镇级别的；响应中已经这么说明，也应当继续这么说明。

• 关键词搜索先全文，后子串。 search_tsv（一个加权存储列，迁移 092）会做词干化并覆盖到描述；trigram ILIKE 扫描只在全文检索没有结果时运行，因为拍卖标题里满是部分型号编号，tsquery 无法在单词内部匹配它们。

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "us-auctions": {
      "url": "https://gateway.pipeworx.io/us-auctions/mcp"
    }
  }
}

这个端点实际提供什么

位于 https://gateway.pipeworx.io/us-auctions/mcp 的 tools/list 会返回上表中的工具，外加共享的 Pipeworx 元工具——ask_pipeworx、discover_tools、search_within、remember/recall 以及网关层面其余的整套工具。因此你看到的工具数量会比此表更大：单数据包端点目前会列出大约 30 个共享工具，外加该数据包自身的工具。连接的 initialize 响应会声明其确切范围，也就是对某一天的权威答案。

这是有意为之，而不是碰巧的多路复用。正是这些元工具，让一个限定范围的连接能够回答该数据包未覆盖的问题——通过 ask_pipeworx，它会在整个目录中路由——而无需你添加第二个 MCP 服务器。目前没有任何办法在缺少它们的情况下挂载数据包端点；如果额外的 schema 消耗的上下文比路由带来的价值还多，那就连接一次完整网关，而不是连接多个数据包端点。

或者，连接完整的 Pipeworx 网关，直接列出每个数据包的工具，而不仅仅是这一个的：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 到达的是同一个网关和同样的 1481+ 个数据源。唯一区别是哪些数据包的工具会被直接列出；ask_pipeworx 从任意一端都能触达所有工具。

与 ask_pipeworx 配合使用

无需直接调用工具，你可以用纯英文提出问题——这在上面的数据包端点和完整网关上都可以：

ask_pipeworx({ question: "your question about Us Auctions data" })

网关会挑选正确的工具并自动填好参数。

更多

• 文档和指南

• pipeworx.io

许可证

MIT