Idaho Code

@pipeworx/idaho-code

爱达荷州法规（Idaho Code）——按引证查询现行法规文本、修订历史，并根据官方章节和条款标题进行主题／关键词搜索，数据实时来自 legislature.idaho.gov。

属于 Pipeworx——一个将 AI Agent 连接到 1881+ 个实时数据源的 MCP 网关。这是独立的非官方集成，与上游提供方没有关联，未经其认可，也非由其发布。

工具

• id_statute({citation}) — 按引证获取单个条款的全文（例如 "18-4001"，谋杀罪），包含官方标题、章节／标题上下文， 以及爱达荷州几乎为每个条款打印的修订“History:”行。
• id_search({query, limit?}) — 在约 20,400 个实时条款标题（及其所属章节的 标题）中进行主题／关键词搜索，例如 "landlord"、 "concealed weapon permit"。不搜索法规正文全文—— 爱达荷州未发布无需密钥的全文搜索 API（参见“数据来源”）。

身份验证

无需密钥。无需注册，也没有激活门槛。

数据来源

• https://legislature.idaho.gov/statutesrules/idstat/ — 爱达荷州法规 标题列表（74 个标题）。
• https://legislature.idaho.gov/statutesrules/idstat/Title{T}/ — 单个标题的章节 列表，包含各章节的官方标题。
• https://legislature.idaho.gov/statutesrules/idstat/Title{T}/T{T}CH{C}/ — 单个章节的条款列表，包含各条款的官方标题。
• https://legislature.idaho.gov/statutesrules/idstat/Title{T}/T{T}CH{C}/SECT{T}-{N}/ — 单个条款的全文。

以上四种页面都是由 WordPress 提供的纯 HTML，无需密钥，未观察到速率限制。

引证不会直接写出所属章节——但可以通过公式推算

爱达荷州以 title-number 格式引用条款（“18-4001”），不会写出章节数字。章节可以推算出来，因为爱达荷州自己的编号严格采用 chapter*100 + sectionWithinChapter 的区块规则——已通过实时数据验证 Title 18 的第 1、5、9、40、83 和 91 章，以及仅含一章的 Title 4 和 29 的第 1 章：第 1 章包含“18-100”至“18-1xx”，第 40 章包含“18-4000”至“18-4099”，第 83 章包含“18-8300”至“18-8399”。因此，chapter = floor(number / 100)。id_statute 使用该公式构建直接 URL，然后会进行验证，而非盲目依赖公式——详见 src/index.ts 文件头中的“THE VERIFICATION CHAIN”，以及其中记录的三步回退流程（在报告某条引证不存在之前，先确认计算出的章节自身列表页）。错误的章节猜测必须产生明显且可调查的错误，绝不能悄然返回 found: false。

如实返回 404——没有 Oklahoma／Texas 式伪装成 200 的情况

已从两种环境实时验证（笔记本上的 curl，以及部署到生产 Cloudflare 账户的临时 wrangler dev --remote Worker，日期为 2026-10-07）： 两种环境下，每种 URL 格式都返回相同的状态和字节长度。不存在的章节或条款会返回真正的 HTTP 404（确实是 WordPress 的 error404 模板，大小稳定为 72,512 字节）——不会返回带页面装饰但没有法规内容的 200 响应。这种陷阱曾导致早期 Oklahoma 程序包构建失败（oscn.net 对 Cloudflare Worker 和笔记本的响应不同，尽管通过了所有本地冒烟测试，仍在每次实时调用中返回 found:false）。爱达荷州的网站不会这样做，两种方式均已确认：

                                            curl (laptop)        wrangler dev --remote (CF edge, prod account)
Title18/T18CH40/SECT18-4001/ (real)        200 / 91,548B         200 / 91,548B
Title18/T18CH40/ (real chapter listing)    200 / 92,122B         200 / 92,122B
Title18/T18CH999/ (bad chapter)            404 / 72,512B         404 / 72,512B
Title18/T18CH40/SECT18-9999/ (gap number)  404 / 72,512B         404 / 72,512B

传输或解析失败（非 404 的 HTTP 错误，或找不到内嵌法规片段的 200 响应）会抛出明确错误，指出上游状态或解析失败——绝不会报告为 found: false。只有经过确认不存在的引证（通过该章节自身的实时列表验证，而不只是直接猜测的 URL 返回 404）才会返回 found: false。

嵌入的法规片段

