OSHA Recordkeeping MCP — 29 CFR Part 1904

一个确定性的 Model Context Protocol 服务器，帮助安全经理回答每次有人受伤时都会面对的问题：这起事故是否属于 OSHA 可记录事件？

十一个工具沿着一起事故从有人受伤到正确的日志条目走完全程，每个工具都返回带引用的判定，而不是模型对规则的记忆。MIT 许可，免费使用。

仅用于参考和分诊——不构成法律建议，也不构成医学判定。 每项判定都附带其 CFR 引用以及底层数据最后一次对照 eCFR 核验的日期，因此推理过程是可审计的，而非凭空断言。

使用方法

git clone https://github.com/srhtdmrkl/osha-recordkeeping-mcp.git
cd osha-recordkeeping-mcp && npm install && npm run build

然后将其添加到 Claude Desktop 的 claude_desktop_config.json 中：

{
  "mcpServers": {
    "osha": { "command": "node", "args": ["/absolute/path/to/dist/index.js"] }
  }
}

如果您使用 nvm，请使用 node 二进制的绝对路径——Claude Desktop 不会加载您的 shell 配置文件，因此裸的 node 无法解析。

配套的 Skill 承载了操作流程：链条何时适用、调用前需要确认什么、以及哪些事项是工具无法判定的。

Related MCP server: Quellgeist

这个工具存在的原因

每次事故都需要依据 29 CFR Part 1904 评估工伤可记录性。错误的判定会带来直接的合规风险：过度记录会人为抬高总可记录事故率（TRIR），而漏记则会依据 29 CFR 1904.4 招致 OSHA 传票。

Part 1904 下的可记录性评估涉及多个独立的触发条件：一般标准（死亡、缺勤天数、工作受限、意识丧失、1904.7 下 PLHCP 的诊断）、特定案例规则（针刺伤、医学移除、听力损失、1904.8–1904.12 下的结核病），以及治疗分类。就治疗而言，1904.7(b)(5)(ii) 定义了一个封闭的、包含 14 项的列举清单，列出急救治疗。在类型化工具中实现这些封闭的监管规则，用可复现的查找逻辑取代了 LLM 对监管文本的插值。

分工：LLM 叙述，工具判定

调用模型做它擅长的事——阅读混乱的事故叙述并将其映射为规范代码（治疗类型、结果）。工具做模型在法律判定中绝不能做的事——确定性地应用封闭清单并返回带引用的答案。工具从不接受自由文本的治疗描述；它接受受控词汇表，以确保判定可复现。

锚定工具：osha_assess_recordability

输入。 模型将叙述映射为以下字段；它绝不传递自由文本。

前三个数组是必填的，这是有意为之。默认值 [] 无法与*"我检查过了，没有"*区分开来，因此让它们默认为空会让一个信息不完整的叙述返回一个自信的、带引用的假阴性——而漏记正是会招致传票的方向。

输出。 一个 RuleRecord，其值携带 recordable、basis、triggering_factors（每个都带有各自的子条款引用）、当 1904.39 可能适用时的 severe_injury_reporting_note、针对标准对日志本身施加后果的 log_entry_notes，以及当没有任何内容被断言时的 under_specified。注册层会添加 determination_final 和 clarification_required——参见下文引导询问。

判定逻辑（确定性） — 1904.4(b)(2) 决策树，按顺序：

1. 如果 work_related 为 false → 不可记录（1904.5）。

2. 如果 new_case 为 false → 不新增条目，但如果天数或结果发生变化，则更新现有条目（1904.6）。决策树在此处路由；它不会简单地停止。

3. 否则，如果存在任何 specific_case_criteria → 依据 1904.8-1904.12 可记录，完全不查阅急救清单。

4. 否则，如果存在任何 outcome → 可记录（一般记录标准，1904.7(b)(1)）。

5. 否则，如果存在任何 significant_diagnosis → 即使只给予了急救也可记录（1904.7(b)(7)）。

6. 否则，如果任何 treatment 不在封闭的急救清单中 → 可记录（超出急救范围的医疗治疗，1904.7(b)(5)(i)）。

7. 否则 → 不可记录（仅急救，且无特定案例标准）。

第 3 步的存在是因为 1904.4(a)(3) 是一个析取：1904.7 或 1904.8-1904.12 的特定案例。没有这一步，一个用清洁和绷带处理的受污染针刺伤会返回"不可记录"——还附带引用——而同一服务器的隐私工具却正确地将其判定为隐私案例。从不查阅急救清单的记录标准必须在查阅急救清单之前检查，而不是之后。

协议面（全部三种 MCP 原语）

此服务器使用完整协议，而不仅仅是 Tools：

• Tools — 下文事故分诊链下列出的十一项判定。每个都声明了 outputSchema 并返回类型化的 structuredContent，而非 JSON 字符串，并且每个都标注了 readOnlyHint: true、destructiveHint: false、idempotentHint: true、openWorldHint: false——安全、可重试、纯查找。

• Resources — 全部十五个数据集都直接暴露，因此客户端可以将参考数据作为上下文加载，而不必只能通过工具调用来获取。数据模型就是产品；Resources 使其可见。URI 为 osha://data/<id>，其中 <id> 是 src/datasets.ts 中的键——例如 osha://data/first-aid-treatments、osha://data/partially-exempt-industries、osha://data/privacy-cases。

• Prompt — triage_incident 将一起事故作为单个用户调用的工作流走完整个链条：范围界定 → 记录雇主 → 工作相关性 → 新案例 → 工作受限 → 听力损失 → 可记录性 → 报告截止日期 → 300 日志列 → 隐私案例 → 机构。

• 引导询问 — osha_assess_recordability 解决它绝不能猜测的一个边界情况：非处方药与处方强度药物。非处方强度属于急救；处方强度属于医疗治疗且可记录。当叙述未说明时，模型传递 medication_unspecified_strength，强度通过询问人类来解决——绝不由工具自行选择。

  两级解析。 引导询问是一项可选的 MCP 能力，因此服务器会检查 getClientCapabilities() 并选择其通道：

  客户端声明 elicitation	通道	结果
  是	服务器直接提示用户	在一次工具调用中解决
  否	返回 determination_final: false + clarification_required	模型在聊天中询问，然后使用已解析的代码重新调用

  无论哪种方式，问题都会到达人类手中，工具绝不猜测。临时结果保持保守——recordable: true，依据标记为待确认——clarification_required 携带问题、CFR 理由，以及每个答案要发回的精确治疗代码。

  特定客户端落在哪一级值得检查而非假设。 此处已验证：Claude Desktop 的聊天客户端不声明 elicitation 能力，MCP Inspector 0.15.0 和 1.0.0 也不声明。代理型客户端可能不同，而通过自身机制询问用户的客户端从外部看起来完全相同。服务器在连接时向 stderr 记录 elicitation=supported|NOT supported——在任何客户端下启动它并读取该行。

来源与强制衰减

RuleRecord<T>（参见 src/types.ts）携带监管规则：cfr_cite、source_url、last_verified，以及当 eCFR 提供时的 amendment_history 和 editorial_note。没有 effective_date 字段；数据集携带当前的 eCFR 文本，last_verified 表示监管核验的日期。

衰减通过 scripts/check-decay.ts 强制执行，如果任何记录的 last_verified 超过其衰减阈值，该脚本会使构建失败。它在推送时和每周 CI 计划中运行，验证子部分 source_url 目标，并检查 eCFR 的 editorial_note 条目。

事故分诊链（随附）

十一个确定性工具，沿着一起事故从"有人受伤"到正确的日志条目走完全程：

1. osha_check_recordkeeping_obligation（1904.1、1904.2）——所有其他判定都以此为前提的问题：该雇主究竟是否需要保存记录？规模豁免按整个公司上一日历年的峰值就业人数衡量——不是平均值，也不是单一场所。行业豁免依附于场所，工具在给定 NAICS 代码时，会对照封闭的 82 项附录 A 清单进行判定。两者都是部分豁免：1904.39 严重伤害报告在任一豁免下仍然适用——这正是被豁免雇主最容易得出危险错误推断的地方。

2. osha_determine_recording_employer（1904.31）——这是一个门槛问题，而非一个步骤：当受伤者不在工资单上时，这到底是不是该雇主的案件？**决定权在日常监督，而非工资单。**一名由机构支付工资的临时工，若其工作由你每日指挥，则须由你记录；同一名临时工若在机构监督下工作，则不属于你的记录范围。自雇人士完全不在 OSH 法案范围内，独资企业的业主或合伙人也不属于记录意义上的雇员。(b)(4) 要求案件必须且只能记录一次——绝不能同时出现在两份日志上。

3. osha_assess_work_relatedness（1904.5）——这是其余一切判定所依赖的门槛，也是此前本项目交给模型处理的唯一法律判断。1904.5(a) 对工作环境中发生的任何情况推定其与工作相关；1904.5(b)(2) 是九项可推翻该推定的封闭例外清单。该判定刻意采用三值——work_related、not_work_related 或 requires_judgment——因为 1904.5 包含法规本身交由雇主裁量的路径：原因不明（1904.5(b)(3)）、出差状态（b)(6)）、在家工作（b)(7)），以及每项例外都依赖的"唯一"认定。将这些强行压缩为布尔值，等于让工具去猜测 Part 1904 中最具争议的判定。它还能纠正人们记反的情形。在通勤途中于公司场地内发生的机动车事故属于 (b)(2)(vii) 的例外；在同一场地内滑倒则不属于任何例外，仍与工作相关。而精神疾病则颠倒了通常方向——除非雇员自愿提供 PLHCP 的意见（b)(2)(ix)），否则不属于工作相关。

4. osha_assess_new_case（1904.6）——是新增一条 300 日志条目，还是更新已有条目？这是 1904.4(a) 合取条件的第二个条件。它区分了法规刻意分开的两种复发情形：由工作场所暴露引起的事件属于新案件（b)(2)）——例如生产线上触发的职业性哮喘——而症状在无暴露情况下复发的慢性疾病则只记录一次（b)(1)）。注意 (b)(1) 并非封闭清单：法规称"示例可包括"癌症、石棉肺、棉肺和硅肺，因此该工具询问的是病症的性质，而非匹配疾病名称。它也是服务器中唯一一个服从外部权威的工具。根据 (b)(3)，雇主无需咨询 PLHCP，但一旦咨询，必须遵循其建议——因此 PLHCP 意见完全覆盖规则逻辑，而相互冲突的意见则返回 requires_judgment，因为权衡这些意见明确属于雇主的职责。

5. osha_evaluate_restricted_work（1904.7(b)(4)）——该限制是否真的算数？并非所有限制都算数，而两种错误都会使案件被移入或移出日志。仅限受伤当日的限制不计入（b)(4)(iii)）；在仍执行所有常规职能的情况下产出减少不计入（b)(4)(vi)）；"常规职能"指每周至少执行一次的活动（b)(4)(ii)）。部分班次确实计入（b)(4)(v)），调岗与限制共用同一列（b)(4)(x)）。最有趣的是 (b)(4)(vii)：当诸如*"轻体力工作"*之类的模糊建议无法向 PLHCP 澄清时，该案必须记录为受限工作。这是法规在自身存疑时倾向于记录——也是 Part 1904 中唯一一条默认记录规则。

6. osha_evaluate_hearing_loss（1904.10）——Part 1904 中唯一纯算术的记录标准，也是这里唯一一个计算而非查表的工具。两项测试必须在同一只耳朵中同时满足：相对基线出现 10 dB 标准阈值偏移，以及总听力水平高于听力零值 25 dB 或以上，两者均在 2000、3000 和 4000 Hz 处取平均值。一只耳朵有 STS 而另一只耳朵达到 25 dB 水平，不构成记录。年龄调整仅适用于偏移测试，绝不适用于 25 dB 测试。

7. osha_assess_recordability（1904.4）——是否可记录？（锚点，见上文）

8. osha_check_severe_injury_reporting（1904.39）——是否必须向 OSHA 报告，以及何时报告？返回从雇主得知该事件起计算的实际截止时间戳（死亡 8 小时，住院/截肢/失去一只眼睛 24 小时），检查事件发生后的资格窗口，并标记截止时间是否已逾期。

9. osha_classify_300_log_entry（1904.29）——在最严重结果规则下，300 日志的结果列（G/H/I/J）是哪一列、伤害/疾病类型列，以及上限为 180 天的天数。

10. osha_check_privacy_case（1904.29(b)(6)-(9)）——雇员的姓名能否出现在日志上？这是第二个封闭清单，且双向封闭：(b)(7) 列举了六种隐私关切情形，而 (b)(8) 禁止将任何其他情形视为隐私关切——因此雇主既不能出于同情而扩展它，也不能忽略它。返回字面日志条目（"privacy case"）以及随之而来的义务：单独的保密清单（(b)(6)）、在叙述本身可能识别出雇员时对案件描述的酌情处理（(b)(9)），以及当记录提供给除政府代表以外的任何人时进行编辑（(b)(10)）。

11. osha_route_to_establishment_log（1904.30）——关于单个事件的最后一个问题：应记录在哪个场所的 300 日志上。该规则与直觉相悖：案件跟随地点，而非人。在雇主另一家工厂顶班时受伤的人，记录在该工厂的日志上——这会推动该场所的 TRIR 数字。在远离所有场所的地方受伤——客户现场、途中、远程——则记录在雇员正常工作所在的场所日志上。

范围：仅限 Part 1904

这里的一切都回答一个问题——有人受伤了；OSHA 要求我记录和报告什么？ 这就是 29 CFR Part 1904 的全部内容，而上述十一个工具正是它强制要求的判定。

分发：一个服务器和一个 Skill

两个产物，因为它们回答不同的问题。服务器负责判定；Skill 负责知道何时调用它。

服务器——三个入口，一个引擎

三个入口都调用同一个 createServer()，使用相同的十一个工具和十五个数据集——src/tools/ 中的任何内容都不知道正在运行的是哪一个。这种可移植性来自两个早期决策，而非移植工作本身：判定是纯函数，而 datasets.ts 是与 JSON 的唯一接触点。

每个变体都是无状态的——每个请求一个全新服务器，没有会话 ID，调用之间不保留任何内容，因为每个工具都是对捆绑数据的纯查找。/health 报告每个数据集的年龄与其衰减阈值的关系，并在数据集过期时返回 503，因此托管部署与构建遵循相同的规则。

npm run start:http      # node host — PORT=3000 MCP_PATH=/mcp by default
npm run smoke:http      # boots it, drives it with a real client, checks /health

npm run dev:worker      # wrangler dev — runs under workerd, not Node
npm run smoke:worker    # boots workerd and drives it with a real client
npm run deploy:worker   # wrangler deploy

smoke:worker 是唯一在 workerd 下运行工具的检查。另外两个 smoke 在 Node 上运行，结构上无法看到 node 内置项潜入代码路径——而这正是部署首先会暴露的问题。nodejs_compat 在 wrangler.toml 中刻意设为 OFF，以便该失败在开发中响亮而非静默。

该 worker 仅接受 POST。无状态服务器不会发起任何消息，因此 GET SSE 流不携带任何内容，会永远保持打开；workerd 会取消响应从未完成的请求。405 并带 Allow: POST 是协议表达"不存在服务器到客户端的流"的方式。

无认证，这是有意的。服务器暴露已发布的监管文本，不存储任何内容，也没有副作用，因此访问控制应放在其前面——Cloudflare Access 或 OAuth 层——而非在其内部半实现。

速率限制

速率限制是例外，它存在于 worker 内部而非其前面。部署在 workers.dev 上，这不是账户中的区域，因此 WAF 速率限制规则没有可依附的对象。在 wrangler.toml 中声明为 [[ratelimits]] 绑定，这也意味着它会被审查、版本化并随部署一起移动，而不是存在于无人 diff 的仪表板中。

每个客户端 IP 每分钟 300 个请求。 刻意宽松：限制器以 IP 为键，而一个公司 NAT 后面的安全团队共享一个键。一次分诊链大约 15 个请求，因此多人同时工作合法地超过 150/分钟。此限制旨在切断模型在错误上循环——这是真正威胁托管部署的失败——而非限制正常使用。超过限制返回 429 并带 Retry-After。

/health 位于检查之上，因此按计划轮询的监控器永远不会耗尽预算。执行按数据中心而非全局协调，因此它是截止而非精确配额。

工具接收的内容

服务器不检索任何内容，也不存储任何内容。但参数仍然流入，它们描述真实事件，因此"无用户数据"是关于存储的声明，与传输无关。这一区别值得明确说明，因为这是 EHS 团队必须评估的。

没有输入是标识符。 任何模式中都没有姓名、员工编号、出生日期、地址或自由文本叙述的字段——每个输入都是案件的属性（work_related、days_away_from_work、treatments），判定不需要其他任何内容。这是模式的性质，而非策略：没有字段可以放入姓名。Skill 也指示模型不要将身份信息带入调用，因此约束在两端都成立——参见 传递事实，而非身份。

某些属性仍然敏感。 osha_check_privacy_case 恰好接受 1904.29(b)(7) 列举的类别——sexual_assault、mental_illness、hiv_hepatitis_or_tuberculosis、contaminated_needlestick_or_sharps。法规特别指出这些类别，正是因为它们绝不能出现在同事可读的日志上。仅属性也不同于匿名：在九人场所，性质代码加上事件日期可以识别出任何在那里工作的人。

这取决于传输方式，且仅取决于传输方式：

无论哪种情况都不会记录任何日志——没有请求日志，没有工具调用日志，无论成功与否。这是有意为之。这些参数的日志本身就会构成一个受监管的存储库，而该服务器上本就没有需要监管的内容；而且判定结果已经可以从输入加上每个响应中携带的 last_verified 数据集版本复现。响应中的溯源信息完成了审计日志的工作，却无需保留数据。

因此：如果你在 GDPR 或 HIPAA 下处理真实案件，请运行 stdio，或在你掌控的基础设施上自行托管 worker。 将受监管的事故数据指向他人托管的此服务器副本，意味着将伤害属性发送给你没有协议的第三方。判定逻辑是对打包 JSON 的纯函数——自行托管的成本只是一次 wrangler deploy，且不会改变任何答案。

Host 与 Origin 校验

认证关乎谁可以提问。Host 校验关乎浏览器是否被诱导代表他人提问，这是任何上游网关都无法事后补救的——因此这部分在 src/httpGuard.ts 中处理，并适用于两个 HTTP 入口点。

它所封堵的攻击是 DNS rebinding：攻击者域名重新解析到 127.0.0.1，浏览器将请求视为同源请求并无预检地发送，本地运行的 MCP 服务器随即应答。Host 头仍然会暴露这一点——它携带的是攻击者的域名——因此精确匹配的 host 白名单就是有效的检查手段。

两者都接受逗号分隔的列表；当上游网关拥有决策权时，* 可关闭检查。Origin 仅在请求头存在时才被检查，因为非浏览器的 MCP 客户端不会发送该头。/health 位于白名单之外——可用性监控器不在威胁模型之内。

Node 入口点默认仅回环地址。 容器或反向代理部署通过其他名称访问，必须设置 MCP_ALLOWED_HOSTS；否则会以 403 失败并指明它看到的请求头，这是五秒钟就能修复的问题。相反的默认值则是一个无人察觉的漏洞。请注意，绑定地址本身不是防护——绑定 0.0.0.0 仍是默认值以便容器正常工作，而白名单才是使其安全的关键。

被拒绝的请求返回 403 及 JSON-RPC -32000 错误。超大请求体（>1 MB）返回 413，格式错误的 JSON 返回 400——客户端错误不会作为事件记录。

Skill

skills/osha-incident-triage/ 承载流程：链条何时适用、调用之前需要确认什么、如何呈现判定结果，以及工具无法决定什么。它包含事件分诊的流程指引，不直接承载监管逻辑。

布局

判定逻辑是纯函数且可测试的；服务器只是围绕它的接线。

