Guam Code

@pipeworx/guam-code

关岛注释法典（GCA）——按引文以及主题／关键词搜索关岛领地法规。无需密钥。

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

工具

• gu_statute(citation, title?) — 按引文获取 GCA 条文全文 （“9 GCA 16.30”是加重谋杀罪的定义；“21 GCA 33101”规定谁可以为契据办理签字确认）。将引文解析到对应的单章 PDF，实时获取并提取文本。若 citation 中尚未包含 title，才需要提供 title。
• gu_search(query, title?, limit?) — 按主题／关键词搜索条文和章节标题（不搜索法规正文全文——见下文），也可以限定在一个 Title（1-22）内。

身份验证

无需密钥。

来源与结构

法律汇编官（关岛司法部门，col.guamcourts.gov）以约 800 个按章节拆分的 PDF 发布 GCA，这些 PDF 链接都位于一个静态 HTML 页面中：页面包含 22 个可折叠的 Title 面板，每个面板列出相应章节。该网站没有按 Title 列出的目录、没有搜索 API，也没有全站条文索引（经实时确认）——mcps/north-dakota-code 在 Century Code 上也遇到了相同问题。scripts/bake-index.mjs 会将该页面中的数据（title／chapter／catchline／PDF URL）一次性烘焙到索引中。

与 North Dakota 不同，GCA 索引页也没有列出每一条条文。但抽样检查的每份章节 PDF 开头都包含自己的目录，其中列出一系列 § <chapter>.<nn>. Catchline. 标题，因此 scripts/bake-sections.mjs 会再获取全部约 800 份章节 PDF，并从目录块中烘焙出条文级的标题索引（15,760 行）。 gu_search 会读取该索引；gu_statute 从不依赖它来返回文本——每次调用时，都会根据实时获取的 PDF 重新推导条文边界。

刷新流程

当法律汇编官对 GCA 的修订足以值得重新烘焙时，请重新运行这两个脚本（先运行章节索引脚本——条文索引脚本会读取该索引）：

node mcps/guam-code/scripts/bake-index.mjs > mcps/guam-code/src/gu-index-data.ts
node --experimental-strip-types mcps/guam-code/scripts/bake-sections.mjs > mcps/guam-code/src/gu-section-data.ts

条文索引脚本需要 --experimental-strip-types，因为它会直接导入该包自己的 TypeScript 提取器（此仓库不依赖 tsx/ts-node）——运行时无需该标志，只有这个离线脚本需要。

请预留几分钟：以适中的并发度发起约 800 次 HTTP 请求，这是出于对 col.guamcourts.gov 的体谅，并非因为该网站会限流。

两个烘焙模块由 src/gu-baked-data.ts（一个简单的重新导出文件）合并为此包对应的唯一数据模块 workers/gateway/src/pack-baked-indexes.json。网关会在部署时将导出内容上传到 KV，并注入为 args._bakedIndex，而不是在模块作用域中导入（参见 index.ts 的 ensureIndex；fleet #2754 就是因为曾有一次将烘焙表作为值导入到每个隔离环境中，导致网关宕机）。

两种引文格式，都确实存在

较新的重新编纂 Title（9 GCA，即《刑事与矫正法典》，改编自 1977 年《模范刑法典》）以带点号的“chapter.section”格式引用——“9 GCA § 16.30”表示加重谋杀罪。较早的 Title（例如 21 GCA 第 33 章《文书的证明与签字确认》）则将章节号与补零后的条文号连在一起，中间不加分隔符——“21 GCA § 33101”表示第 33 章第 101 条。gu_statute 接受这两种格式（参见 src/index.ts 中的 parseGuCitation）。对于不带点号的格式，仅凭数字字符串确实无法确定章节号与条文号的边界（章节号的位数不一）；系统会针对给定 Title，选取作为引文文字前缀的最长已知章节号来确定边界——在所有抽样案例中，这种方法均准确无误。

shared/src/pdf-text.ts 需要真正的修复 — 已合并，分支已删除（fleet #2904）

Guam 的法规章节 PDF 最初会以共享提取器尚无法处理的方式让它失效；而本数据包开发的同一周，另一个数据包（#2884，New Mexico）也在独立修改该共享文件。因此，修复最初放在 src/gu-pdf-extract.ts 中，这是 shared/src/pdf-text.ts 的数据包本地分支；文件头还加了醒目的注释，提醒下一位修改共享提取器的人将这些修复合并进去（这些问题都不是 Guam 特有的）。在 fleet #2904 中，这些修复已完成合并：分支已删除，本数据包现在直接调用 @pipeworx/shared 中的 extractPdfText，以下三项修复都已进入 shared/src/pdf-text.ts，让其他所有 PDF 数据包（kentucky-code、north-dakota-code、wyoming-code、new-mexico-code）也能受益，而不仅限于本数据包：

1. 字面字符串没有经过字体解码器处理。 Guam 的 PDF 生成程序（Neevia Document Converter，由 Word 转换而来）会将一些非 WinAnsi 子集字体的文本写成带括号的字面字符串（(abc)Tj），而不是十六进制字符串（<...>Tj）。共享提取器的 decodeRun 会原样传递字面字符串 — 对 WinAnsi 来说这是正确的，但对于这些字体，原始字节属于极小且任意的编码空间，只有通过字体自身的 /ToUnicode CMap 才有意义。共享代码已经具备相应机制（为 North Dakota 编写），但只接入了十六进制字符串路径。已在实际文件中确认：修复前，提取出的 § 16.10 是控制字符噪声；修复后则能正确读取。
2. 声明的 /Length 多出几个字节。 一些较旧的章节 PDF（生成程序为 “MS Word for Windows Document”，比上述 Neevia 转换的文件更早）声明的 /Length 比实际 deflate 流长 1 个或更多字节。Python 的 zlib 会静默容忍尾随字节；Node/Workers 严格的 DecompressionStream 则会抛出 ERR_TRAILING_JUNK_AFTER_STREAM_END。现在会在放弃前逐次修剪流尾部，每次一个字节，最多修剪 4 个字节后重试。
3. 生成章节索引时发现的、几乎导致崩溃的问题。 共享的 inflate() 辅助函数中，两次流写入都是异步触发后即不再等待（void writer.write(...)）；畸形 deflate 流（即上述第 2 项所述的同一批 PDF）会导致该 Promise 被拒绝，形成未处理的拒绝，对任何调用者的 try/catch 都不可见，并导致整个进程退出 — scripts/bake-sections.mjs 在运行中直接崩溃。修复方式是在每次写入和关闭操作上附加一个空操作的 .catch()；实际错误仍会通过 reader.read() 传出，而调用方本来就会处理该错误。

有一项改动仍留在数据包本地的 src/gu-font-cmap-fix.ts 中，因为它确实是 Guam 特有的问题： 每个章节 PDF 中都嵌入了一个符号字体（...+WPTypographicSymbols，仅用于弯引号），其 /ToUnicode CMap 将两个编码映射到 U+0041（'A'）和 U+0040（'@'），而不是它实际显示的左、右弯引号。肉眼核对确认：原始提取结果中的 “ADirector of Public Safety@”，将这两个编码替换回去后就是 ““Director of Public Safety”” — 这显然是原本想表达的内容，任何 PDF 查看器复制粘贴时也会得到同样结果。这是 Guam 发布的 PDF 本身存在的缺陷，不是通用提取器能够推断出来的问题，因此会通过新增的 fontCMapOverride 选项传入 extractPdfText — 这是一个通用钩子（匹配字体自身的字典文本，并可选择返回替换后的 /ToUnicode 映射），其机制本身与 Guam 无关，今后任何遇到类似问题的来源 PDF 的数据包都可以使用。

四项能力——两项可用，两项不可用

• 引用查询——可用（gu_statute）。
• 主题／关键词搜索——可用（gu_search），搜索范围为官方标题行（条款标题 + 章节名称），不包括完整的法规正文。覆盖情况尽力而为：标题行取自各章 PDF 自带的目录，而非单独的官方索引，因此格式特殊的章节可能覆盖不足。
• 修订／制定历史——嵌入在 gu_statute 的 text 字段中，作为法规自身的 “SOURCE:” 行（例如 “Enacted 1977 as 16.30; amended by P.L. 14-125...”），未拆分为单独字段——GCA 的标记方式不够明确，无法在抽样的两个 PDF 时期中可靠地解析。
• 历史版本（某条款在修订前的文本）——不可用。col.guamcourts.gov 仅提供当前文本；未找到按年份或届次划分的存档。

已知瑕疵：章节最后一条条款处的页眉页脚杂项噪声

gu_statute 会去除重复的页眉（“9 GCA CRIMES AND CORRECTIONS CH. 16 CRIMINAL HOMICIDE 1”）以及每页都有的 “COL” 印记，这些内容均根据章节文本中首次出现的位置自行提取。较早时期的 PDF（上文第 2 项中由 “MS Word for Windows Document” 生成的文件）有时会提取出没有词间空格的页眉（例如 “21GCAREAL PROPERTY”，而不是 “21 GCA REAL PROPERTY”），导致剥离正则表达式——其匹配条件要求 GCA 前有空格——无法识别。法规正文不受影响；只有在这些较早章节中，恰好位于页面末尾的条款可能带有下一页页眉／页脚的尾部片段。这只是外观问题，不影响准确性。

引用

将 citation 设为 "9 GCA 16.30"、"9 GCA § 16.30"、"21 GCA 33101"，或不带标题的条款号（"16.30" / "33101"），并单独传入 title。

数据来源

• https://col.guamcourts.gov/guam-code-annotated/guam-code-annotated——标题／章节索引（一个可折叠页面）。已一次性写入 src/gu-index-data.ts；不会在每次调用时获取。
• https://col.guamcourts.gov/sites/default/files/9gc016.pdf——某一章的完整法规文本（此处为 9 GCA 第 16 章《刑事杀人罪》——替换文件名即可获取其他章节）。gu_statute 每次调用时都会实时获取此文件，并从中提取目标条款。约 800 份章节 PDF 也会由 scripts/bake-sections.mjs 离线获取一次，用于构建标题行搜索索引。

两者都是纯静态、无需密钥的服务端渲染 HTML／PDF——无需登录、无需 JavaScript；开发期间未观察到速率限制。

快速开始

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

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

此端点实际提供的内容

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

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

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

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

这两个 URL 都连接到同一个网关和相同的 1879+ 个数据源。唯一的区别在于哪些工具包的工具会被直接列出；无论连接哪一个，ask_pipeworx 都能访问所有工具。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/gu_statute \
  -H 'Content-Type: application/json' \
  -d '{"citation":"9 GCA 16.30"}'

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

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

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

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

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

npx -y @pipeworx/mcp-guam-code

它通过 stdin/stdout 使用 MCP 协议，并针对仅此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接所添加的任何共享元工具。相同的源代码，相同的工具，但没有 ask_pipeworx 路由功能。

使用 ask_pipeworx

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

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

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT