mcpField
M
Mississippi Code

Mississippi Code

远程服务
pipeworx.io法律与政务01 天前更新

关于 Mississippi Code

Mississippi Code 查询服务面向需要按引文查阅州法规或按标题浏览章节的法律研究者。它基于截至 2020-07-08 的静态版本,并附列后续法案记录,不将其合并为法规正文。

主要功能

  1. 01按引文获取法规文本及沿革
  2. 02按标题浏览章节
  3. 03按官方条文标题搜索
  4. 04列出后续相关法案且不合并正文

适用场景

  1. 01核对某条法规的快照文本
  2. 02浏览标题下的章节目录
  3. 03查找特定主题的法规条文
  4. 04追踪快照之后涉及该引文的法案

MCP 相关

作为 MCP 服务,它向客户端提供按引文查询、章节浏览和标题搜索工具。

配置

远程服务无需本地安装。选择你使用的客户端,复制配置或使用一键安装。

服务地址https://gateway.pipeworx.io/mississippi-code/mcp
一键复制安装命令
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

命令在终端中运行;JSON 粘贴到对应客户端的 MCP 配置后重启。需要授权的服务会在首次连接时提示登录。

工具

详细介绍

@pipeworx/mississippi-code

《1972 年密西西比州法典》(注释版)——按引文查询条文、按标题浏览章节,以及根据官方条文标题搜索主题/关键词。 Fleet #2883。无需密钥。

属于 Pipeworx——连接 AI Agent 与 1882+ 个实时数据源的 MCP 网关。这是独立的非官方集成,与上游提供方无关,未获其认可,也非其发布。

