New Hampshire Code

@pipeworx/new-hampshire-code

新罕布什尔州 RSA（《修订法典注释》）——新罕布什尔州州法——按引文查阅完整条文，并根据官方标题进行主题／关键词搜索。

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

工具

• nh_statute(citation) — 获取一条 RSA 条文的完整现行文本（例如 "630:1"，谋杀一级罪），以及官方标题、章／标题上下文和逐字摘录自该条文自身“Source.”行的修订历史（例如 "Source. 1971, 518:1. 1974, 34:1. ... 2019, 42:1, eff. May 30, 2019."），并将其单独列入 history。
• nh_search(query, limit?) — 在普通法院官方条文和章节标题中进行主题／关键词搜索，涵盖全部 64 个标题（例如 "landlord"、“concealed weapon permit”）。这不是全文搜索——新罕布什尔州并未提供全文搜索。

身份验证

无需密钥。

数据源

全部位于 https://gc.nh.gov/rsa/html/ 下——这是规范主机；旧地址 www.gencourt.state.nh.us 会将每个路径 301 重定向至此（已于 2026-10-07 实时验证）。

• nhtoc.htm — 根目录目录：列出每个标题（罗马数字 I–LXIV）及其官方名称。
• NHTOC/NHTOC-{ROMAN}.htm — 每个标题对应一个页面：列出其中的每个章节及其官方名称。
• NHTOC/NHTOC-{ROMAN}-{chapter}.htm — 每个章节对应一个页面：列出其中的每条条文，格式为 "Section: {chapter}:{section} {catchline}."。
• {ROMAN}/{chapter}/{chapter}-{section}.htm — 实时条文页面。nh_statute 会在每次请求时实时获取此页面，不会预先固化。

scripts/bake-index.mjs 会离线遍历前三层（根目录 + 每个标题 + 每个章节）一次，将内容写入 src/nh-index-data.ts——包含引文、官方标题以及章节／标题上下文，不包含法规文本本身。

功能——三项可用，一项不可用

新罕布什尔州官方发布内容支持：

• 按引文查找 — nh_statute。
• 主题／关键词搜索 — nh_search，仅搜索标题（见下文）。
• 修订／立法历史 — 可用。每个现行条文页面的 sourcenote 标签内都有一行“Source.”，列出制定或修订该条文的届期法律。nh_statute 会在 history 中逐字返回该行（包括“Source.”标签）。
• 历史版本（修订前的文本）——不可用。已实时检查：根目录目录和条文页面都没有链接到按年份存档，也没有“查看截至某日期版本”的日期选择器。gc.nh.gov 仅发布当前在线 RSA。“Source.”行说明条文何时以及由哪部届期法律修订，但不会返回修订前的文本。

来源与结构——修改解析器前请先阅读

8 月的州法调查（docs/state-law-probe.md）指出，新罕布什尔州需要“从章节推导罗马数字标题”，而且它猜测的每个索引 URL 都返回相同的通用 18.8 KB 网站页面。这两项观察在一定范围内都是正确的：NH 的章节编号不像爱达荷州的 chapter = floor(section / 100) 那样通过算术方式划分到标题中，因此无法根据单独的章节编号推导出标题。调查未发现的是，gc.nh.gov 的目录有三级，而不是一级；每一级都是小型、静态、无需密钥的 HTML 页面（见上文“数据源”）——因此，章节 → 标题罗马数字的映射，以及每条条文的官方标题，都需要通过遍历这三级内容一次来获取。这是 mcps/idaho-code 所做的两级烘焙（标题列表 → 章节列表）的三级版本；由于 NH 的章节编号完全无法提供捷径，因此多扩展了一层。 引文 → URL 是直接改写，不需要猜测。 在第一个冒号处拆分引文（"632-A:1" → 章节 "632-A"、条款 "1"），实时页面地址为 https://gc.nh.gov/rsa/html/{titleRoman}/{chapter}/{chapter}-{section}.htm （将 : 替换为 -）。已在普通章节（630）、带连字符字母的章节（632-A）和带连字符字母的条款（630:1-a）中验证可用。gc.nh.gov 的 IIS 服务器对该路径不区分大小写（630-1-A.htm 和 630-1-a.htm 均返回 200），因此该工具包无需对获取的内容进行大小写规范化，只需在匹配调用方输入的引文时规范化即可。

条款页面的标记简单且一致——每个页面都在一个无修饰的 codesect 标签中包含法规正文（各行之间用普通 br 分隔；跨多个标题的样本中均未发现嵌套标签），修订历史则位于 sourcenote 标签中。这两个标签是该网站自定义的，并非标准 HTML；也正因如此，它们才是可靠的锚点——周围没有需要剥除的 WordPress/CMS 界面元素。

gc.nh.gov 确实被 Cloudflare 出口流量拦截——情况与 Oklahoma 或 Utah 不同，已通过实时测试确认，且需要相同的中继修复。 笔记本电脑上的 curl 可以正常访问所有 URL 形式，但 Cloudflare Worker 的实时出口对 5 个不同的 URL（根目录目录页、标题目录页、章节目录页、真实条款页面、不存在的条款）全部返回 HTTP 520（“error code: 520”，16 字节，Cloudflare 自带的通用边缘错误正文）——2026-10-07，在生产账号上用临时的 wrangler dev --remote Worker 重复验证了两次：

                                                     laptop curl       wrangler dev --remote (CF edge, prod account), x2 runs
rsa/html/nhtoc.htm                 (root TOC)        200               520 / 16B "error code: 520"  (both runs)
rsa/html/NHTOC/NHTOC-LXII.htm       (title TOC)       200               520 / 16B "error code: 520"  (both runs)
rsa/html/NHTOC/NHTOC-LXII-630.htm   (chapter TOC)     200               520 / 16B "error code: 520"  (both runs)
rsa/html/LXII/630/630-1.htm         (real section)    200               520 / 16B "error code: 520"  (both runs)
rsa/html/LXII/630/630-999.htm       (bad section)     404               520 / 16B "error code: 520"  (both runs)

gc.nh.gov 自身的响应头（Server: Microsoft-IIS/10.0、X-Powered-By: ASP.NET，没有 cf-ray 或 Server: cloudflare）表明源站本身并未置于 Cloudflare 前端之后——这说明是 NH 州网络在连接层拒绝 Cloudflare 的 IP 段，而不是应用层质询（不同于 oscn.net 的 Turnstile 2xx），也不是 TLS 证书链缺失（不同于 le.utah.gov 的 526）。Cloudflare 边缘根本没有收到任何源站响应可供分类。因此，src/index.ts 中的每次获取都会在网关为此 slug 注入 _proxyUrl/_proxyToken 时，通过 Supabase 出口中继（supabase/functions/egress-proxy，已将 gc.nh.gov 加入其 ALLOWED_HOSTS）进行路由——机制与 mcps/oklahoma-code 和 mcps/utah-code 相同；由于这不是 TLS 问题，因此不需要 PINNED_CA 条目。没有中继时（本地开发、该工具包自身的笔记本冒烟测试），则直接获取。

与 OKLAHOMA 不同（该工具包首次促成了这条边缘探测规则），对于不存在的条款或章节路径，gc.nh.gov 会返回真实且明确的 404（IIS“找不到文件或目录”模板）；已确认其状态码和正文都与真实页面不同——未发现以 200 状态码返回页面装饰内容的陷阱；此处唯一的传输问题就是上述 Cloudflare 专属的 520，已通过中继修复。已废止的条款是另一种合法情况：其页面仍返回 200，但 codesect 标签为空，sourcenote 标签也为空，且页面自身的短标题（从目录页预先获取，例如 "631:5 Repealed by 1992, 257:22, II, eff. Jan. 1, 1993."）会以明文说明这一点。nh_statute 会在接受空正文前，检查预先获取的短标题是否以 Repealed|Redesignated|Transferred|Renumbered|Omitted 开头，从而将这种情况与真正的解析失败区分开来——除此以外的任何空正文都会被视为严重的解析失败，绝不会静默返回 found: false。

一个反复出现的数字实体： –，每个条款的短标题后都有一个装饰性连接号。它以 Windows-1252 代码点形式书写（150 = 连接号），却被当作 Unicode 代码点使用——若直接解码，实际上会变成控制字符（U+0096），浏览器也会默默应用相同的映射。该工具包的本地实体解码器会对此作特殊处理。 刷新路径： node scripts/bake-index.mjs > src/nh-index-data.ts 每当新罕布什尔州的 RSA 重新编纂时（每年会多次将会期法律纳入其中），都要运行此命令。此工具包的其他部分无需更改——nh_statute 和 nh_search 都会读取此文件当前导出的内容。

已知缺口

• nh_search 会匹配官方标题（章节和章名），而不是完整的法条正文——新罕布什尔州不提供全文搜索，本工具包也不会声称提供。工具描述和每条“无匹配”响应中都说明了这一点。

• 如果烘焙索引中存在某条引用，但 LIVE 网站返回 404（例如，自上次烘焙索引以来某条法条已重新编号或废止），则会返回明确标记的 reason: "index_live_mismatch"，而不会只返回没有解释的 found: false。

• 遇到非 404 传输故障，或无法解析的 200 响应（缺少 codesect 或 sourcenote 标签，或非废止类标题对应的正文为空）时，会抛出清晰的错误，指出上游状态码和 URL——绝不会悄然改成 found: false。契约测试见 src/index.test.ts。

• 在 Supabase 的 egress-proxy 函数使用此提交新增的 gc.nh.gov 条目更新 ALLOWED_HOSTS 并重新部署之前，此工具包无法通过实时网关访问——该函数只能通过 workflow_dispatch 部署（.github/workflows/deploy-edge-function.yml），推送代码时绝不会自动部署，和允许列表中的其他条目一样。在完成部署之前（或网关版本早于为此 slug 注入 _proxyUrl），nh_statute 每次调用都会抛出明确的上游错误，而不会悄然返回 found: false——请参阅上文的“来源和结构”部分以及 src/index.test.ts。

部署前证据

请参阅 smoke.json，了解经过冒烟测试的参数；原始负载和边缘探测结果见此工具包的 PR/关闭说明（按照针对任何新上游主机的既定规则，在生产账户上运行 wrangler dev --remote，访问此工具包使用的确切 gc.nh.gov URL）——表格见上文的“来源和结构”部分。

快速开始

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

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

此端点实际提供的内容

https://gateway.pipeworx.io/new-hampshire-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 都连接到同一个网关和相同的 1784+ 个数据源。唯一的区别是直接列出哪个工具包的工具；无论连接哪一个，ask_pipeworx 都能访问所有工具。

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

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

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

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

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

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

也可以直接运行，以确认它能够启动：

npx -y @pipeworx/mcp-new-hampshire-code

它通过 stdin/stdout 使用 MCP 通信，并响应 initialize/tools/list/tools/call，仅提供此软件包的工具——不包含上述网关连接额外提供的任何共享元工具。相同的源代码，相同的工具，不使用 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗英语提问，而不是直接调用工具——这既适用于上述软件包端点，也适用于完整网关：

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

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT