Utah Code

@pipeworx/utah-code

Utah Code — 引用によるユタ州法令の検索、施行日と改正履歴を含む全文、および Code 全体を対象としたトピック／キーワード検索。

Pipeworx の一部です。AI エージェントを 1764+ の稼働中のデータソースに接続する MCP ゲートウェイです。これは独立した非公式の連携であり、上流プロバイダーとの提携、承認、公開はありません。

ツール

• ut_code_section(section) — 引用による Utah Code セクションの全文 （例：「76-5-203」、「53-5a-102.2」）。施行日と改正履歴 （例：「Amended by Chapter 356, 2026 General Session」）も含みます。置き換えられた／過去の全文は返しません。le.utah.gov 独自の法令ビューアーでは、各セクションにつき「Current Version」が 1 つだけ表示されます。以前の改正について残るのは改正の引用のみで、以前の本文は残りません。
• ut_code_search(query, limit?) — Utah Code の全セクションを対象にした全文キーワード／トピック検索。該当する各項目について、引用、タイトル、URL を返します。

認証

不要です。

データソース

• https://le.utah.gov/xcode/TitleNN/ChapterMM/NN-MM-Sxxx.html（例： Title76/Chapter5/76-5-S203.html） — 公開セクションビューアーページです。法令本文はクライアント側の JS で挿入されるテンプレートのため、単純なフェッチでは外枠しか返りません。ただし、ページのインラインスクリプトブロックには常に var versionDefault="C76-5-S203_2026050620260506"; の形式の行があり、現在のバージョンのコンテンツドキュメントを指定しています。ボット対策の壁はありません。デフォルトの UA で取得してもブラウザーと同じく 200 が返りますが、このパックでは誠実な UA を送信しています。
• versionDefault で指定されたコンテンツドキュメント。同じディレクトリにあり、.html を付けたものです（例：C76-5-S203_2026050620260506.html）。実際の法令本文です。プレーンな未レンダリング HTML で、パンくずリスト、「Effective MM/DD/YYYY」の行、サブセクションの文字（「(1)」、「(a)」、「(i)」）がセル内のリテラルテキストとして記された、入れ子の HTML テーブル行による法令本文、末尾の「Amended by Chapter N, YYYY General Session」という履歴注記が含まれます。同じドキュメントは PDF／RTF／XML 形式でも公開されています（ベース名は同じで拡張子が異なります）。XML のマークアップはより簡潔ですが、サブセクションの文字はリテラルテキストとして含まれません（代わりに number 属性にのみ存在します）。そのため、このパックでは XML ではなくプレーン HTML の断片を読み取ります。
• https://le.utah.gov/servlet/solrproxy9 — le.utah.gov の Code 向け「Keyword Search」ナビゲーションリンク（/solrsearch.jsp?ktype=Code）を支える、認証不要の Solr プロキシです。JS でレンダリングされた検索結果ページを経由せず、直接呼び出します。fq=category:Code で法令本文に対象を絞ります。このフィルターがないと、法案、委員会文書なども検索されます。サイト上のどこにも説明されていない既知の仕様上の問題：このプロキシはクエリパラメーターをデコードしてから、再エンコードせずに内部 Solr サーバー（LESOLR:8080）へ転送します。そのため、q 内のリテラルなスペースが上流への HTTP リクエスト行にそのまま入り、Solr は 400 を返します。複数語のクエリでは、通常の %20／+ ではなく、スペースを %2520 と二重エンコードする必要があります（サーバー側で一度デコードされ、なお有効な文字列 %20 になります）。単語 1 つのクエリならどちらでも動作します。このゲートでは身元を偽装する必要はありませんでした。誠実な UA と GET だけで十分です。

ビューアーページの仕様上の問題と Solr の二重エンコードの仕様上の問題は、コードを書く前に curl で実際に調査して判明しました。8 月の州法調査では、ビューアーページだけを根拠に Utah を「クライアント側でレンダリングされるか、ボット対策の壁がある」と分類していました。

到達性 — このパックはエグレスリレー経由でアクセスします

le.utah.gov がリーフ証明書のみの TLS チェーンを提供しており、Sectigo の「Public Server Authentication CA OV R36」中間証明書が欠落しています。また、稼働中の Cloudflare Worker は **HTTP 526「Invalid SSL certificate」**を返します。2026-10-07 は3/3、2026-10-06 は5/5でした。Worker の fetch() には、欠落した中間証明書を指定する API がありません。そのため、すべてのリクエストは supabase/functions/egress-proxy 経由でルーティングされます。このプロキシの PINNED_CA マップが、le.utah.gov のリーフ証明書に記載された AIA URI から取得した正規の中間証明書でチェーンを補完します。 証明書の検証を無効にすることはありません。チェーンを補完するのであり、検証を省略するのではありません。

ゲートウェイは、このスラッグに対して _proxyUrl／_proxyToken を注入します （workers/gateway/src/index.ts）。この注入がなければ、このパックは遅くなったり一部だけ利用できたりするのではなく、 完全に利用不能になるため、このスラッグはリストに残しておく必要があります。

mcps/who-euro は直接動作し、こちらは動作しない理由

どちらのホストもリーフ証明書のみで、同じ Root R46 配下の兄弟関係にある Sectigo R36 中間証明書を使用しています。 つまり、チェーンの形状が Cloudflare の拒否理由ではありません。2026-10-07 に、 1つの Worker で1回実行して測定した結果は次のとおりです。

ホスト	結果	中間証明書
le.utah.gov	526 ×3	Sectigo CA OV R36
dw.euro.who.int	404 ×3 — TLS は完了しているため、アプリケーション層からの応答	Sectigo CA DV R36
example.com	200 ×3	対照

Cloudflare は、一部の欠落した中間証明書を独自のキャッシュから補完しますが、そうしない場合もあります。DV R36 は OV R36 よりもはるかに広く導入されており、それが有力な理由ですが、仕組みは CF 内部のもので検証できません。ホストごとに実測し、決して予測しないでください。

同じ形状を持つ次のパックを1分で診断する方法

openssl s_client -connect <host>:443 -servername <host> -showcerts \
  2>/dev/null | grep -c 'BEGIN CERT'      # 1 => leaf-only chain

ローカルの Node または Deno で失敗しても、Cloudflare については何も証明できません。 Deno の rustls は AIA をたどらず、中間証明書をキャッシュしないため、 dw.euro.who.int を含め、リーフ証明書のみのすべてのホストを拒否します。一方、CF は dw.euro.who.int に正常に応答します。重要な問いに答えられるのは、稼働中の wrangler dev --remote プローブだけです。526 が返る場合は、リレーに PINNED_CA エントリー（ホスト1つ、正規の中間証明書1つ）を追加します。コーパスを取り込んで保存し直す必要はありません。

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf など）に追加します。

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

このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/utah-code/mcp の tools/list は、上の表に記載されたツールに加えて、共有 Pipeworx メタツール（ask_pipeworx、 discover_tools、search_within、remember／recall など、ゲートウェイ全体で利用できるツール一式）も返します。そのため、表示されるツール数はこの表より多くなります。現在、単一パックのエンドポイントには、そのパック独自のツールとともに、共有ツールがおよそ30個表示されます。initialize の応答には正確なスコープが記載されており、その日の時点での確定情報となります。

これは意図的な設計であり、誤って多重化しているわけではありません。メタツールを使えば、ask_pipeworx でカタログ全体を対象にルーティングできるため、このパックの対象外の質問にも、2つ目の MCP サーバーを追加せずに回答できます。現時点では、メタツールなしでパックのエンドポイントをマウントする方法はありません。追加スキーマのコンテキストコストがルーティングのメリットを上回る場合は、複数のパックエンドポイントではなく、フルゲートウェイに一度接続してください。

または、Pipeworx のフルゲートウェイに接続すると、このパックだけではなく、すべてのパックのツールを直接一覧表示できます。

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

どちらの URL も、同じゲートウェイと同じ1,764以上のデータソースにアクセスします。唯一の違いは、どのパックのツールが直接一覧表示されるかです。ask_pipeworx を使えば、どちらからでもすべてのパックにアクセスできます。

MCP クライアントがない場合は、HTTP 経由で呼び出す

curl -X POST https://gateway.pipeworx.io/v1/tools/ut_code_section \
  -H 'Content-Type: application/json' \
  -d '{"section":"76-5-203"}'

最初の呼び出しにアカウントは不要です。任意のツールを確認するには、GET https://gateway.pipeworx.io/v1/tools/ut_code_section を呼び出します。ツールを探すには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を呼び出します。

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

このパッケージは、ローカルの stdio MCP サーバーとしても実行できます。Pipeworx アカウントも、ゲートウェイ経由の往復通信も不要です。

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

または、直接実行して起動を確認できます。

npx -y @pipeworx/mcp-utah-code

stdin/stdout 経由で MCP を使用し、initialize／tools/list／tools/call に応答します。ただし対象はこのパックのツールのみで、上記のゲートウェイ接続で追加される共有メタツールは含まれません。同じソース、同じツールを使用し、ask_pipeworx によるルーティングはありません。

ask_pipeworx の使用

ツールを直接呼び出す代わりに、平易な英語で質問できます。これは、上記のパックエンドポイントでもフルゲートウェイでも機能します。

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

ゲートウェイが適切なツールを選択し、引数を自動的に入力します。

詳細

• ドキュメントとガイド
• pipeworx.io

ライセンス

MIT