src/
  index.ts              stdio entry point — Claude Desktop, local development
  http.ts               Streamable HTTP entry point — container / node host
  worker.ts             Cloudflare Workers entry point — same server, fetch handler
  server.ts             createServer() factory + registerRuleTool/toolResult helpers
  httpGuard.ts          Host/Origin allowlisting shared by both HTTP entry points —
                        one implementation, since Node and workerd share no middleware
  datasets.ts           the one place JSON assets are loaded and named — static imports,
                        so the same module resolves with or without a filesystem
  types.ts              RuleRecord, Provenance, and the ruleRecord() constructor
  md.d.ts               ambient declaration letting SKILL.md be imported as a string,
                        so the worker can serve it without a filesystem
  tools/                one pure function per determination — no MCP imports except
                        medicationStrength.ts, which owns the elicitation exchange
  registrations/
    tools/              one registerX.ts per tool + a barrel; metadata and summaries
    resources.ts        generated from the DATASETS table
    prompts.ts          triage_incident

添加一个工具意味着在 src/tools/ 中新增一个文件（规则）、在 src/registrations/tools/ 中新增一个文件（如何描述和总结），以及在 barrel 文件中新增一行。register 前缀使这些文件名在编辑器标签栏中与 src/tools/ 中的对应文件区分开来。

有两个值得保持的不变式：溯源信息仅由 ruleRecord() 组装；Resources 从工具加载所用的同一张 DATASETS 表生成，因此数据集不可能发布在没有任何工具读取的路径下。

持续集成

.github/workflows/ci.yml 在 Node 20 和 22 上运行类型检查、构建、单元测试和冒烟测试套件。

衰减检查和 npm audit 与 CI 其余部分在同一触发器上运行——push、pull request 以及每周计划——作为独立作业，以便任一失败都能单独呈现，而不是多个红叉中的一个。npm audit 在生产依赖的低级别漏洞公告上阻止构建；开发依赖的公告仅报告，不阻止。每周计划用于捕获针对 main 上已有依赖版本发布的公告——此时没有任何 push 会触发重新检查。

tsconfig.json 排除了 test/，因此 tsc --noEmit 仅检查 src/，而 ts-jest 在 npm test 期间对测试文件进行类型检查。

变更控制与版本管理

CHANGELOG.md 在两个独立的发布维度上跟踪所有变更：

• 代码： 判定逻辑、工具 schema 和服务器传输遵循语义化版本控制。

• 监管数据： src/data/ 下打包的 eCFR JSON 数据集。对照当前 eCFR 文本重新验证数据集会更新其 last_verified 日期，并以补丁更新形式发布，即使监管文本未发生变化，也能为合规团队维护可审计的溯源信息。

• 强制衰减： CI 每周运行 scripts/check-decay.ts，若任何数据集超过 365 天衰减阈值且未经手动重新验证，则使构建失败。

• 发布： GitHub 上的版本标签（vX.Y.Z）触发 .github/workflows/release.yml 运行完整验证套件（类型检查、测试、冒烟、衰减、审计）并创建经过验证的 GitHub Release。

开发

npm install
npm run build       # tsc + copy src/data → dist/data
npm test            # jest — deterministic logic
npm run check-decay # build-breaking staleness trap
npm run smoke       # end-to-end: spawn the server, list tools/resources/prompts, call a tool

通过 npx @modelcontextprotocol/inspector 本地连接，或将其添加到指向 dist/index.js 的 claude_desktop_config.json 中。

npm run smoke:worker 和 npm run dev:worker 需要 Node 22 或更高版本，因为 wrangler 有此要求。其他一切在 Node 20 上运行，且 engines 有意保持为 >=20：该字段声明的是谁能安装和运行服务器——这只需要 SDK 和 zod。Wrangler 是开发工具，永远不会到达消费者手中，因此其要求不属于包的要求。CI 正是为此在矩阵中保留 Node 20，并仅在那里跳过 worker 冒烟测试。

评估

evals/recordkeeping-evals.xml——四十七个问题，测试 LLM 是否通过工具得出正确答案，这是单元测试无法覆盖的。每个答案都是通过真实 MCP 客户端驱动构建后的服务器产生的；追踪记录在 evals/README.md 中。这四十七个问题中大多数都有一个凭记忆推理的模型会触及的直觉性错误答案。

免责声明

仅供参考和分诊使用。不构成法律建议，不构成医疗判定。可记录性边缘案例通常需要 PLHCP 或法律顾问介入。工作相关性（1904.5）仅沿其确定性路径判定；来源不明、出差状态、居家办公以及任何未经确认的"唯一"结论均返回 requires_judgment 而非判定结果。