Utah Code

@pipeworx/utah-code

Utah Code——按引文查询州法条文，提供全文、生效日期和修订历史，并支持在整个法典中按主题/关键词搜索。

它是 Pipeworx 的一部分——一个将 AI Agent 连接到 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 自带的法典查看器对每个条文只 会列出一个“当前版本”；先前修订只保留修订引文，不保留此前文本。
• 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（无 JS）：包含面包屑导航、“Effective MM/DD/YYYY”一行、 以嵌套 HTML 表格行呈现的法规正文，其中小节字母（“(1)”、“(a)”、“(i)”）以字面文本形式印在单元格中， 末尾还有“Amended by Chapter N, YYYY General Session”修订历史说明。同一 文档也以 PDF / RTF / XML 格式发布（基本文件名相同，扩展名不同）——XML 标记更简洁，但小节字母不再以字面文本形式出现（它们只存在于 number 属性中），因此这个工具包读取纯 HTML 片段而非 XML。
• https://le.utah.gov/servlet/solrproxy9——支撑 le.utah.gov 自带法典“关键词搜索”导航链接 （/solrsearch.jsp?ktype=Code）的免密钥 Solr 代理；直接调用该代理，而不是通过 JS 渲染的结果页面。fq=category:Code 用于限定搜索范围为法规文本； 不加此筛选条件则会搜索法案、委员会文件等内容。已知问题，网站上没有任何文档说明：该代理会解码自身的查询参数，并将其转发给内部 Solr 服务器 （LESOLR:8080），但不会重新编码，因此 q 中的字面空格会成为上游 HTTP 请求行中的字面空格，导致 Solr 返回 400。 多词查询需要将空格双重编码为 %2520（服务器端解码一次后仍是有效字符串 %20），而不能使用常规的 %20/+——单词查询两种方式都可用。网关不需要伪造身份：只需使用真实的 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 获取真实中间证书，以补全证书链。绝不会禁用证书验证——我们补全证书链，而不是跳过验证。

网关会为此 slug 注入 _proxyUrl/_proxyToken（workers/gateway/src/index.ts）。没有这项注入，工具包并非响应慢或返回不完整，而是会完全不可用，因此此 slug 必须保留在该列表中。

为什么 mcps/who-euro 可以直连，而此处不行

这两个主机的证书链都仅包含叶证书，并使用来自同一 Root R46 的同级 Sectigo R36 中间证书，因此链的形态并不是 Cloudflare 拒绝连接的原因。以下数据来自 一个 Worker 在 一次运行中的测量，日期为 2026-10-07：

主机	结果	中间证书
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 内部，无法检查——应将其视为按主机实测，绝不预测。

下一个具有此类证书链形态的工具包：一分钟诊断

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，也不会缓存中间证书，因此会拒绝所有仅包含叶证书的主机——包括 CF 可以正常提供服务的 dw.euro.who.int。只有通过实时的 wrangler dev --remote 探测，才能回答关键问题。如果返回 526，修复方法是在中继中添加 PINNED_CA 条目（一个主机，一个真实中间证书），而不是重新构建语料库并执行摄取和存储。

快速开始

将其添加到你的 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 跨整个目录路由——无需添加第二个 MCP 服务。目前无法挂载不含这些元工具的工具包端点；如果额外的架构定义占用的上下文超过路由功能带来的价值，请改为连接一次完整网关，而不是连接多个工具包端点。

也可以连接完整的 Pipeworx 网关，直接列出每个工具包的所有工具，而不只是此工具包的工具：

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

两个 URL 都会访问同一个网关和相同的 1764+ 个数据源。唯一的区别在于会直接列出哪个工具包的工具；无论连接哪个端点，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":"..."} 向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求。

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

此软件包也可以作为本地 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