Tennessee Code

@pipeworx/tennessee-code

田纳西州注释法典（T.C.A.）——按引证和官方条文标题（主题搜索）查找州法规。无需密钥。

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

此工具包提供的是截至 2021-05-21 的某一时间点快照，并非现行法典。 若要将其用于任何需要准确现行文本的场景，请先阅读下方的“为什么这是快照”，每次响应也会对此作出说明。

工具

• tn_statute(citation) — 按引证获取 T.C.A. 条款的全文 （“39-13-202”是一级谋杀；“66-28-301”是押金法规）。通过内置索引解析引证对应的标题，实时获取该标题的 HTML，并根据条款自身唯一的锚点 ID 从中截取。还会返回 later_acts——本工具包自建索引显示，自 2021-05-21 快照以来所有涉及此确切引证的 Public Chapter（舰队 #2916，见下方“叠加层”）。
• tn_search(query, limit?) — 在内置的引证 + 官方条文标题索引中进行主题/关键词搜索（不搜索法规正文全文）。

身份验证

无需密钥。

为什么这是快照，而非现行法典

田纳西州自身的出版安排规定，现行的 TCA 仅通过 LexisNexis 的 advance.lexis.com 提供——这是一个受 Cookie/会话限制的 SPA，没有稳定的单条引证 URL。我们已实时确认这一点（追踪了 lexisnexis.com/hottopics/tncode -> advance.lexis.com/container?config=...，它会立即检测是否支持 Cookie，之后才开始任何客户端渲染）。这与本工具包系列判定为不支持的同类限制相同（ASP.NET 回发 / 反机器人机制 / JS 渲染的 SPA）。

没有其他官方电子渠道，而这一缺失曾诉诸法律解决，并非只是没有相关记录：Public.Resource.Org v. Matthew Bender & Co.，686 S.W.3d 1（Tenn. Ct. App. 2023）（2024 年田纳西州最高法院驳回进一步上诉）裁定，田纳西州《公共记录法》不适用于电子版 TCA，因为 LexisNexis 是根据单独的法定安排（T.C.A. § 1-2-114）为法典委员会提供服务的私人承包商，并非持有公共记录的州政府机构。在这场争议中败诉后——而且在提起诉讼前就已无法访问电子版法典——Public.Resource.Org 让 UniCourt 扫描并转换印刷版卷册，并将结果发布于 https://unicourt.github.io/cic-code-tn/：

“此代码仓库由 UniCourt 代表 Public.Resource.Org 创建。 所有工作均属于公共领域，且不保留任何权利。” — 第 76 次发布，日期为 2021.05.21。

这一公共领域主张基于“政府法令”理论；美国最高法院在 Georgia v. Public.Resource.Org，590 U.S. 255 (2020) 一案中确认，该理论适用于佐治亚州自己的注释法典——而且，这里使用的正是同一转换流程（cic-beautify-state-codes），以及本仓库对 mcps/georgia-code 上游已信任的同一份样式表引用。

同一版本也已上传至 archive.org，条目为 gov.tn.tca（已直接核验，法规文本逐字节相同）。本工具包改用 GitHub Pages 上的副本，是基于开发过程中发现的两个具体原因，而非抽象偏好：

1. 可靠性／延迟。 archive.org 的镜像节点在本次发布中多次返回临时 HTTP 500 错误，并在生成索引和对 tn_statute 进行冒烟测试时出现数秒到无限期的停滞（一个 7.2MB 的法典标题在一次调用中耗时 12.9s，在另一次调用中则始终没有返回，即使客户端超时设为 60s，并重试 3 次也是如此）。对于相同文件，GitHub Pages 每次都能稳定地在不到 1s 内响应。
2. 完整性。 archive.org 上传的 Title 47（商业票据与交易／UCC）带有 LexisNexis 的“© ... 保留所有权利”声明，标记也完全不同（p.p5），而不是其他所有法典标题都采用的 PRO 公共领域转换格式（span.boldspan）——显然这是该文件的一次错误上传。UniCourt 上的 Title 47 副本采用了正确的公共领域转换格式，与其他 67 个法典标题一致。因此，此资源包涵盖了全部 68 个已发布的法典标题（archive.org 的副本只能支持 66 个，Title 47 和另一个暂时无法获取的法典标题除外）。