每个章节页面都会在网站当前的 WordPress 主题中，嵌入一个由旧版 Arbortext 生成的 HTML 导出文件（其自身包含 <html><head><body>，使用 Arbortext Epic 6.1，年代约为 2010 年代中期）。法规文本位于该内部片段顶层的 <div> 块中：一行 TITLE N、标题名称、一行 CHAPTER C、章节名称，然后是法规正文（一个或多个 div——包含多个段落的章节会为每个小节使用一个 <div>），接着是一个 History: 标记 div，后面跟着一个包含括号内修订引文的 div。src/index.ts 中的 parseSectionFragment 会提取这些内容；scripts/bake-index.mjs 的文件头进一步说明了为什么要同时烘焙章节和条文标题这两个层级。

四项能力——三项可用，一项不可用

• 引文查询——id_statute。
• 主题／关键词搜索——id_search，搜索官方标题（不搜索完整法规正文）。
• 修订／颁布历史——嵌入在 id_statute 的 history 字段中，即爱达荷州自己的 “History:” 行（例如："[18-4001, added 1972, ch. 336, sec. 1, p. 928; am. 1977, ch. 154, sec. 1, p. 390; am. 2002, ch. 330, sec. 1, p. 935.]"），几乎每条现行法规都有这一行。
• 历史版本（修订前的文本）——不可用。legislature.idaho.gov 仅提供当前文本。其 Session Laws 档案（/statutesrules/sessionlaws/）包含从 2000 年代起每个立法会期的一份 PDF 卷册，但这些卷册按会期章节编号编排（例如，某一整年的 “Chapters 1 - 162”），与法规引文中的标题／章节编号无关，也没有按条文编制索引——要找回先前版本，只能在这些卷册中手动搜索 history 中提到的修订法案。id_statute 会在每条响应中说明这一点，而不会默默省略该字段。

烘焙索引的刷新

src/id-index-data.ts 由 scripts/bake-index.mjs 根据 74 个标题页面及其约 1,468 个章节列表页面生成（一次性捕获约 20,400 条法规）。立法会期的法规编纂工作完成后，请重新运行该脚本：

node scripts/bake-index.mjs > src/id-index-data.ts

保留的标题（部分烘焙）

如果烘焙时发布方无法提供某个完整标题的页面，烘焙脚本（KNOWN_UNAVAILABLE_TITLES）会保留该标题在上次烘焙中的条目，而不是删除仍然存在的标题。这些条目不会重新标注验证时间：ID_CARRIED_FORWARD 会按标题记录上次验证时间，并在负载中说明这一情况。id_search 会标记每条保留条目（carried_forward、index_captured_at），将 data_as_of 设为所返回条目中最早的验证日期（烘焙日期为 index_baked_at），并添加 carried_forward_note。对于此类标题中的条文，id_statute 会返回 reason: "publisher_unavailable" 和相同的说明，而不会声称该章节不存在。 目前保留的标题：Title 22（上次验证时间为 2026-10-07）。

快速开始

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

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

此端点实际提供的内容

https://gateway.pipeworx.io/idaho-code/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 共享元工具——ask_pipeworx、 discover_tools、search_within、remember/recall 和网关级工具集中的其他工具。因此，你看到的工具数量会多于表格中的数量：目前，单个工具包端点除了列出工具包自身的工具外，还会列出大约 30 个共享工具。连接的 initialize 响应会说明确切范围，是当天最权威的依据。

这是有意为之，并非意外的多路复用。元工具能让限定范围的连接回答本工具包未涵盖的问题——通过 ask_pipeworx 跨整个目录进行路由——无需你再添加第二个 MCP 服务。目前无法在不包含这些元工具的情况下挂载工具包端点；如果额外的架构定义占用的上下文超过了路由带来的价值，请连接一次完整网关，而不是连接多个工具包端点。

或者连接完整的 Pipeworx 网关，直接列出每个工具包的工具，而不只是此工具包的工具：

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

两个 URL 都连接到同一个网关和同一组 1881+ 个数据源。唯一的区别是直接列出哪个工具包的工具；通过任意一个端点，ask_pipeworx 都能访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/id_statute \
  -H 'Content-Type: application/json' \
  -d '{"citation":"18-4001"}'

首次调用无需账户。检查任意工具：GET https://gateway.pipeworx.io/v1/tools/id_statute。查找工具：使用 {"query":"..."} 向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求。

独立运行（无需网关账户）

此软件包也可以作为本地 stdio MCP 服务运行——无需 Pipeworx 账户，也无需经过网关：

{
  "mcpServers": {
    "idaho-code": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-idaho-code"]
    }
  }
}

也可以直接运行，确认服务能否启动：

npx -y @pipeworx/mcp-idaho-code

它通过 stdin/stdout 使用 MCP 协议，并仅针对此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接额外提供的任何共享元工具。相同的数据源、相同的工具，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗易懂的语言提问，而不是直接调用工具——此功能既适用于上面的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Idaho Code data" })

网关会自动选择合适的工具并填入参数。

更多信息

• 文档与指南
• pipeworx.io

许可证

MIT