工具

  • ms_code_section(citation) — 按引文查询条文文本 ("97-3-19"、"Miss. Code Ann. § 89-8-19"、"Section 97-3-19")。返回 条文标题、现行法规正文、HISTORY: 行,以及适用时的联合立法委员会 / 修正案 / 交叉引用注释,并且还会返回 later_acts 覆盖信息——根据此工具包自行抓取的 密西西比州已签署法案文本,自 2020-07-08 快照以来所有涉及该确切引文的法案 (fleet #2915,见下文“覆盖信息”)。特意排除判例法(JUDICIAL DECISIONS) 注释——每个条文可能包含数百条引用,而询问“这项法规怎么说”的调用方并不需要这些内容。
  • ms_code_chapters(title) — 标题下的所有章节标题和编号 (97 是刑事犯罪,89 是不动产和个人财产),适用于没有确切引文时浏览。
  • ms_code_search(query, limit?) — 根据每个条文的官方 CATCHLINE 搜索主题/关键词 (不搜索完整法规正文——见下文“为何不支持全文搜索”)。与 North Dakota 的 nd_search 类似:基于预先构建的索引进行 IDF 加权词语重叠搜索,不会实时调用上游服务。

身份验证

无需密钥。调用双方均无需注册或登录。

为何不支持全文搜索

官方 LexisNexis 托管的法典(lexisnexis.com/hottopics/mscode, 由国务卿官方网站链接)位于 Cloudflare 管理的质询机制之后——已实时确认: 每个直接请求都会收到“Just a moment...”拦截页,HTTP 403,且不含法规文本。 两个常见的免费第三方版本 law.justia.com 和 codes.findlaw.com 也位于 完全相同的 Cloudflare 质询机制之后(已实时确认,返回完全相同的 “Just a moment...”正文)——这并非 Lexis 独有的限制,而是 Cloudflare 机器人检测机制挡在三家不同供应商提供的同一文本副本之前,因此无法通过“换个镜像站的搜索界面试试”来解决。

数据源

  • https://unicourt.github.io/cic-code-ms/ — Mississippi Code 的 GitHub Pages 副本,由 UniCourt 代表 Public.Resource.Org 构建,来源于该法典官方发布的 RTF 卷册 (archive.org/download/gov.ms.code.ann.2018),根据该仓库自己的 README,该内容“属于公有领域,不保留任何权利”。每个 HTML 页面对应一个标题 (gov.ms.code.title.{NN}.html,标题编号补零至 2 位 — Mississippi 的标题编号为 1-99 的奇数),每次调用 ms_code_section / ms_code_chapters 时都会实时获取 — 此工具包通过代理访问,不会在仓库中附带该法典副本(Pipeworx CLAUDE.md 许可部分中的 mirror-needs-grant-proxy-does-not)。

    无论出版商的许可对其自身呈现方式如何规定,底层法条文本均属于公法 — 颁布的法律不受版权保护(Banks v. Manchester,128 U.S. 244(1888);Veeck v. SBCCI, 293 F.3d 791(5th Cir. 2002)(全院庭审))。

必须如实说明的局限。 此数据源是 Release 78,于 2020-07-08 发布, 由该法典 2018 年印刷版 RTF 卷册生成。它是静态快照,并非持续更新的数据流 — 2021 年至 2026 年常规议会会议期间颁布的修正案未反映在其中。每个响应都会附带 current_through 和 data_as_of: "2020-07-08",而不是默认显示 “现在”,以免把六年前的文本误表述为现行法律。对于 2020 年年中之后颁布的任何内容,请对照 LexisNexis 托管的官方法典核实,或联系立法汇编、修订与出版联合委员会(Miss. Code Ann. §§ 1-1-101 至 1-1-111)。

Title 79(公司、协会与合伙企业)无法按条款查询。 于 2026-10-09 对全部 50 个标题进行实时检查:其他所有标题的条款标题标签 (h3,id 属性格式为 t{title}c{chapter}s{citation})均带有该 id — 共 27,688 条 — 但 Title 79 的约 700 个条款标题都是没有 id 的裸 h3 标签(这些标签反而被重复用于 编辑注释等无关附注),其链接到的内部引文锚点(例如 href="#t79c01s79-1-1")也悬空 — 该标题的文档中没有任何元素带有这个 id。ms_code_section 会明确指出这一情况(reason: "title_markup_unsupported"),而不会返回无法区分的 citation_not_found。ms_code_chapters 仍可用于 Title 79(其章节目录完好);只有条款级文本提取受到阻止。

覆盖层:后续法案,绝不合并(fleet #2915)

Bruce 保留了基于冻结的 2020-07-08 快照的 ms_code_section(“我们得想办法解决”),没有追求完全协调的现行法典 — arkansas-code 的覆盖层(fleet #2906)也遵循了同样的决定。本覆盖层是在此决定之上最经济且诚实的改进 — 设计与测量见 docs/current-statute-routes.md(#2902)。

与 Arkansas 不同,Mississippi 的立法机构没有发布现成的“引文到法案”索引。 billstatus.ls.state.ms.us 提供法案状态页面和已签署的法案文本,而不是“已修订条款”查询 — 因此,此覆盖层是自行构建的:抓取每份已颁布法案的签署文本,并解析 Mississippi 每份修正案都使用的套话:“SECTION N. Section <cite>, Mississippi Code of 1972, is amended as follows:”(也包括“is created”/“shall be codified as Section <cite>, Mississippi Code of 1972”/“is repealed”/“is brought forward as follows”/“is reenacted as follows” — 作为日落条款续期的一种动词形式,归入“amended”类别,因为它以相同方式涉及该引文)。

规则:绝不改写快照 text。只在旁边添加带日期和链接的列表,并明确标注其未合并。 ms_code_section 的响应包含:

  • later_acts — 自快照日期以来影响这一准确引文的每项法案各有一条记录:chapter(Session Laws 章节编号,取自法案自身的历史记录;尚未分配时为 null)、session(人类可读的名称,例如 “2025 Regular Session”)、verb(amended/created/repealed/brought_forward)、range_to(仅当法案影响的是 Sections X through Y 范围而非单条引文时非空;见下文“范围”)、link(法案自身的签署文本页面)、bill(法案编号)、source: "billstatus" 和 merged: false。空值([])表示覆盖层在检查过的所有届期中均未发现影响该引文的后续法案——并不表示覆盖层加载失败(KV 索引缺失或格式错误时会直接抛出错误,与 ms_code_search 的 catchline 索引相同)。
  • sessions_checked — 覆盖层涉及的所有届期,即使 later_acts 为空也会列出,以便调用方区分“没有变更”和“未检查”。
  • later_acts_data_as_of — 覆盖层最后一次生成的时间。

范围。 对于类似 “Sections 75-15-1 through 75-15-35, Mississippi Code of 1972, ... is hereby repealed” 的条款,会保留为一行并同时记录两个端点,而不是由本工具包生成中间的每条引文(其中一些可能并不存在——密西西比州的条文编号并非总是连续的;已实时确认:一项 2025 年法案只重新颁布了某章中编号为奇数的条文)。ms_code_section 会根据末尾部分的数字包含关系来判断查询的引文是否匹配某个范围,并要求标题-章节前缀相同;脚本不会猜测该范围实际包含哪些编号。

有意不建立索引的内容(根据 100 项法案实时样本测得,见下文“覆盖率测量”):修改未编纂 SESSION LAW 的条款(“Section 7, Chapter 467, Laws of 2019, ... is amended”)从不提及 “the Mississippi Code of 1972”,因此会被正确排除——它从未影响任何法典引文。新设但尚未分配最终引文的条款(“Section N of this act shall be codified in Chapter X, Title Y, Mississippi Code of 1972”)也会被排除——在编纂者分配编号之前,没有可用于建立索引行的键,而本数据源不会进行编号分配。

在 Release-78 快照中未找到、但存在于覆盖层中的条文会被特别标记:如果本工具包自身的抓取结果显示,有法案涉及 2020 年快照中不存在的引文,那么 ms_code_section 返回的 found: false 结果会附带 later_acts_if_created——这意味着该条文可能是在快照日期之后创建的,不一定是引文错误。

覆盖率测量(2026-10-10;从 2021-2025 Regular Sessions 中均匀抽取的 100 项真实已颁布法案): 有 208 条以 “Mississippi Code of 1972” 开头附近文字的 “SECTION N.” 条款;其中 207 条成功解析出动词(99.5%)。唯一未解析的条款(“...Section 25-11-415, Mississippi Code of 1972, which provides that...”)是拨款法案中的描述性交叉引用,并非修订条款——因为它未使用五个已识别动词中的任何一个,所以确实无法解析。scripts/bake-later-acts.mjs 会将其报告到 stderr(--report-unparsed 也会将其作为 // UNPARSED_REPORT: 注释写入生成的文件),而不会悄然丢弃。下方 MS_LATER_ACTS 中实际烘焙的数据量,取自完整生产运行(自 2021 年以来发现的每一届期),而非仅取自 100 项法案样本。

来源:billstatus.ls.state.ms.us——无需密钥,无反爬虫墙;已于 2026-10-10 实时确认(HTTP 200,纯 HTML/XML,无需 JavaScript 渲染)。烘焙期间,我们会按请求代理立法机关自己的公开法案状态网站,而不是再分发受版权保护的呈现内容——法律文本本身不受版权保护(上文引用的 Banks v. Manchester;Veeck v. SBCCI),而法案文本是立法机关自己的公开记录。 接下来是 Tennessee:复用,不要重新推导。 可直接沿用本次构建的内容(Arkansas 交给本次构建的结构相同):响应结构(later_acts/sessions_checked/later_acts_merged_into_text: false/“绝不重写文本”规则)、烘焙索引 + KV 注入模式(将新导出内容追加到 catchline 索引已使用的同一个 src/<xx>-index-data.ts 文件中)、优先发现会话而非硬编码的技巧(读取实时会话列表,而不是固定列表),以及用于刷新工作流的 scripts/bake-later-acts.mjs -> scripts/<xx>-later-acts-refresh.yml 结构。 和 Mississippi 一样,Tennessee 也没有官方引文索引(参见 docs/current-statute-routes.md)——其法案文本是 PDF(capitol.tn.gov),而非 HTML,因此其模板解析器需要使用 pdftotext,而不是本工具包的 HTML 剥离方式;但模板本身的正则结构相同,都是“SECTION N. Tennessee Code Annotated, Section X, is amended...”模式。

刷新烘焙索引

src/ms-index-data.ts 包含两个分别烘焙的表,两者都通过 workers/gateway/src/pack-baked-indexes.json 从 KV 注入,作为一个合并的 _bakedIndex 对象,而不是打包进去(fleet #2754:通过值导入的多 MB 表会加载到每个 gateway 隔离环境中,无论其是否会提供此工具包的服务):

  • MS_SECTIONS — ms_code_search 的 catchline 索引,在支持该索引标记的 49 个标题中有 27,688 行(见上文“Title 79”)。使用 node scripts/bake-index.mjs > src/ms-index-data.ts 重建(会覆盖文件——见下文)。仅当 unicourt.github.io/cic-code-ms 发布了高于 78 的版本时才重新运行。
  • MS_LATER_ACTS/MS_LATER_ACTS_SESSIONS_CHECKED — ms_code_section 的覆盖索引(fleet #2915),通过抓取并解析 billstatus.ls.state.ms.us 自己签署的法案文本构建(不存在官方索引)。使用 node scripts/bake-later-acts.mjs >> src/ms-index-data.ts 重建(追加)。每次 Mississippi 立法会期休会且法案签署后都要重新运行——定时版本见 .github/workflows/mississippi-later-acts-refresh.yml。会话自动发现(读取 billstatus.ls.state.ms.us/sessions.htm 上的实时会话列表),因此新会话出现时无需更改代码。

完整重新生成(两个表):

node scripts/bake-index.mjs > src/ms-index-data.ts
node scripts/bake-later-acts.mjs >> src/ms-index-data.ts

任一操作后都要运行 node ../../scripts/check-baked-indexes.mjs(在仓库根目录执行)——它会像 KV 上传器一样动态导入重新生成的文件,并在空导出数组进入部署流程前拒绝它。

快速开始

添加到你的 MCP 客户端(Claude Desktop、Cursor、Windsurf 等):

{
  "mcpServers": {
    "mississippi-code": {
      "url": "https://gateway.pipeworx.io/mississippi-code/mcp"
    }
  }
}
此端点实际提供的内容

https://gateway.pipeworx.io/mississippi-code/mcp 上的 tools/list 会返回上表中的工具,以及共享的 Pipeworx 元工具——ask_pipeworx、 discover_tools、search_within、remember/recall,以及 gateway 全局工具集中的其他工具。因此,你看到的工具数量会多于此表:目前,单工具包端点会在该工具包自身的工具之外,列出大约 30 个共享工具。连接的 initialize 响应会说明其确切范围,是当天情况的权威答案。

这是有意为之,并非意外复用多路复用。元工具能让限定范围的连接通过 ask_pipeworx 跨整个目录路由,从而回答此工具包未涵盖的问题,而无需你添加第二个 MCP 服务。目前无法挂载不含这些元工具的工具包端点;如果额外的 schema 占用的上下文超过路由功能带来的价值,请改为连接一次完整 gateway,而不是连接多个工具包端点。

也可以连接完整的 Pipeworx gateway,直接列出所有工具包的工具,而不只是此工具包的工具:

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

两个 URL 都连接到同一个 gateway 和相同的 1882+ 个数据源。唯一的区别是直接列出哪个工具包的工具;无论连接哪一个,ask_pipeworx 都能访问所有工具。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/ms_code_section \
  -H 'Content-Type: application/json' \
  -d '{"citation":"97-3-19"}'

首次调用无需账户。检查任意工具:GET https://gateway.pipeworx.io/v1/tools/ms_code_section。查找工具:使用 {"query":"..."} 调用 POST https://gateway.pipeworx.io/v1/tools/search_packs。

独立运行(无需网关账户)

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

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

也可以直接运行,确认它能正常启动:

npx -y @pipeworx/mcp-mississippi-code

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

使用 ask_pipeworx

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

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

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

更多信息

许可证

MIT

评论

支持 Markdown

第一次接触 MCP?

从协议是什么,到在客户端里装上第一个服务,这几条回答覆盖了大多数入门问题。

一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。