不存在任何更新的发布版本。 我们检查了 UniCourt 索引页上列出的“Release NN dated YYYY.MM.DD”信息，以及 archive.org 的单独上传记录：双方最新的都是 release 76（2021.05.21）。上文提及的 2023-2024 年诉讼正是原因——Public.Resource.Org 正在努力恢复当前的电子数据源，但最终败诉。因此，此资源包中的每个响应都会明确标注 current_through 和 data_as_of 为 2021-05-21。2021 至 2025 年间约五届田纳西州立法会议通过的修订均未反映在其中。

我们也检查并排除了其他免费渠道，并非只是没有尝试：

候选来源	结果
wapp.capitol.tn.gov / capitol.tn.gov（田纳西州议会）	发布Public Chapters（已通过的会议法律）和法案文本，但没有整合后的现行法典——其自身的“Tennessee Code”链接会跳转到上文提到的 LexisNexis 付费墙。会议法律与编纂后的 TCA 是不同的文档（见下文“Public Chapters 并非法典”）。
law.justia.com/codes/tennessee/	对不带额外请求头的抓取请求返回 Cloudflare 的“Just a moment”托管式 JS 挑战（HTTP 403，包含 cf_chl_opt）——这并非可以通过更改普通 User-Agent 绕过的门槛，而是与本系列资源包视为不可用的同类机器人墙。显然，Google 自己的爬虫可以通过（搜索结果中能找到已编入索引的页面），但普通 HTTP 客户端不行。
codes.findlaw.com/tn/	同样遇到 Cloudflare 托管式挑战，结果相同。
law.resource.org/pub/us/code/tn/	这是上文诉讼的诉讼案卷（2021-2024 年的法庭文件），不是法典镜像。实际扫描文本位于上述两个镜像中，不在 law.resource.org 自身的文件目录中。
SOS（sos.tn.gov）	发布 Acts 和 Resolutions（会议法律），没有整合后的法典；根据 Code Commission 的安排，该网站会将电子版 TCA 请求引导至 LexisNexis。

Public Chapters 并非法典

田纳西州议会按年份发布 Public Chapters——即通过的会议法律，例如 capitol.tn.gov/Archives/Joint/publications/PublicChapters/2024/...—— 而且这些内容确实是最新且免费的。但 Public Chapter 是修订法案（“AN ACT to amend Tennessee Code Annotated, Title 47...”），而不是编纂后的法典文本本身——阅读某一章只能知道发生了什么变更，无法得知修订后的条文在法典其余内容中的完整表述。此资源包不会尝试将会议法律合并到冻结于 2021-05-21 的文本中（这种整合正是 Code Commission 编纂法典时所做的工作，超出了本资源包的范围）；如果不进行实际整合，就把这种合并文本称为“现行法典”是不诚实的。如果调用方需要了解 2021 年以来的变更，应直接查阅 Public Chapters，而不是使用此资源包。

覆盖层：后续法案，绝不合并（fleet #2916）

Bruce 保留了冻结于 2021-05-21 的快照中的 tn_statute（“想办法解决”），而没有追求完全核对一致的现行法典——这与 Arkansas（fleet #2906）和 Mississippi（fleet #2915）的处理相同。这个覆盖层是在该决定之上成本最低且诚实的改进——设计和测量数据见 docs/current-statute-routes.md（#2902）。

规则：绝不重写快照 text。只在旁边添加带日期、带链接的列表，并明确标注为未合并。 tn_statute 的响应包含：

• later_acts — 自快照日期以来，凡是涉及这条确切引文的 Public Chapter，各有一条记录：public_chapter（编号）、general_assembly（例如 "114"）、bill（例如 "HB0001"）、link（该法案自己的 PDF）、verb（"amended" / "repealed" / "new_section"）、source: "tnga"、merged: false。空值（[]）表示该索引在已检查的每份 Effective Report 中都没有显示涉及这条引文的后续 Public Chapter——并不表示覆盖层加载失败（若内置索引缺失或格式错误，会像 tn_search 的 catchline 索引一样直接抛出错误）。
• sessions_checked — 索引覆盖的每份 Public Chapters Effective Report，即使 later_acts 为空也会列出，让调用方能分辨“没有变化”和“我们没有检查”。
• later_acts_data_as_of — 上次构建覆盖层的时间。
• later_acts_parse_rate_pct — 在此次构建所抓取的所有法案 PDF 中，构建器实际能解析为引文的“Tennessee Code Annotated, Section/Title ...”修订条款的实测占比（见下文“测得的覆盖率”）。每条法案记录的 date: null 都是如实填写——Effective Report 和法案 PDF 都没有提供每条引文对应的颁布日期（Effective Report 中的日期对应整个 chapter，而非单个 section）；与其猜测，不如如实说明。

来源，以及为何这是自行构建的索引，而非州政府维护的索引（与 Arkansas 不同）： Tennessee 的立法机构没有发布类似 arkleg.state.ar.us 的“本法案涉及哪些引文”索引——这已由 docs/current-statute-routes.md 确认。这个包通过两个无需密钥的公开来源自行构建索引；两者均已确认可正常访问，没有机器人拦截，也无需登录：

1. 哪些法案成为法律，以及它们的 Public Chapter 编号 — Tennessee General Assembly 自己发布的“Public Chapters Effective Report”（capitol.tn.gov/Archives/Joint/publications/PublicChapters/<year>/PublicChapters_<year><01|07>.pdf），每年发布两次。这是一份无需密钥、可提取文本的普通 PDF 表格，列出该届 General Assembly 中所有成为 Public Chapter 的法案及其 PC 编号和生效日期——但摘要只到 Title/Chapter 层级，不包含确切的 section 引文。
2. 涉及的确切引文 — 每项已通过法案自身的文本，通过 capitol.tn.gov/Bills/<ga>/Bill/<billId>.pdf 无需密钥即可获取；对其进行解析，以查找固定套话 "Tennessee Code Annotated, Section <cite>, is amended ..."（还包括 "... is repealed ..."；对于全新 section，则查找 "... Title X, Chapter Y[, Part Z], is amended by adding the following as a new part/section:"，随后是新 section 自身带编号的标题）。

已知限制，特此说明：链接指向的是已提交法案文本，而非单独发布的最终成法文本。 Tennessee 没有提供稳定、无需密钥的已签署最终文本 URL，不像 Arkansas 的索引会直接链接到该法案的 PDF。唯一可能提供该文本的来源是 Secretary of State 的“Acts and Resolutions”页面（sos.tn.gov）；该页面对本包如实使用的 User-Agent 返回 HTTP 403，这是 CloudFront/WAF 规则所致（已于 2026-10-09 确认），而浏览器 UA 则可通过。本包不会伪装 UA 以绕过拦截。因此，later_acts 条目是可靠信号，表明这条引文受到该 Public Chapter 的影响，并链接到法案自身的已提交文本——但不保证该文本与最终经全体议员修订的文本逐字节一致。 **自动发现，而非硬编码：**待检查的 Effective Report 列表会实时从 wapp.capitol.tn.gov/apps/WebPublications/Index 自身的出版物表格中读取，因此新发布的报告无需更改代码就会显示出来——这与 Arkansas 由 <select> 驱动的 session 自动发现具有相同的自扩展特性。

在 Release-76 快照中不存在、但在覆盖层中存在的章节会被特别标记：tn_statute 的 found: false 响应会携带 later_acts_if_created——如果索引显示某条引文对应有 Public Chapters，但该章节在 2021 快照中不存在，这表明该章节可能是快照日期之后才创建的，不一定是错误引文。

覆盖情况测量（fleet #2916 烘焙测试，记录于 2026-10-10）

• 检查了 11 份 Effective Reports（2021 年 7 月至 2026 年 7 月），覆盖 第 112、113 和 114 届 General Assemblies。
• 发现 1,289 个唯一的（General Assembly，Public Chapter）配对。
• 1,289 份账单 PDF 全部成功获取（在预期路径 capitol.tn.gov/Bills/<ga>/Bill/<billId>.pdf 下，缺失数为 0）。
• 在这些账单中发现 4,245 个“Tennessee Code Annotated, ...”修订子句；其中 3,858 个（90.9%）解析成功（修订／废除／新章节），387 个未解析。解析率按子句粒度统计——一个列出多个引文的子句（“Sections 1-2-3 and 4-5-6, are amended”）算作一个子句，而不是两个，因此不会虚增比率。
• 从已解析的子句中提取出 3,873 条引文（3,767 条修订、0 条废除——此时间范围内没有账单使用单独的“is repealed”固定措辞；所有看起来像废除的子句都使用了“is amended by deleting ... and substituting”，解析器无法可靠地区分这种写法与普通改写，因此将其留作未解析，而不错误标记；另有 106 条新章节），去重后得到 2,834 条 TN_LATER_ACTS 记录。
• 387 个未解析子句可分为两类已知且如实披露的缺口（绝不会静默丢弃——src/tn-index-data.ts 中的 TN_LATER_ACTS_UNPARSED_SAMPLE 附带最多 60 条样本，烘焙脚本每次运行时都会在 stderr 中报告完整计数）：
  • 章节／部分级的“is amended by adding ... as a new section”子句，但新章节在账单文本中完全没有编号标题——田纳西州的立法起草有时会将引文留给 Code Commission 在编纂时分配，因此账单文本本身不会写明引文（通过人工检查多个样本确认——插入的文本直接以实质性内容开头，没有“NN-NN-NNN.”标题）。这是 SOURCE 本身的实际限制，并非可修复的解析器缺口。
  • 少量解析器尚未专门处理的一次性起草格式变体：整章“is amended by deleting the chapter and substituting”、包含内部换行且本次构建的两轮修复未覆盖的多引文列表，以及少数虽提及“Tennessee Code Annotated”但并非修订子句的句子（例如 Code Commission 的出版指示）。
