New Hampshire Code

@pipeworx/new-hampshire-code

ニューハンプシャー州 RSA（注釈付き改正法典）— ニューハンプシャー州法規 — 引用による条文全文、および公式の見出しによるトピック／キーワード検索。

Pipeworx の一部です。Pipeworx は、AI エージェントを 1784 以上の稼働中のデータソースに接続する MCP ゲートウェイです。これは独立した非公式の統合であり、上流プロバイダーとは提携関係になく、同社の承認を受けておらず、同社から公開されたものでもありません。

ツール

• nh_statute(citation) — RSA の条項 1 件の現行全文（例： "630:1"、第一級殺人）。公式の見出し、章／タイトルの文脈、および条文自身の 「Source.」行からそのまま取得した改正履歴（例："Source. 1971, 518:1. 1974, 34:1. ... 2019, 42:1, eff. May 30, 2019."）を含み、history に分けて格納します。
• nh_search(query, limit?) — 64 タイトルすべてにわたる、General Court の公式な条文および章の見出しを対象としたトピック／キーワード検索です （例："landlord"、"concealed weapon permit"）。全文検索ではありません。 ニューハンプシャー州は全文検索を公開していません。

認証

不要です。

データソース

すべて https://gc.nh.gov/rsa/html/ 配下にあります。これが正式なホストであり、旧 www.gencourt.state.nh.us はすべてのパスをここへ 301 リダイレクトします （2026-10-07 に実際に確認済み）。

• nhtoc.htm — ルートの目次：すべての TITLE（ローマ数字 I～LXIV）とその公式名称。
• NHTOC/NHTOC-{ROMAN}.htm — タイトルごとのページ。各タイトルに含まれるすべての CHAPTER とその公式名称。
• NHTOC/NHTOC-{ROMAN}-{chapter}.htm — 章ごとのページ。その章に含まれるすべての SECTION を "Section: {chapter}:{section} {catchline}." の形式で掲載します。
• {ROMAN}/{chapter}/{chapter}-{section}.htm — 現行の条文ページ。 nh_statute はリクエストごとにこのページを取得します。事前に固定したデータは使用しません。

scripts/bake-index.mjs は最初の 3 種類（ルート、各タイトル、各章）を一度だけ オフラインで巡回し、src/nh-index-data.ts に格納します。格納するのは引用情報、 公式の見出し、章／タイトルの文脈であり、法令本文そのものは含みません。

対応機能 — 3 つ利用可能、1 つは利用不可

ニューハンプシャー州の公式公開情報が対応している機能は次のとおりです。

• 引用による検索 — nh_statute。
• トピック／キーワード検索 — nh_search。見出しのみを対象とします（下記参照）。
• 改正／制定履歴 — 利用可能です。現行の各条文ページには sourcenote タグ内に 「Source.」行があり、その条文を制定または改正した会期法が記載されています。 nh_statute は「Source.」ラベルを含め、これをそのまま history で返します。
• 過去のバージョン（改正前の条文）— 利用できません。実際に確認したところ、 ルートの目次にも各条文ページにも、年ごとのアーカイブや「指定日現在の内容を表示」 する日付選択機能へのリンクはありません。gc.nh.gov が公開しているのは 現行の RSA のみです。「Source.」行には条文がいつ、どの会期法によって改正されたかが 記載されていますが、改正前の条文は返されません。

情報源と構造 — パーサーに手を加える前にお読みください

8 月の州法調査（docs/state-law-probe.md）では、ニューハンプシャー州について 「章からローマ数字のタイトルを導出する必要がある」と指摘され、調査で推測した すべてのインデックス URL が同じ汎用的な 18.8 KB のサイトページを返しました。 どちらの観察も、確認できた範囲では正しいものでした。NH の章番号は、Idaho の chapter = floor(section / 100) のような算術規則でタイトルごとに 区分されていないため、章番号だけからタイトルを導き出す公式はありません。 調査で見つけられなかったのは、gc.nh.gov の目次が 1 階層ではなく3 階層 であり、各階層が小規模で静的な、認証不要の HTML ページだという点です（上記の 「データソース」を参照）。そのため、章からタイトルのローマ数字への対応付けと、 すべての条文の公式な見出しは、いずれも 3 階層すべてを一度巡回して取得します。 これは mcps/idaho-code が行う 2 階層のベイク（タイトル一覧 → 章一覧）を 3 階層にしたもので、NH の章番号からは何も推測できないため、階層を 1 つ追加しています。 引用 → 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 を返します）。そのため、このパックでは取得時に大文字と小文字を正規化する必要はなく、呼び出し元が入力した引用との照合時にのみ正規化します。

セクションページのマークアップはシンプルで一貫しています。 すべてのページで、法令本文はプレーンな br で行が区切られた単独の codesect タグ内にあり、改正履歴は sourcenote タグ内にあります（複数のタイトルにまたがるサンプルで、入れ子のタグは確認されていません）。どちらもこのサイト独自のもので、標準 HTML ではありません。そのため、周囲の WordPress/CMS の装飾を除去せずに使える、信頼性の高い目印になります。

gc.nh.gov は Cloudflare のエグレス通信をブロックします。 Oklahoma や Utah とは異なる形態ですが、実際に確認済みで、同じリレーによる修正が必要です。ノート PC からの curl ではどの URL 形式にも問題なくアクセスできますが、実際の Cloudflare Worker からのエグレスでは、異なる 5 つの URL（ルート TOC、タイトル TOC、章 TOC、実在するセクションページ、存在しないセクション）すべてで HTTP 520 が返されます（「error code: 520」、16 バイト、Cloudflare 独自の汎用エッジエラー本文）。本番アカウントで一時的な wrangler dev --remote Worker を使い、2026-10-07 に 2 回再現しました。

                                                     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 のすべての fetch は、ゲートウェイがこのスラッグに _proxyUrl／_proxyToken を注入する際に、Supabase のエグレスリレー（supabase/functions/egress-proxy、許可ホストの ALLOWED_HOSTS に gc.nh.gov を追加）を経由します。mcps/oklahoma-code と mcps/utah-code と同じ仕組みです。TLS の問題ではないため、PINNED_CA のエントリーは不要です。リレーがない場合（ローカル開発、このパック固有のノート PC でのスモークテスト）は、直接取得します。

OKLAHOMA とは異なり（このエッジプローブのルールが最初に必要になったパックです）、gc.nh.gov は、存在しないセクションまたは章のパスに対して、正直な個別の 404（IIS の「File or directory not found」テンプレート）を返します。実在するページとはステータスと本文の両方が異なることを確認済みです。200 を返しつつページの装飾を含むという落とし穴は確認されていません。ここでの唯一の通信上の問題は、上記の Cloudflare 固有の 520 であり、リレーによって修正されます。廃止されたセクションは別の正当なケースです。そのページは引き続き 200 を返しますが、codesect タグは空で、sourcenote タグも空です。また、固有のキャッチライン（TOC から取り込まれたもの。例："631:5 Repealed by 1992, 257:22, II, eff. Jan. 1, 1993."）にその旨が平文で記載されています。nh_statute は、本文が空でも受け入れる前に、取り込まれたキャッチラインに Repealed|Redesignated|Transferred|Renumbered|Omitted という接頭辞があるか確認することで、これを実際の解析失敗と区別します。それ以外の空本文は、found: false として黙って扱うのではなく、明確な解析失敗として扱います。

繰り返し現れる数値文字参照が 1 つあります。 – は、各セクションのキャッチラインの後に付く装飾用の en ダッシュです。Windows-1252 のコードポイント（150 = en ダッシュ）を Unicode のコードポイントとして使ったものです。素朴にデコードすると文字どおり制御文字（U+0096）になります。これはブラウザーが暗黙に行う再マッピングと同じです。このパックのローカルなエンティティデコーダーでは、これを特別扱いしています。 更新方法： node scripts/bake-index.mjs > src/nh-index-data.ts ニューハンプシャー州の RSA が再編纂されたときに実行してください（session laws は年に数回まとめて組み込まれます）。このパックで変更が必要なのはこれだけです。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 関数を、このコミットで ALLOWED_HOSTS に追加された gc.nh.gov エントリとともに再デプロイするまで、このパックはライブゲートウェイでは利用できません。この関数のデプロイは workflow_dispatch でのみ実行され（.github/workflows/deploy-edge-function.yml）、許可リスト内の他のすべてのエントリと同様、push では自動実行されません。デプロイされるまで（または、このスラッグへの _proxyUrl 注入より前のゲートウェイビルドが使われている場合）、nh_statute は呼び出しのたびに上流エラーを明示的にスローし、found: false を黙って返すことはありません。上記の「ソースと形式」セクションおよび src/index.test.ts を参照してください。

デプロイ前の証跡

スモークテストした引数については smoke.json を、未加工のペイロードとエッジプローブについてはパックの PR／クローズ時のメモを参照してください（このパックが使用する正確な gc.nh.gov URL に対して、本番アカウントで wrangler dev --remote を実行しています。新しい上流ホストには常に適用されるルールです）。表については上記の「ソースと形式」セクションを参照してください。

クイックスタート

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 サーバーを 2 つ目に追加する必要はありません。現時点では、メタツールなしでパックのエンドポイントをマウントする方法はありません。追加のスキーマがルーティングの利点よりもコンテキストを圧迫する場合は、複数のパックエンドポイントではなく、フルゲートウェイに一度接続してください。

または、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":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行します。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージは、ローカルの 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