• 示例（本任务自身的测试引文）：T.C.A. § 39-13-202（一级谋杀）对应 3 项后续 Public Chapters——PC 528（HB0511）、PC 394（HB0512）、PC 500（SB1228），均属第 112 届 GA；这些均未合并到 2021-05-21 快照文本中。

对于下一个覆盖层构建：直接复用，不要重新推导

响应格式（later_acts/sessions_checked/ later_acts_merged_into_text: false/“永不改写文本”规则）、 烘焙索引 + KV 注入模式（将新的导出追加到 catchline 索引已在使用的同一个 src/tn-index-data.ts 文件中），以及 “动态发现，不要硬编码”的技巧，都可以直接沿用自 Arkansas 的 #2906 和本套件自身的 #2916。各州真正不同的是：州议会是否维护自己的引文到法案索引 （Arkansas：是；Mississippi 和 Tennessee：否，需要从已签署法案文本构建索引），以及是否存在专门用于 AS-ENACTED 文本的稳定无密钥 URL （Arkansas：有，即法案 PDF；Tennessee：没有——见上文）。

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

• 引文查询——可用（tn_statute），涵盖全部 68 个标题。
• 主题/关键词搜索——可用（tn_search），但它匹配的是 官方标题（条款/章节标题），而非完整的法规正文——与 mcps/north-dakota-code 的 nd_search 形式相同。此来源不提供实时全文搜索（它是静态扫描件，而非搜索 API）。
• 修订/制定历史——部分可用：多数修订条款后面的“Acts YYYY, ch. N, § N; ...”立法历史行会包含在 tn_statute 的 text 中；解析成功时，也会单独作为 history 显示。自最初制定以来从未修订过的条款可能完全没有此类行。
• 历史版本（某条款在指定修订之前的文本）——除这份 2021-05-21 快照所保留的内容外，不可用。这里没有 Colorado 或 Indiana 发布的那种按年份存档；而可能提供此类存档的实时网站（LexisNexis），正是本套件无法访问的屏障。

从标题文件中截取条款

与大多数同类州法典套件不同，这里不存在需要解决的标题正则表达式歧义：Public.Resource.Org 的转换已为每个条款提供了唯一的锚点 ID（id="t{title}c{chapter}s{citation}"，例如 39-13-202 对应 id="t39c13s39-13-202"）。tn_statute 从该 ID 开始截取，直到以下最先出现的位置：下一条款的 ID、下一章的 <h2>，或标题自身的 h4#...-NOTESTODECISIONS 标题——此处注释文本从法规（及其自身的立法/编者注释）切换为判例摘要。所有响应都会排除该判例摘要，和 mcps/colorado-code 在自己的“ANNOTATION”区块前划定编者内容与法规文本界线的做法相同。

与 archive.org 上传的同一版本相比，有一处标记差异： UniCourt 的 HTML 在“Title NN”/“Chapter NN”与名称之间使用单独的 <br />，而 archive.org 的副本使用的是空的 span.headbreak — scripts/bake-index.mjs 中的标题/章节正则表达式两种格式都接受，以防未来版本重新采用另一种格式。

刷新路径

src/tn-index-data.ts 包含两张独立构建的表，两者都通过 workers/gateway/src/pack-baked-indexes.json 从 KV 注入，作为一个合并的 _bakedIndex 对象，而不是打包进来（fleet #2754：通过值导入的数 MB 表会加载到每个网关隔离环境中，无论它是否会提供这个工具包）——与 mcps/arkansas-code 的 ar-index-data.ts 一样，也是两张表的结构：

• TN_CHAPTERS/TN_SECTIONS — tn_search 的条文标题索引。运行 node scripts/bake-index.mjs > src/tn-index-data.ts 重新构建（会覆盖文件——见下文）。只有在 Public.Resource.Org/UniCourt 发布比 76 更新的版本时才需要重新运行（脚本始终解析网站自身最新的“Release NN dated YYYY.MM.DD”行，不会硬编码版本号）。
• TN_LATER_ACTS/TN_LATER_ACTS_SESSIONS_CHECKED — tn_statute 的覆盖层索引（fleet #2916，见上文“The overlay”）。运行 node scripts/bake-later-acts.mjs >> src/tn-index-data.ts 重新构建（会追加内容）。每次发布 Public Chapters Effective Report 后（1 月、7 月）重新运行——定时版本见 .github/workflows/tennessee-later-acts-refresh.yml。报告会自动发现（读取 wapp.capitol.tn.gov/apps/WebPublications/Index 上的实时出版物列表），因此无需更改代码就能发现新报告。

完整重新生成（两张表）：

node mcps/tennessee-code/scripts/bake-index.mjs > mcps/tennessee-code/src/tn-index-data.ts
node mcps/tennessee-code/scripts/bake-later-acts.mjs >> mcps/tennessee-code/src/tn-index-data.ts

条文标题索引构建会获取全部约 68 个标题文件（总计约 145MB），并在请求之间短暂暂停；如果解析出的行数少得可疑，脚本会明确报错，而不会静默通过——这表示来源网站的标记发生了变化，而不是法典变短了。TN_EXCLUDED_TITLES 仍作为防御性检查保留：如果某个标题的 HTML 不含 PRO 的“is in the public domain”句子，就会将其排除并在此处注明，而不会静默地将其当作公有领域内容提供（当前为空——本次发布中的每个标题都符合条件）。出于同样的原因，后续法案构建会获取所有有效报告及其发现的所有法案 PDF，并设有自己的 MIN_ROWS 合理性下限。

任一表重新生成后（在仓库根目录）运行 node ../../scripts/check-baked-indexes.mjs——它会像 KV 上传器一样动态导入重新生成的文件，并在空导出数组进入部署前拒绝继续。

引用

田纳西州的引用格式为标题-章-节，例如“39-13-202”（标题 39，第 13 章，第 202 节：一级谋杀）或“66-28-301”（标题 66，第 28 章，第 301 节：保证金）。tn_statute 会直接在预构建索引中查找引用，而不是将其拆分解析，因此只要后缀格式与索引中的 ID 完全匹配，索引使用的任何后缀形式（例如带字母的子节“39-17-417(a)”）都能正确往返处理。

数据来源

• https://unicourt.github.io/cic-code-tn/ — 版本索引页。每次构建时读取一次，而不是每次调用都读取，以确定当前版本标签。
• https://unicourt.github.io/cic-code-tn/transforms/tn/octn/r76/gov.tn.tca.title.{NN}.html — 单个标题的完整文本（法规 + 立法注释 + 判例摘要）。只构建一次到 src/tn-index-data.ts，作为引用+条文标题索引（而非法规文本）；tn_statute 每次调用时都会实时获取特定标题，并仅提取请求的条文。

两者都是 GitHub Pages 上公开、无需密钥的静态文件——无需登录、无需 JS，也未观察到速率限制；开发期间响应时间始终不到 1 秒。

快速开始

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

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

此端点实际提供的内容

https://gateway.pipeworx.io/tennessee-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 都会访问同一个网关和相同的 1784+ 个数据源。唯一的区别在于直接列出的是哪个工具包的工具；无论使用哪个 URL，ask_pipeworx 都能访问所有工具。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/tn_statute \
  -H 'Content-Type: application/json' \
  -d '{"citation":"39-13-202"}'

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

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

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

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

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

npx -y @pipeworx/mcp-tennessee-code

它通过 stdin/stdout 使用 MCP 通信，并响应 initialize/tools/list/tools/call，但仅提供此工具包的工具——不包含上述网关连接额外提供的共享元工具。源码相同，工具相同，但没有 ask_pipeworx 路由功能。

使用 ask_pipeworx

你也可以用自然语言提问，而不必直接调用工具——此功能既适用于上面的工具包端点，也适用于完整网关：

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

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT