How do I use osha-recordkeeping-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@osha-recordkeeping-mcp Is this injury OSHA recordable? Employee fractured arm." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

osha-recordkeeping-mcp

by srhtdmrkl

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

OSHA Recordkeeping MCP — 29 CFR Part 1904

A deterministic Model Context Protocol server that helps a safety manager answer the question they face every time someone gets hurt: is this OSHA recordable?

Eleven tools follow one incident from someone got hurt to a correct log entry, each returning a cited determination rather than a model's recollection of the rule. MIT licensed and free to use.

Reference and triage only — not legal advice, and not a medical determination. Every determination carries its CFR citation and the date the underlying data was last verified against eCFR, so the reasoning is auditable rather than asserted.

Using it

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

Then add it to Claude Desktop's claude_desktop_config.json:

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

Use an absolute path to your node binary if you use nvm — Claude Desktop does not source your shell profile, so a bare node will not resolve.

The companion Skill carries the procedure: when the chain applies, what to establish before calling, and what the tools cannot decide.

Related MCP server: Quellgeist

Why this tool exists

Evaluating workplace injury recordability under 29 CFR Part 1904 occurs on every incident. Incorrect determinations carry direct compliance risks: over-recording artificially inflates Total Recordable Incident Rate (TRIR), while under-recording incurs OSHA citations under 29 CFR 1904.4.

Recordability under Part 1904 evaluates multiple independent triggers: general criteria (fatality, days away, job restriction, loss of consciousness, PLHCP diagnoses under 1904.7), specific case rules (needlesticks, medical removal, hearing loss, TB under 1904.8–1904.12), and treatment classification. For treatment, 1904.7(b)(5)(ii) defines a closed, 14-item enumerated list of first-aid treatments. Implementing these closed regulatory rules inside typed tools replaces LLM interpolation over regulatory text with reproducible lookup logic.

Division of labor: LLM narrates, tool decides

The calling model does what it is good at — reading a messy incident narrative and mapping it to canonical codes (treatment types, outcomes). The tool does what a model must not do for a legal determination — apply the closed list deterministically and return a cited answer. The tool never accepts free-text treatment descriptions; it accepts a controlled vocabulary so the determination is reproducible.

The anchor tool: `osha_assess_recordability`

Input. The model maps the narrative to these; it never passes free text.

Field	Meaning
`work_related`	1904.5 — supply from `osha_assess_work_relatedness`, do not judge it here
`new_case`	1904.6 — supply from `osha_assess_new_case`
`outcomes`	`death`, `days_away_from_work`, `restricted_work_or_transfer`, `loss_of_consciousness`
`significant_diagnoses`	`cancer`, `chronic_irreversible_disease`, `fractured_or_cracked_bone`, `punctured_eardrum` (1904.7(b)(7))
`specific_case_criteria`	1904.8-1904.12 triggers — needlestick, medical removal, hearing loss, TB, bloodborne exposure with diagnosis
`plhcp_recommendations_not_followed`	The three places a recommendation binds even when the employee ignored it (1904.7(b)(3)(ii), (b)(4)(viii), (b)(5)(v))
`medical_removal_was_voluntary_and_early`	Guard for 1904.9(b)(3) — pulling someone out early is not recordable
`tuberculosis_test_was_pre_employment`	Guard for 1904.11(b)(1) — a hiring-physical positive is not occupational
`treatments`	Controlled codes. First-aid codes come from the closed list; two codes are neither first aid nor medical treatment (1904.7(b)(5)(i))

The first three arrays are required, deliberately. A default of [] cannot be told apart from "I checked and there were none", so defaulting them lets an under-specified narrative return a confident, cited false negative — the under-recording direction that draws a citation.

Output. A RuleRecord whose value carries recordable, basis, triggering_factors (each with its own sub-clause cite), severe_injury_reporting_note when 1904.39 may be in play, log_entry_notes for consequences a criterion imposes on the log itself, and under_specified when nothing at all was asserted. The registration layer adds determination_final and clarification_required — see Elicitation below.

Determination logic (deterministic) — the 1904.4(b)(2) decision tree in order:

If work_related is false → not recordable (1904.5).
If new_case is false → no new entry, but update the existing one if the day counts or outcome have changed (1904.6). The tree routes here; it does not simply stop.
Else if any specific_case_criteria is present → recordable under 1904.8-1904.12, without consulting the first-aid list at all.
Else if any outcome is present → recordable (general recording criteria, 1904.7(b)(1)).
Else if any significant_diagnosis is present → recordable even if only first aid was given (1904.7(b)(7)).
Else if any treatment is not in the closed first-aid list → recordable (medical treatment beyond first aid, 1904.7(b)(5)(i)).
Else → not recordable (first-aid only, and no specific-case criterion).

Step 3 exists because 1904.4(a)(3) is a disjunction: 1904.7 or the specific cases of 1904.8-1904.12. Without it a contaminated needlestick treated with cleaning and a bandage came back "not recordable" — with a citation attached — while the same server's privacy tool correctly called it a privacy case. Recording criteria that never consult the first-aid list have to be checked before it, not after.

Protocol surface (all three MCP primitives)

This server uses the full protocol, not just Tools:

Tools — the eleven determinations listed under The incident-triage chain below. Each declares an outputSchema and returns typed structuredContent, not a JSON string, and each is annotated readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false — safe, retryable, pure lookups.
Resources — all fifteen datasets are exposed directly, so a client can load the reference data as context rather than only reaching it through a tool call. The data model is the product; Resources are what make it visible. URIs are osha://data/<id>, where <id> is the key in src/datasets.ts — e.g. osha://data/first-aid-treatments, osha://data/partially-exempt-industries, osha://data/privacy-cases.
Prompt — triage_incident walks one incident through the whole chain as a single user-invoked workflow: scope → recording employer → work-relatedness → new case → restricted work → hearing loss → recordability → reporting deadline → 300-Log column → privacy case → establishment.

Elicitation — osha_assess_recordability resolves the one edge case it must not guess: OTC vs. prescription-strength medication. Nonprescription-strength is first aid; prescription-strength is medical treatment and recordable. When the narrative is silent the model passes medication_unspecified_strength and the strength gets resolved by asking a human — never by the tool picking.

Two-tier resolution. Elicitation is an optional MCP capability, so the server checks getClientCapabilities() and picks its channel:

Client advertises `elicitation`	Channel	Result
Yes	Server prompts the user directly	Resolved in one tool call
No	Returns `determination_final: false` + `clarification_required`	Model asks in chat, then re-calls with the resolved code

Either way the question reaches a human and the tool never guesses. The provisional result stays conservative — recordable: true, basis marked pending confirmation — and clarification_required carries the question, the CFR reason, and the exact treatment code to send back for each answer.

Which tier a given client lands in is worth checking rather than assuming. Verified here: Claude Desktop's chat client advertises no elicitation capability, and neither does MCP Inspector 0.15.0 or 1.0.0. Agentic clients may differ, and a client that asks the user via its own mechanism looks identical from the outside. The server logs elicitation=supported|NOT supported to stderr on connect — start it under any client and read that line.

Provenance & enforced decay

RuleRecord<T> (see src/types.ts) carries regulatory rules: cfr_cite, source_url, last_verified, and where the eCFR supplies them, amendment_history and editorial_note. There is no effective_date field; datasets carry current eCFR text, and last_verified indicates the date of regulatory verification.

Decay is enforced via scripts/check-decay.ts, which fails the build if any record's last_verified exceeds its decay threshold. It runs on push and on a weekly CI schedule, validates subpart source_url targets, and checks for eCFR editorial_note entries.

The incident-triage chain (shipped)

Eleven deterministic tools that follow one incident from "someone got hurt" to a correct log entry:

osha_check_recordkeeping_obligation (1904.1, 1904.2) — the question every other determination assumes: must this employer keep records at all? The size exemption is measured across the entire company on peak employment last calendar year — not an average, not one site. The industry exemption attaches to the establishment, and the tool resolves it against the closed 82-code Appendix A list when given a NAICS code. Both are partial: 1904.39 severe-injury reporting survives either, which is the inference an exempt employer gets dangerously wrong.
osha_determine_recording_employer (1904.31) — a threshold question, not a step: when the injured person is not on the payroll, is this the employer's case at all? Day-to-day supervision decides, not the paycheck. A temp on an agency's payroll whose work you direct daily is yours to record; the same temp under the agency's supervision is not. Self-employed people are outside the OSH Act entirely, and owners or partners of a sole proprietorship are not employees for recordkeeping. (b)(4) requires the case be recorded exactly once — never on both logs.
osha_assess_work_relatedness (1904.5) — the gate everything else rests on, and until now the one legal judgment this project handed to the model. 1904.5(a) presumes work-relatedness for anything arising in the work environment; 1904.5(b)(2) is a closed list of nine exceptions that can defeat it. The verdict is deliberately three-valued — work_related, not_work_related, or requires_judgment — because 1904.5 contains paths the regulation itself assigns to the employer: unclear origin (1904.5(b)(3)), travel status (b)(6), working at home (b)(7), and the "solely" finding every exception depends on. Forcing those into a boolean would be the tool guessing at the most-disputed call in Part 1904. It also settles cases memory gets backwards. A motor-vehicle accident while commuting on the company lot is excepted under (b)(2)(vii); a slip and fall in the same lot is not covered by any exception and stays work-related. And mental illness inverts the usual direction — not work-related unless the employee volunteers a PLHCP opinion (b)(2)(ix).
osha_assess_new_case (1904.6) — a new 300-Log entry, or an update to one already there? The second condition of the 1904.4(a) conjunction. It splits the two recurrence cases the regulation deliberately separates: an episode caused by a workplace exposure is a new case (b)(2) — occupational asthma triggered on the line — while a chronic illness whose symptoms recur without exposure is recorded once only (b)(1). Note (b)(1) is not a closed list: the regulation says "examples may include" cancer, asbestosis, byssinosis and silicosis, so the tool asks about the character of the condition rather than matching illness names. It is also the only tool in the server that defers to an outside authority. Under (b)(3) an employer need not consult a PLHCP, but having consulted one must follow the recommendation — so a PLHCP opinion overrides the rule logic entirely, and conflicting opinions return requires_judgment because weighing them is expressly the employer's job.
osha_evaluate_restricted_work (1904.7(b)(4)) — does the restriction actually count? Not every one does, and both errors move cases on or off the log. A restriction confined to the day of injury does not count (b)(4)(iii); reduced output while still performing all routine functions does not (b)(4)(vi); "routine functions" means activities performed at least once per week (b)(4)(ii). A partial shift does count (b)(4)(v)), and transfers share the restriction column (b)(4)(x)). The interesting one is (b)(4)(vii): when a vague recommendation like "light duty" cannot be clarified with the PLHCP, the case must be recorded as restricted work. That is the regulation resolving its own doubt toward recording — and the only default-to-record rule in Part 1904.
osha_evaluate_hearing_loss (1904.10) — the one recording criterion in Part 1904 that is pure arithmetic, and the only tool here that computes rather than looks up. Two tests must both be met in the same ear: a 10 dB standard threshold shift against the baseline, and a total hearing level of 25 dB or more above audiometric zero, each averaged at 2000, 3000 and 4000 Hz. An STS in one ear and a 25 dB level in the other does not record. Age adjustment applies to the shift test only, never to the 25 dB test.
osha_assess_recordability (1904.4) — is it recordable? (the anchor, above)
osha_check_severe_injury_reporting (1904.39) — must it be reported to OSHA, and by when? Returns the actual deadline timestamp (8 hours for a fatality, 24 for hospitalization / amputation / loss of an eye) computed from when the employer learned of it, checks the eligibility window from the incident, and flags whether the clock is already overdue.
osha_classify_300_log_entry (1904.29) — which 300-Log outcome column (G/H/I/J) under the most-serious-outcome rule, the injury/illness type column, and day counts capped at 180.
osha_check_privacy_case (1904.29(b)(6)-(9)) — may the employee's name go on the log at all? A second closed list, and closed in both directions: (b)(7) enumerates the six privacy concern cases, and (b)(8) forbids treating anything else as one — so an employer cannot extend it out of sympathy any more than they can ignore it. Returns the literal log entry ("privacy case") plus the obligations that follow: the separate confidential list ((b)(6)), discretion in describing the case when the narrative alone could identify the employee ((b)(9)), and redaction when records go to anyone but a government representative ((b)(10)).
osha_route_to_establishment_log (1904.30) — which establishment's 300 Log, the last question about an individual incident. The rule runs against intuition: a case follows the place, not the person. Someone hurt while covering a shift at another of the employer's plants is recorded on that plant's log, which moves the number that drives its site TRIR. An injury away from every establishment — customer site, in transit, remote — goes on the log of the site where the employee normally works.

Scope: Part 1904, and nothing else

Everything here answers one question — someone got hurt; what does OSHA require me to record and report? That is 29 CFR Part 1904 end to end, and the eleven tools above are the determinations it forces.

Distribution: a server and a Skill

Two artifacts, because they answer different questions. The server decides; the Skill knows when to ask it.

The server — three entry points, one engine

Entry point	Transport	For
`dist/index.js`	stdio	Claude Desktop, local development
`dist/http.js`	Streamable HTTP	a container or node host
`src/worker.ts`	Streamable HTTP	Cloudflare Workers

All three call the same createServer() over the same eleven tools and fifteen datasets — nothing in src/tools/ knows which one is running. That portability came from two earlier decisions rather than from porting effort: the determinations are pure functions, and datasets.ts is the single point of contact with the JSON.

Every variant is stateless — a fresh server per request, no session ids, nothing kept between calls, because every tool is a pure lookup over bundled data. /health reports each dataset's age against its decay threshold and returns 503 when one goes stale, so a hosted deployment is watched on the same rule the build is.

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 is the only check that runs the tools under workerd. The other two smokes run on Node and structurally cannot see a node built-in creeping into a code path — which is exactly what a deploy would surface first. nodejs_compat is deliberately OFF in wrangler.toml so that failure is loud in dev rather than silent.

The worker accepts POST only. A stateless server initiates no messages, so the GET SSE stream carries nothing and would stay open forever; workerd cancels a request whose response never completes. 405 with Allow: POST is the protocol's way of saying there is no server-to-client stream.

No authentication, on purpose. The server exposes published regulatory text, stores nothing, and has no side effects, so access control belongs in front of it — Cloudflare Access or an OAuth layer — rather than half-implemented inside it.

Rate limiting

Rate limiting is the exception, and it lives in the worker rather than in front of it. The deployment is on workers.dev, which is not a zone in the account, so a WAF rate limiting rule has nothing to attach to. Declared as a [[ratelimits]] binding in wrangler.toml, which also means it is reviewed, versioned and travels with the deploy instead of living in a dashboard nobody diffs.

300 requests per minute per client IP. Deliberately generous: the limiter keys on IP, and a safety team behind one corporate NAT shares a single key. One triage chain is roughly 15 requests, so several people working at once legitimately clears 150/minute. This is sized to cut off a model looping on an error — the failure that actually threatens a hosted deployment — not to meter normal use. Over the limit returns 429 with Retry-After.

/health sits above the check, so an uptime monitor polling on a schedule can never be what exhausts the budget. Enforcement is per data centre rather than globally coordinated, so it is a cutoff rather than an exact quota.

What the tools receive

The server retrieves nothing and stores nothing. But arguments still flow in, and they describe a real incident, so "no user data" is a claim about storage that says nothing about transit. The distinction is worth stating plainly, because it is the one an EHS team has to evaluate.

No input is an identifier. There is no field anywhere in the schemas for a name, employee number, date of birth, address, or free-text narrative — every input is an attribute of the case (work_related, days_away_from_work, treatments) and the determination needs nothing else. That is a property of the schemas, not a policy: there is no field to put a name in. The Skill instructs the model not to carry identity across into a call either, so the constraint holds at both ends — see Pass facts, never identities.

Some attributes are sensitive anyway. osha_check_privacy_case takes exactly the categories 1904.29(b)(7) enumerates — sexual_assault, mental_illness, hiv_hepatitis_or_tuberculosis, contaminated_needlestick_or_sharps. The regulation singles those out precisely because they are the ones that must not appear on a log a coworker can read. Attribute-only is also not the same as anonymous: a nature code plus an incident date at a nine-person establishment can identify someone to anyone who works there.

Where that lands depends on the transport, and only on the transport:

Entry point	Where arguments go
stdio	stays on the machine running the server; the AI host still sees it
node HTTP / worker	crosses the network to whoever operates that deployment

Nothing is logged either way — no request logging, no tool-call logging, successful or otherwise. That is deliberate. A log of these arguments would be a regulated repository in its own right, on a server that otherwise has nothing to regulate, and determinations are already reproducible from the inputs plus the last_verified dataset version carried in every response. Provenance in the response does the job an audit log would, without the retention.

So: if you are handling real cases under GDPR or HIPAA, run stdio, or self-host the worker on infrastructure you control. Pointing regulated incident data at someone else's hosted copy of this server means sending injury attributes to a third party you have no agreement with. The determinations are pure functions over bundled JSON — self-hosting costs one wrangler deploy and changes nothing about the answers.

Host and Origin validation

Authentication is about who may ask. Host validation is about a browser being made to ask on someone else's behalf, which no upstream gateway can retrofit — so that part is handled in src/httpGuard.ts and applies to both HTTP entry points.

The attack it closes is DNS rebinding: an attacker domain re-resolves to 127.0.0.1, the browser treats the request as same-origin and sends it with no preflight, and a locally-run MCP server answers. The Host header is what still gives it away — it carries the attacker's domain — so an exact-match host allowlist is the check that works.

Variable	Node (`dist/http.js`)	Worker
`HOST`	bind address, default `0.0.0.0`	—
`MCP_ALLOWED_HOSTS`	default `localhost:$PORT`, `127.0.0.1:$PORT`, `[::1]:$PORT`	unset = unrestricted
`MCP_ALLOWED_ORIGINS`	unset = unrestricted	unset = unrestricted

Both accept a comma-separated list; * turns the check off when a gateway in front owns the decision. Origin is only checked when the header is present, because non-browser MCP clients do not send one. /health sits outside the allowlist — an uptime monitor is not the threat model.

The node entry point defaults to loopback-only. A container or reverse-proxy deployment is reached by another name and must set MCP_ALLOWED_HOSTS; it fails with a 403 naming the header it saw, which is a five-second fix. The opposite default is a hole nobody notices. Note that the bind address is not the protection — binding 0.0.0.0 stays the default so containers work, and the allowlist is what makes that safe.

Rejected requests get 403 with a JSON-RPC -32000 error. Oversized bodies (>1 MB) get 413, malformed JSON gets 400 — client mistakes are not logged as incidents.

The Skill

skills/osha-incident-triage/ carries the procedure: when the chain applies, what to establish before calling, how to present a determination, and what the tools cannot decide. It contains process guidance for incident triage and carries no regulatory logic directly.

Layout

Determination logic is pure and testable; the server is wiring around it.

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

Adding a tool means one file in src/tools/ (the rule), one in src/registrations/tools/ (how it is described and summarised), and one line in the barrel. The register prefix keeps those filenames distinct from their src/tools/ counterparts in an editor tab bar.

Two invariants worth keeping: provenance is assembled only by ruleRecord(), and Resources are generated from the same DATASETS table the tools load from, so a dataset cannot be published under a path no tool reads.

Continuous integration

.github/workflows/ci.yml runs typecheck, build, unit tests, and smoke suites on Node 20 and 22.

The decay check and npm audit both run on the same triggers as the rest of CI — push, pull request, and a weekly schedule — kept as separate jobs so either failure is legible on its own rather than one red X among several. npm audit blocks the build on low-level production vulnerability advisories; dev-dependency advisories are reported, not blocking. The weekly schedule is what catches an advisory published against a dependency version already on main, where nothing would otherwise push to trigger a re-check.

tsconfig.json excludes test/, so tsc --noEmit checks src/ only and ts-jest typechecks test files during npm test.

Change control & versioning

CHANGELOG.md tracks all changes across two independent release dimensions:

Code: Determination logic, tool schemas, and server transports follow Semantic Versioning.
Regulatory data: Bundled eCFR JSON datasets under src/data/. Re-verifying a dataset against current eCFR text moves its last_verified date and is released as a patch update, even when regulatory text has not changed, maintaining auditable provenance for compliance teams.
Enforced Decay: CI runs scripts/check-decay.ts weekly to fail the build if any dataset exceeds its 365-day decay threshold without manual re-verification.
Releases: Version tags (vX.Y.Z) on GitHub trigger .github/workflows/release.yml to run full validation suites (typecheck, tests, smokes, decay, audit) and create a verified GitHub Release.

Develop

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

Connect locally via npx @modelcontextprotocol/inspector, or add to claude_desktop_config.json pointing at dist/index.js.

npm run smoke:worker and npm run dev:worker need Node 22 or newer, because wrangler does. Everything else runs on Node 20, and engines stays at >=20 deliberately: that field is a claim about who can install and run the server, which needs only the SDK and zod. Wrangler is dev tooling and never reaches a consumer, so its requirement is not the package's. CI keeps Node 20 in the matrix for exactly that reason and skips only the worker smoke there.

Evaluations

evals/recordkeeping-evals.xml — forty-seven questions testing whether an LLM reaches the right answer through the tools, which unit tests cannot cover. Every answer was produced by driving the built server with a real MCP client; the trace is in evals/README.md. Most of the forty-seven have an intuitive wrong answer a model reasoning from memory will reach for.

Disclaimer

Reference and triage only. Not legal advice, not a medical determination. Recordability edge cases frequently require a PLHCP or counsel. Work-relatedness (1904.5) is determined only along its deterministic paths; unclear origin, travel status, working at home, and any unestablished "solely" finding return requires_judgment rather than a verdict.

Available Tools

11 tools

osha_assess_new_caseAssess New Case vs. Continuation (29 CFR 1904.6)A

Read-onlyIdempotent

Determine whether an injury or illness is a NEW case or a continuation of one already on the 300 Log — the second condition of the 1904.4(a) conjunction. Run this after osha_assess_work_relatedness and before osha_assess_recordability, and pass its new_case result through. Key distinctions it settles: a recurrence CAUSED by a workplace exposure is a new case (1904.6(b)(2), e.g. an occupational asthma episode), while a chronic illness whose symptoms recur WITHOUT exposure is recorded only once (1904.6(b)(1)). A PLHCP recommendation, once sought, is binding and overrides the rule logic (1904.6(b)(3)). Returns work_case verdicts of new_case, not_new_case, or requires_judgment — the last when PLHCP opinions conflict or causation is unestablished. Treat requires_judgment as a question for the user, never as a licence to pick. Reference and triage only — not legal advice or a medical determination.

ParametersJSON Schema

Name	Required	Description	Default
`plhcp_opinion`	No	Any physician or licensed health care professional recommendation on whether this is a new case or a recurrence. Under 1904.6(b)(3) an employer need not seek one, but MUST follow it once sought — so this OVERRIDES the rule logic. Use 'conflicting' when two or more PLHCPs disagree; the employer must then decide which is most authoritative.	none
`causation_is_clear`	No	Is it clear whether a workplace event caused the current signs or symptoms, as opposed to the condition simply continuing? Pass false when the narrative does not establish this; the tool will return requires_judgment rather than pick.
`recovered_completely_from_prior`	No	Had the employee recovered completely from the prior recorded case — ALL signs and symptoms had disappeared — before the current signs or symptoms appeared? (1904.6(a)(2))
`prior_recorded_same_type_same_body_part`	Yes	Has the employee previously experienced a RECORDED injury or illness of the same type affecting the same part of the body? (1904.6(a)(1)) If false, the case is new and nothing else needs deciding.
`workplace_event_caused_current_symptoms`	No	Did an event or exposure in the workplace cause the current signs or symptoms? (1904.6(b)(2)) An episode of occupational asthma triggered by a workplace exposure is a new case even though the asthma itself is not new.
`chronic_recurs_without_workplace_exposure`	No	Is this an occupational illness whose signs or symptoms may recur or continue in the ABSENCE of a workplace exposure? Examples may include occupational cancer, asbestosis, byssinosis and silicosis (1904.6(b)(1)). This is a description of character, NOT a closed list of illnesses — judge the condition, do not match the name. Such cases are recorded once only.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the basic safety and side-effect profile. The description adds meaningful context beyond that by explaining the binding PLHCP override (1904.6(b)(3)) and clarifying that requires_judgment is a non-decision state to be escalated, not acted upon. It does not detail return-format specifics, but with an output schema present and the annotations already carrying the safety burden, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: purpose first, then workflow ordering, then the key legal distinctions, then the output verdicts and a caution about misuse. Each sentence carries distinct regulatory or procedural information. It loses one point for density — the 1904.6(b)(3) PLHCP rule is described in a long single sentence, and the overlap between the description's example ('occupational asthma episode') and the schema's parameter description is some slight redundancy, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 100% parameter coverage, an output schema, and read-only/idempotent annotations, the description fills every remaining gap: imputed workflow position among 10 sibling tools, special-case handling (PLHCP binding), and the output's semantics (requires_judgment means ask the user). No side-effect or resource-lifetime concerns exist for this read-only classifier, so nothing is arguably missing to invoke/triage correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (all 6 parameters have rich schema descriptions), so the baseline is already 3. The description adds substantial value beyond the schema by interpreting the regulatory context: why PLHCP opinion overrides the logic, what 'conflicting' means in practice, and what makes requires_judgment occur. The parameter 'causation_is_clear' gets practical meaning — 'Pass false when the narrative does not establish this' — which the schema itself does not fully convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Determine whether an injury or illness is a NEW case or a continuation of one already on the 300 Log.' It precisely names the second condition of the 1904.4(a) conjunction and distinguishes itself from sibling tools by placing itself explicitly between osha_assess_work_relatedness and osha_assess_recordability. This gives an agent an unambiguous understanding of what the tool does and how it differs from the rest of the osha_* family.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit sequencing: 'Run this after osha_assess_work_relatedness and before osha_assess_recordability, and pass its new_case result through.' It also lists key distinctions the tool settles and provides a clear behavioral rule for ambiguous results: 'Treat requires_judgment as a question for the user, never as a licence to pick.' This is strong when-to-use guidance with a direct exclusion of misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_assess_recordabilityAssess OSHA Recordability (29 CFR 1904.4)A

Read-onlyIdempotent

Determine whether a work-related injury or illness is OSHA recordable under the 1904.4 decision tree: work-related AND a new case AND meeting either the general recording criteria of 1904.7 OR a specific-case criterion of 1904.8-1904.12 (needlestick, medical removal, hearing loss, tuberculosis). Map the incident narrative to the controlled inputs. The tool applies the closed first-aid list in 1904.7(b)(5)(ii) deterministically and returns a cited determination. Reference and triage only — not legal advice or a medical determination. If the result has determination_final=false, it is provisional: follow the clarification_required instruction, ask the user, and call this tool again with their answer.

ParametersJSON Schema

Name	Required	Description
`new_case`	Yes	Is this a new case, not a continuation of a previously recorded one? (1904.6)
`outcomes`	Yes	General recording criteria outcomes present in this case. REQUIRED — pass [] only when the narrative affirmatively establishes there were none. If the narrative is silent on time off or work restrictions, ask the user before calling; do not pass [] to mean 'unknown'.
`treatments`	Yes	Controlled treatment codes. Map the incident narrative to these codes. First-aid codes come from the closed 1904.7(b)(5)(ii) list; anything else is medical treatment. Use 'other_medical_treatment' if unsure. If the report mentions medication but not its strength, use 'medication_unspecified_strength' — the strength will be resolved by asking the user, either by the server or by you. Never guess it. REQUIRED — pass [] only when the narrative affirmatively establishes no treatment was given. Note two codes are NEITHER first aid nor medical treatment: 'observation_or_counseling_only' and 'diagnostic_procedure_only' (1904.7(b)(5)(i)) — an x-ray or a clinic visit to be checked out does not make a case recordable. And the professional status of whoever provided the treatment is irrelevant (1904.7(b)(5)(iv)): a bandage is first aid even when a physician applies it.
`work_related`	Yes	Did the work environment cause or contribute to the injury/illness? (1904.5)
`significant_diagnoses`	Yes	Significant injuries/illnesses that are recordable even if only first aid was given (1904.7(b)(7)). REQUIRED — pass [] only when affirmatively established, not when the narrative is silent.
`specific_case_criteria`	Yes	Specific-case recording criteria under 1904.8-1904.12, which are INDEPENDENT of the first-aid list: a case meeting one of these is recordable even when only first aid was given. One of: contaminated_needlestick_or_sharps, medical_removal, occupational_hearing_loss_sts, tuberculosis_infection, bloodborne_exposure_with_diagnosis. REQUIRED — pass [] only when affirmatively established. Note 'occupational_hearing_loss_sts' asks whether the 1904.10 audiometric test is already MET; the tool does not compute the shift.
`plhcp_recommendations_not_followed`	No	Situations where a PLHCP recommended something and the employee did not follow it. The case is recordable anyway — what was recommended controls, not what the employee did. One of: days_away_recommended_but_employee_worked, restriction_recommended_but_employee_worked_normally, medical_treatment_recommended_but_declined. (1904.7(b)(3)(ii), (b)(4)(viii), (b)(5)(v))
`tuberculosis_test_was_pre_employment`	No	For a tuberculosis case only: was the positive skin test obtained at a PRE-EMPLOYMENT physical? If so the case is NOT recordable (1904.11(b)(1)) — the employee was not occupationally exposed to a known active case in your workplace.
`medical_removal_was_voluntary_and_early`	No	For a medical removal only: was the employee removed VOLUNTARILY, before the medical removal levels required by the OSHA standard were reached? If so the case is NOT recordable (1904.9(b)(3)) — an employer who acts early is not penalised. Leave false when the removal met the standard's criteria.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the already helpful annotations of readOnlyHint, idempotentHint, and destructiveHint, the description adds meaningful behavioral detail: the tool applies the closed first-aid list deterministically, returns a cited determination, marks results provisional when needed, and requires a follow-up interaction when clarification is pending. It also discloses the limitation that this is not legal advice or a medical determination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is thorough and front-loaded with the main decision. Every sentence contributes something valuable: the decision rule, the deterministic behavior, the input-mapping requirement, the disclaimer, and the follow-up workflow. It is long because it needs to be, but it still feels tight and structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a regulatory decision tool with nine parameters, rich annotated safety metadata, and a complex sibling set, the description is complete. It covers the decision tree, the output provisional state, user clarification flow, mapping of narrative input to controlled fields, and the non-legal/non-medical disclaimer. An agent has enough information to invoke the tool and respond to the results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter already carries detailed regulatory guidance, so the description does not need to re-explain individual inputs. It adds a high-level instruction to map the incident narrative to controlled inputs, but most of the substantive usage semantics are already embedded in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action and resource: 'Determine whether a work-related injury or illness is OSHA recordable under the 1904.4 decision tree.' It then spells out the exact conditions of the decision tree, and the resource and scope are clearly distinct from sibling tools that assess only one component such as work-relatedness or new-case status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear operational context by stating 'Reference and triage only' and by specifying what to do when the result is provisional: follow the clarification_required instruction, ask the user, and call again. However, it does not explicitly name sibling tools or give exclusion conditions for when a caller should use one of them instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_assess_work_relatednessAssess Work-Relatedness (29 CFR 1904.5)A

Read-onlyIdempotent

Determine whether an injury or illness is work-related — the gate every other Part 1904 determination depends on. 1904.5(a) presumes work-relatedness for anything arising from the work environment unless one of the nine closed exceptions in 1904.5(b)(2) applies. Run this BEFORE osha_assess_recordability and pass its work_related result through. Returns one of three verdicts: work_related, not_work_related, or requires_judgment — the last when the regulation itself calls for the employer's evaluation (unclear origin under 1904.5(b)(3), travel status, working at home) or when an exception's 'solely' requirement is not established. Treat requires_judgment as a question to put to the user, never as a licence to pick. Reference and triage only — not legal advice.

ParametersJSON Schema

Name	Required	Description	Default
`origin_is_clear`	Yes	Is it clear whether the precipitating event occurred at work or away from work? Pass false when the narrative genuinely does not establish this — 1904.5(b)(3) then requires the employer to evaluate the employee's duties and environment, which this tool cannot do.
`claimed_exception`	Yes	Which 1904.5(b)(2) exception is claimed, if any. Use 'none' when no exception is asserted. One of: member_of_general_public, symptoms_surface_at_work_only, voluntary_wellness_or_recreation, personal_food_or_drink, personal_tasks_outside_working_hours, personal_grooming_self_medication_or_self_inflicted, commuting_motor_vehicle_on_company_lot, common_cold_or_flu, mental_illness_without_plhcp_opinion, none.
`special_situation`	No	Whether the employee was on travel status (1904.5(b)(6)) or working at home (1904.5(b)(7)). Both are fact-heavy and resolve to requires_judgment with the governing test returned.	none
`aggravation_tests_met`	No	Which 1904.5(b)(4) significant-aggravation tests the workplace event caused. Closed list — nothing else counts as significant aggravation. One of: death_but_for_work_event, loss_of_consciousness_but_for_work_event, days_away_restriction_or_transfer_but_for_work_event, medical_treatment_needed_or_changed.
`pre_existing_condition`	No	Is this a pre-existing condition — one that resulted solely from a non-work-related event outside the work environment (1904.5(b)(5))? If so it is work-related only if significantly aggravated.
`exception_solely_established`	No	Has it been affirmatively established that the injury results SOLELY from the claimed exception? Every 1904.5(b)(2) exception requires this and it is a factual finding, not a lookup. Pass false when unverified — the tool will return requires_judgment rather than apply the exception.
`occurred_in_work_environment`	Yes	Did the event or exposure occur in the work environment as defined by 1904.5(b)(1) — the establishment and other locations where employees work or are present as a condition of employment, including equipment and materials used in the course of work?
`mental_illness_plhcp_opinion_volunteered`	No	For a mental illness only: has the employee VOLUNTARILY given the employer a PLHCP opinion stating the illness is work-related? Under 1904.5(b)(2)(ix) a mental illness is not work-related without one.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: it explains that the tool returns one of three verdicts, specifies the exact conditions that trigger requires_judgment, and includes a not-legal-advice caveat. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but efficiently front-loaded with the core purpose, then the workflow ordering, verdict semantics, and handling guidance. Each sentence contributes distinct information: regulatory basis, tool sequencing, return values, requires_judgment behavior, and scope disclaimer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters and an output schema, the description provides enough operational context for an agent to call it correctly: when to run it, what it returns, why requires_judgment appears, and how to respond to it. The output schema covers return structure, so the description does not need to restate that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema fully documents all parameters and enums. The tool description itself does not add parameter-level detail, but it does add useful higher-level context about how the result should be used. Per the baseline for complete schema coverage, a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Determine whether an injury or illness is work-related.' It clearly identifies the tool's role as the gate for Part 1904 determinations and distinguishes it from the sibling tool osha_assess_recordability by instructing the agent to run this tool first.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit workflow guidance: 'Run this BEFORE osha_assess_recordability and pass its work_related result through.' It also tells the agent how to handle the requires_judgment verdict — 'put to the user, never as a licence to pick' — and frames the tool as 'Reference and triage only.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_check_privacy_caseCheck Privacy Concern Case (29 CFR 1904.29(b)(6)-(9))A

Read-onlyIdempotent

Determine whether a recordable case is a privacy concern case, meaning the employee's name must NOT be entered on the OSHA 300 Log. 1904.29(b)(7) is a closed list — injury to an intimate body part or the reproductive system, sexual assault, mental illness, HIV/hepatitis/tuberculosis, a contaminated needlestick or sharps cut, and other illnesses where the employee voluntarily asks to be left off. 1904.29(b)(8) forbids treating anything else as a privacy case. Returns the required log entry and the confidential-list and redaction obligations that follow, plus the only three recipients who may receive the forms with identifying information intact (1904.29(b)(10)). Run this after a case is determined recordable.

ParametersJSON Schema

Name	Required	Description
`nature`	Yes	The nature of the case, mapped from the incident narrative. Use 'none_of_these' if the case does not match any enumerated category. One of: intimate_body_part_or_reproductive_system, sexual_assault, mental_illness, hiv_hepatitis_or_tuberculosis, contaminated_needlestick_or_sharps, other_illness_employee_requested, none_of_these.
`is_illness`	No	Is this an illness (not an injury)? Only relevant to 1904.29(b)(7)(vi), which covers other ILLNESSES and never injuries.
`employee_requested_name_omitted`	No	Did the employee voluntarily request that their name not be entered on the log? Only relevant to 1904.29(b)(7)(vi), which covers other ILLNESSES.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe, read-only operation. The description adds valuable behavioral context beyond annotations: it specifies what the tool returns (required log entry, confidential-list and redaction obligations, and the only three recipients) and warns about the closed-list prohibition (1904.29(b)(8)), which prevents misapplication. This enriches the agent's understanding of side effects and output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately long but each sentence carries substantive information. The core purpose is front-loaded in the first sentence, followed by the closed-list explanation, output summary, and usage timing. For a complex regulatory topic requiring precision, this structure is efficient and not padded. It is slightly denser than necessary but appropriate given the need to convey legal nuances.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential elements: what the tool determines, what it returns, when to invoke it, and the closed-list constraint. Since an output schema exists (has output schema: true), the return structure is presumably detailed there, but the description mentions the key outputs (log entry, confidential-list, redaction obligations, three recipients) to orient the agent. It does not explicitly address edge cases like 'none_of_these' returning false, but the schema and closed-list description imply that. Overall, it is complete enough for a read-only classification tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are fully documented in the input schema. The tool description adds meaning by explaining the regulatory basis for the enum values (e.g., '1904.29(b)(7) is a closed list — injury to an intimate body part or the reproductive system, sexual assault...') and clarifies that 'other_illness_employee_requested' is the only category that requires both is_illness and employee_requested_name_omitted. This helps the agent map incident narratives to the correct enum value and understand the conditional logic.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Determine'), a precise resource ('whether a recordable case is a privacy concern case'), and the core consequence (name must NOT be entered on the OSHA 300 Log). It explicitly distinguishes from siblings by indicating this runs after recordability is established, which is not obvious from any other tool. The mention of the closed list and prohibition adds specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly indicates when to run the tool ('Run this after a case is determined recordable') and provides context for the input nature by enumerating the closed list. It does not explicitly name alternative tools for different steps, but the instruction 'after a case is determined recordable' implicitly separates it from recordability assessment tools like osha_assess_recordability. The guidance is sufficient for correct usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_check_recordkeeping_obligationCheck Whether Recordkeeping Applies (29 CFR 1904.1)A

Read-onlyIdempotent

The threshold question every other Part 1904 determination assumes: is this employer required to keep OSHA injury and illness records at all? Run this FIRST for any small employer or any establishment that may be in a partially exempt industry — otherwise the chain will confidently instruct them to make 300-Log entries for a log they need not keep. Two things are commonly got backwards: the size exemption is measured across the ENTIRE COMPANY, not one establishment (1904.1(b)(1)), and it uses PEAK employment during the last calendar year, not an average or year-end figure (1904.1(b)(2)). A written request from OSHA or BLS under 1904.41/1904.42 defeats the exemption. CRITICALLY, the exemption is PARTIAL: 1904.39 severe-injury reporting binds every employer covered by the OSH Act regardless — an exempt employer still owes OSHA the 8-hour fatality call. Supply establishment_naics_code and the tool resolves the 1904.2 industry question itself against the closed Appendix A list, matching on the first four digits. Reference and triage only.

ParametersJSON Schema

Name	Required	Description
`establishment_naics_code`	No	The establishment's NAICS code, 4 to 6 digits. Supply this and the tool looks it up against the closed Appendix A list itself — the match is on the first FOUR digits, since Appendix A lists industry groups. If you do not know the code, omit it and use establishment_in_partially_exempt_industry instead.
`notified_in_writing_to_keep_records`	No	Has OSHA or the Bureau of Labor Statistics informed the employer IN WRITING that it must keep records under 1904.41 or 1904.42? Appendix A extends this to a STATE AGENCY operating under the authority of OSHA or the BLS. Such a request defeats BOTH exemptions — 1904.1(a)(1) for size, 1904.2(a)(1) for industry.
`company_peak_employees_last_calendar_year`	Yes	The PEAK number of employees across the ENTIRE COMPANY at any time during the last calendar year (1904.1(b)(1)-(b)(2)). Not an average, not a year-end headcount, and not a single establishment's count — if the company touched 11 employees for one week, it is over the threshold.
`establishment_in_partially_exempt_industry`	No	Fallback for when the NAICS code is unknown: is this ESTABLISHMENT classified in a partially exempt industry under 1904.2? Ignored when establishment_naics_code is supplied, because the tool then determines it. Note this exemption attaches to the establishment, whereas the size exemption applies to the whole company.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false. The description adds meaningful behavioral context beyond those: it explains the size exemption measurement (entire company, peak employment), the industry exemption resolution against Appendix A, the partial nature of the exemption (1904.39 still binds), and that written notice defeats the exemption. It also notes the tool resolves the 1904.2 industry question itself. No contradictions. The only minor gap is not detailing what the return value looks like, but output schema exists and the description says 'Reference and triage only', which hints at the read-only consultative nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the critical 'Run this FIRST' instruction, then covers key behavioral traps. It is structured in logical flow: purpose, when to use, common mistakes, exceptions, and parameter hints. It is somewhat dense — the sentences are long and packed with regulatory citations. But every sentence earns its place: each clause adds a distinct fact (coverage scope, peak employment, written request exception, partial exemption). Slight deduction for density that may slow parsing, but not for waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex regulatory tool with 4 parameters (including a fallback boolean), the description and parameter-level detail together cover the key nuanced behaviors: the across-company scope, peak employment, industry exemption resolution, the written-notice defeat, and the partial exemption caveat. With output schema present, return format is not a gap. The sibling set includes many downstream chain tools, and this description establishes itself as the entry point. The completeness is high for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%. The description adds significant meaning beyond each property description. For company_peak_employees_last_calendar_year it emphasizes 'PEAK', 'ENTIRE COMPANY', 'not an average, not a year-end headcount', with an illustrative example ('if the company touched 11 employees for one week, it is over the threshold'). For establishment_naics_code it explains the 4-digit matching logic against Appendix A and the fallback to boolean. For notified_in_writing it adds context about state agencies and that it defeats both exemptions. This goes well beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'check whether recordkeeping applies' under 29 CFR 1904.1, and frames it as the threshold question before all other Part 1904 determinations. It clearly distinguishes from siblings by naming the first step in a chain and explicitly instructing to 'Run this FIRST'. The title reinforces the regulatory citation, and the description exceeds mere tautology by explaining the consequence of skipping this check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent when to use: 'Run this FIRST for any small employer or any establishment that may be in a partially exempt industry'. It gives a clear when-not condition: 'otherwise the chain will confidently instruct them to make 300-Log entries for a log they need not keep.' It also reveals two common mistakes to guard against, which adds practical usage context. No direct alternative named, but the sibling set context implies the chain, and the description frames this as the gate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_check_severe_injury_reportingCheck Severe-Injury Reporting Deadline (29 CFR 1904.39)A

Read-onlyIdempotent

Determine whether a fatality, in-patient hospitalization, amputation, or loss of an eye must be reported to OSHA, and compute the actual reporting deadline (8 hours for a fatality, 24 hours for the others) from when the employer learned of it. Also checks the eligibility window from the incident. Datetimes must be full ISO 8601. Applies the 1904.39(b)(11) amputation definition (a severed ear, avulsion, degloving or chipped tooth is NOT an amputation), the (b)(10) rule that a hospitalization for observation or diagnostics alone is not reportable, and the (b)(3)-(b)(4) exclusions for public-road motor vehicle accidents outside construction work zones and events on commercial or public transport. Every one of those still leaves the case RECORDABLE. Reference and triage only — not legal advice.

ParametersJSON Schema

Name	Required	Description	Default
`outcome`	Yes	The severe outcome, if any. 'none' means no 1904.39 reporting is triggered.
`amputation_kind`	No	For an amputation only: what kind. 1904.39(b)(11) defines amputation as the traumatic loss of a limb or external body part, and expressly EXCLUDES avulsions, enucleations, deglovings, scalpings, severed ears, and broken or chipped teeth. Fingertip amputations count with or without bone loss, as do medical amputations and parts since reattached. One of: severed_or_cut_off, fingertip_amputation, medical_amputation, reattached_part, avulsion, enucleation, degloving, scalping, severed_ear, broken_or_chipped_tooth, not_applicable.	not_applicable
`learned_datetime`	Yes	ISO 8601 datetime the employer LEARNED of the outcome. Reporting deadlines run from this moment.
`outcome_datetime`	No	ISO 8601 datetime the outcome occurred (e.g. date of death). Used to check the eligibility window (fatality within 30 days of incident; hospitalization/amputation/eye loss within 24 hours). If omitted, the window cannot be verified.
`incident_datetime`	Yes	ISO 8601 datetime of the work-related incident, e.g. 2026-07-25T09:40:00-05:00.
`reporting_exclusion`	No	Whether a 1904.39(b)(3)-(b)(4) reporting exclusion applies. A motor vehicle accident on a public street or highway is excluded UNLESS it happened in a construction work zone; events on commercial or public transport (airplane, train, subway, bus) are excluded. Either way the event is still RECORDABLE. One of: public_road_motor_vehicle_not_in_work_zone, commercial_or_public_transportation, none.	none
`hospitalization_for_observation_or_diagnostics_only`	No	For an in-patient hospitalization only: was the admission for OBSERVATION or DIAGNOSTIC TESTING alone? If so it is not reportable (1904.39(b)(10)) — only admissions for care or treatment are.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description transparently explains key behavioral rules: exclusions still leave the case recordable, observation-only hospitalizations are not reportable, and specific amputation definitions. It also clarifies that deadlines run from the learned datetime. Annotations already cover safety (read-only, idempotent), so the description adds regulatory context without redundancy.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but necessary given the regulatory complexity. It is structured logically: purpose, key rules, exclusions, and a disclaimer. While slightly long, every sentence adds relevant information, and it is not redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides sufficient regulatory context for the tool's operation, including definitions, exclusions, and deadline logic. Since an output schema is present, the lack of explicit return-value explanation is acceptable. The tool appears complete for its intended triage role.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with descriptions, and the tool description reinforces the meaning of each parameter by explaining regulatory context (e.g., amputation_kind definitions, exclusion categories). It adds value beyond the schema by linking parameters to the regulation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: determine if reporting is required and compute deadlines for severe outcomes. It uses specific verbs like 'determine' and 'compute' and references the specific regulation (29 CFR 1904.39). It distinguishes itself from general recordability tools by focusing on reporting obligations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when the tool is applicable (severe outcomes) and includes exclusions (e.g., public road accidents, transport). It also notes it is for reference and triage only, not legal advice. However, it does not explicitly contrast with sibling tools, which slightly reduces clarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_classify_300_log_entryClassify OSHA 300 Log Entry (29 CFR 1904.29)A

Read-onlyIdempotent

For a recordable case, determine the correct OSHA 300 Log outcome column (G death, H days away, I job transfer/restriction, J other recordable) using the most-serious-outcome rule, the injury/illness type column, and the day counts capped at 180. Check on_log first — it is false when the case is not recordable. Medical removal cases must be days-away or restricted, never column J, and a removal following a chemical exposure goes in the poisoning column (1904.9(b)(1)); a tuberculosis case goes in the respiratory condition column (1904.11(a)), and may be lined out on the three kinds of evidence 1904.11(b)(2) enumerates. Run osha_assess_recordability first. Reference and triage only.

ParametersJSON Schema

Name	Required	Description	Default
`death`	No	Did the injury/illness result in death?
`illness_type`	No	The injury/illness type column (M).	injury
`is_recordable`	Yes	Is the case recordable? Run osha_assess_recordability first. If false, it does not go on the 300 Log.
`tuberculosis_case`	No	Is this a tuberculosis case? 1904.11(a) requires the RESPIRATORY CONDITION column.
`days_away_from_work`	No	CALENDAR days away from work. Do NOT count the day the injury occurred (1904.7(b)(3)(i)). Count calendar days the employee was unable to work regardless of schedule — weekends, holidays and vacation days are included if they could not have worked (1904.7(b)(3)(iv)). If a PLHCP recommended a return date but the employee stayed home, end the count there (1904.7(b)(3)(iii)).
`medical_removal_case`	No	Is this a medical removal case? 1904.9(b)(1) requires it be entered as EITHER days away OR restricted work depending on how the removal requirement was met — 'other recordable' (column J) is not available.
`date_information_received`	No	ISO 8601 date the employer RECEIVED information that a recordable case occurred. 1904.29(b)(3) gives 7 calendar days from that moment — not from the incident — to complete both the 300 Log entry and the 301 Incident Report.
`days_restricted_or_transfer`	No	CALENDAR days of job transfer or restricted work, counted the same way as days away (1904.7(b)(4)(xi)). Run osha_evaluate_restricted_work first — not every restriction counts. If the employee was permanently reassigned to a job that eliminates the restricted functions, the count may stop when that becomes permanent, but at least ONE day must be counted.
`tb_non_occupational_evidence`	No	For a TB case already on the log: evidence that the infection was NOT caused by occupational exposure. 1904.11(b)(2) enumerates three circumstances and permits — does not require — lining out or erasing the entry. One of: household_contact, public_health_department_contact, medical_investigation, none.	none
`bloodborne_diagnosis_after_recording`	No	Has a case already recorded as a needlestick or sharps INJURY since produced a diagnosis of an infectious bloodborne disease? 1904.8(b)(3) then requires the existing entry to be amended rather than a new case recorded — including changing its classification from injury to illness.
`medical_removal_from_chemical_exposure`	No	Did the medical removal follow a CHEMICAL exposure? If so the POISONING column must be checked (1904.9(b)(1)) — set illness_type to 'poisoning'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds specific behavioral rules: the most-serious-outcome rule, 180-day cap, on_log false for non-recordable, medical removal never column J, chemical exposure → poisoning column, TB → respiratory condition column, and lining out on three kinds of evidence. This is substantial context beyond annotations. It doesn't restate the annotations and adds value on the regulatory logic. Not a 5 because it doesn't address what happens on edge cases like the 7-day completion deadline (though that's in the schema) or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense but well-structured paragraph: opens with the decision target, then the key rule, then the on_log gate, then the two special-column rules, and closes with the prerequisite and a triage note. No wasted words. It front-loads the most critical info (the classification rule) before regulatory details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 11 parameters, a rich output schema, and a complex regulatory domain. The description ties into the prerequisite tools and gives enough context to invoke correctly: what to check first, when not to use (on_log false, medical removal not J), and special cases. It could go deeper on the interaction with e.g. osha_evaluate_restricted_work for the restricted-days counting, or clarify the refusal of the 180-day cap on the day counts, but it covers the major decisions. Given the output schema exists, not explaining return format is acceptable. 4 is fair.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema thoroughly documents every parameter. The tool description itself doesn't expand on individual parameters, but it does compound the regulatory logic: e.g., it mentions the medical-removal rule and the chemical-exposure/poisoning link that ties to the medical_removal_from_chemical_exposure and medical_removal_case parameters, and notes the TB/gas evidence that maps to tb_non_occupational_evidence. That gives the parameters regulatory meaning beyond the schema's own text, which is already rich. I'd give 3—the schema carries most of the weight, but the description adds some regulatory interrelations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('determine the correct OSHA 300 Log outcome column'), names the exact resource (OSHA 300 Log column G/H/I/J), and explains the selection rule (most-serious-outcome, injury/illness type, day counts capped at 180). It clearly distinguishes this tool from siblings like osha_assess_recordability and osha_evaluate_restricted_work, which are mentioned as prerequisites.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs 'Run osha_assess_recordability first' and mentions 'Check on_log first' for non-recordable cases. It also references osha_evaluate_restricted_work for days restrictions in the parameter description, and 'Reference and triage only' clarifies this is a classification tool, not one that creates or modifies records. It clearly scopes when to use this tool versus when to use the assess/evaluate siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_determine_recording_employerDetermine Which Employer Records the Case (29 CFR 1904.31)A

Read-onlyIdempotent

Decide WHOSE OSHA 300 Log a case belongs on when the injured person is not a straightforward payroll employee — a temp, a leased or supplied worker, a contractor's employee, someone self-employed, or an owner. Run this FIRST whenever the injured person is not on the employer's payroll: if the answer is 'the other employer' or 'no one', the rest of the chain is not this employer's obligation. The controlling test is DAY-TO-DAY SUPERVISION, not who issues the paycheck (1904.31(b)(2)-(b)(3)): a temp on an agency's payroll whose work you direct daily is your case to record. Self-employed people are not covered by the OSH Act at all (b)(1)), and owners or partners of a sole proprietorship or partnership are not employees for recordkeeping (a)). Every payroll category counts — part-time, seasonal and migrant workers included. 1904.31(b)(4) requires the case be recorded exactly once, never on both employers' logs. Reference and triage only — not legal advice.

ParametersJSON Schema

Name	Required	Description	Default
`worker_relationship`	Yes	The injured person's relationship to the employer asking. One of: on_your_payroll, temporary_leased_or_supplied, contractor_employee, self_employed, owner_or_partner. Note 'on_your_payroll' covers every category — labor, executive, hourly, salary, part-time, seasonal and migrant workers all count (1904.31(a)).
`you_supervise_day_to_day`	No	Do YOU supervise this worker's work on a day-to-day basis? This is the controlling test for temporary, leased, supplied and contractor workers — not who issues the paycheck. Irrelevant for payroll employees, the self-employed, and owners or partners.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully discloses the decision logic, including the day-to-day supervision test and the irrelevance of paycheck issuer for temporary workers. It also references specific OSHA regulations (1904.31(a), (b)(1)-(b)(4)) and notes that it is not legal advice, which sets appropriate expectations. No contradictions with the readOnlyHint and idempotentHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a bit lengthy but well-structured with clear sentences addressing different aspects (purpose, when to use, controlling test, exclusions, and legal reference). It avoids unnecessary fluff, though some points are repeated across the description and parameter descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides comprehensive context for the decision process, including the rule for temporary workers and the exclusion of self-employed and owners. It also mentions that the case must be recorded only once (1904.31(b)(4)), making it complete for the tool's intended use within the OSHA recording workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides descriptions for both parameters, but the overall description adds meaningful context, such as clarifying that 'on_your_payroll' covers all employee types and that supervision is irrelevant for payroll employees. This enriches understanding beyond the schema's individual descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: determining which employer records a case on their OSHA 300 Log for non-payroll workers. It lists specific categories (temp, contractor, self-employed, owner) and the controlling test (day-to-day supervision), distinguishing it from sibling tools like assess_work_relatedness or evaluate_restricted_work.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to run this tool first whenever the injured person is not on the employer's payroll, and explains that if the outcome is 'the other employer' or 'no one', the rest of the chain is not this employer's obligation. This provides clear when-to-use guidance and differentiates from later steps in the recordability assessment chain.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_evaluate_hearing_lossEvaluate Occupational Hearing Loss (29 CFR 1904.10)A

Read-onlyIdempotent

Compute whether an audiogram produces a recordable hearing loss. Two tests must BOTH be met and, critically, in the SAME ear: a Standard Threshold Shift of 10 dB or more averaged at 2000, 3000 and 4000 Hz against the employee's baseline (1904.10(b)(1)), and a total hearing level of 25 dB or more above audiometric zero on the current audiogram (1904.10(a)). An STS in one ear and a 25 dB level in the other does not record. Pass raw audiogram values and the tool does the arithmetic — do not compute averages yourself. If the employee has had a prior recordable hearing loss, pass the REVISED baseline (b)(2)(i)). Age adjustment from Tables F-1/F-2 of 1910.95 appendix F applies to the STS test only, never to the 25 dB test (b)(3)). A retest within 30 days that does not confirm the STS defeats the case; one that confirms it starts a 7-day recording clock (b)(4)). A PLHCP determination of no work-relatedness ends it entirely (b)(6)). Reference and triage only — not legal advice.

ParametersJSON Schema

Name	Required	Description
`retest_date`	No	ISO 8601 date of a confirming retest. Used to compute the 7-calendar-day recording deadline (1904.10(b)(4)).
`current_left`	Yes	LEFT ear current audiogram.
`baseline_left`	Yes	LEFT ear baseline audiogram. If the employee has previously had a recordable hearing loss, use the REVISED baseline reflecting that case, not the original (1904.10(b)(2)(i)).
`current_right`	Yes	RIGHT ear current audiogram.
`baseline_right`	Yes	RIGHT ear baseline audiogram, or the revised baseline if a prior hearing loss was recorded.
`retest_confirmed_sts`	No	If retested, did the retest CONFIRM the recordable STS? A retest within 30 days that does not confirm it means the case need not be recorded.
`age_adjustment_db_left`	No	Optional dB age correction for the LEFT ear, derived from Tables F-1/F-2 of 29 CFR 1910.95 appendix F. Applies ONLY to the STS test — it may NOT be applied to the 25 dB total-hearing-level test (1904.10(b)(3)). The tool does not compute this; supply it from the tables or leave 0.
`age_adjustment_db_right`	No	Optional dB age correction for the RIGHT ear. Same rules as the left.
`retested_within_30_days`	No	Was the employee's hearing retested within 30 days of the first test? (1904.10(b)(4))
`plhcp_determined_not_work_related`	No	Has a PLHCP determined, applying 1904.5, that the hearing loss is not work-related or that occupational noise did not significantly aggravate it? If so the case need not be recorded (1904.10(b)(6)).

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context: the two tests must be met in the same ear, age adjustment applies only to the STS test, retest rules (30-day window, confirmation vs. non-confirmation), and the PLHCP determination ending the case. It also warns that the tool does arithmetic and the user must supply age adjustments. This rich disclosure goes well beyond the annotations and precisely explains the decision logic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long, every sentence carries unique regulatory detail. The main purpose is front-loaded, and the subsequent sentences each clarify a distinct condition or exception. The structure uses parentheses for references and enumerations, making it scannable. There is no redundancy or filler; the length is justified for the regulatory complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters, nested objects, and an output schema present, the description covers all essential behavioral aspects: the two decision tests, same-ear requirement, age adjustment scope, retest logic, PLHCP override, and usage constraints. It also includes a disclaimer about legal advice. The output schema handles return values, so that gap is not an issue. For a complex OSHA evaluation tool, this description is thoroughly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so a baseline of 3 applies. The description adds meaning beyond the schema by clarifying relationships: it explains the same-ear condition, that baseline values should be the revised baseline when applicable, and that age adjustments are for STS only. It instructs the agent to pass raw values and not precompute averages, and clarifies the interplay between retest flags and the PLHCP flag. This adds semantic depth that the schema alone does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb and resource: 'Compute whether an audiogram produces a recordable hearing loss.' It also specifies the regulatory basis (29 CFR 1904.10) and the two tests, making it unmistakable from sibling tools that handle other OSHA recordkeeping aspects. The purpose is specific, actionable, and distinguishes this tool from the broader osha_assess_recordability and similar siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context and instructions: 'Pass raw audiogram values and the tool does the arithmetic — do not compute averages yourself,' and explains when to pass a revised baseline. It also disclaims 'Reference and triage only — not legal advice.' However, it does not explicitly name sibling tools or state when NOT to use this tool (e.g., for work-relatedness determination, use osha_assess_work_relatedness). Since the domain is specific, the exclusion is implicit but not explicit, so a 4 is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_evaluate_restricted_workEvaluate Restricted Work or Job Transfer (29 CFR 1904.7(b)(4))A

Read-onlyIdempotent

Decide whether a work restriction or job transfer actually counts as restricted work — not every restriction does. Run this BEFORE passing 'restricted_work_or_transfer' as an outcome to osha_assess_recordability, because getting it wrong moves cases onto or off the 300 Log. The rules it applies: a restriction confined to the day of injury does not count (b)(4)(iii); reduced output while still doing all routine functions does not count (b)(4)(vi); a restriction that misses every routine function does not count (b)(4)(iv), where routine functions are activities performed at least once per week (b)(4)(ii); a partial shift does count (b)(4)(v); and a job transfer is recorded in the same column (b)(4)(ix)-(x)). Critically, when a vague recommendation such as 'light duty' cannot be clarified with the PLHCP, the case MUST be recorded as restricted work (b)(4)(vii)) — the regulation resolves that doubt toward recording. Reference and triage only — not legal advice.

ParametersJSON Schema

Name	Required	Description
`reduced_output_only`	No	Is the ONLY effect that the employee produces less while still performing all routine functions and working the full shift? That is not restricted work (1904.7(b)(4)(vi)).
`restriction_is_vague`	No	Is the recommendation vague — 'light duty', 'take it easy for a week' — rather than specific? (1904.7(b)(4)(vii))
`worked_partial_shift`	No	Did the employee work only part of a shift because of the injury or illness? A partial day counts as a day of restriction or transfer, except on the day of the injury (1904.7(b)(4)(v)).
`transferred_to_another_job`	No	Was the employee assigned to a job other than their regular job for part of the day? Transfers are recorded in the same 300-Log box as restricted work (1904.7(b)(4)(ix)-(x)).
`vague_restriction_clarified`	No	If the restriction was vague, was the PLHCP successfully asked whether the employee can do ALL routine functions AND work the FULL shift? If clarification could NOT be obtained, pass false — 1904.7(b)(4)(vii) then requires the case to be recorded as restricted work.
`restriction_applies_beyond_day_of_injury`	Yes	Does the restriction or transfer extend beyond the day the injury occurred or the illness began? A restriction imposed ONLY for that day is not recordable as restricted work (1904.7(b)(4)(iii)).
`keeps_from_routine_function_or_full_shift`	Yes	Does the restriction keep the employee from one or more ROUTINE functions, or from working the full workday they would otherwise have been scheduled? Routine functions are activities the employee regularly performs AT LEAST ONCE PER WEEK (1904.7(b)(4)(ii)). A restriction on something done less often than weekly is not a restriction on a routine function.

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat those. It does add valuable behavioral context beyond the annotations: the tool applies a decision tree based on regulation, and it emphasizes the doubt-resolution rule that vague recommendations default to recording. It also notes the tool is not legal advice, which is a helpful behavioral caveat. There is no contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but it packs a dense set of regulatory rules that are essential for correct usage. It front-loads the purpose and usage instruction ('Run this BEFORE...'), then lists the key rules in a structured sequence. While it could be slightly trimmed, the length is justified by the complexity of the regulatory domain. It is not tautological or redundant with the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool (7 parameters, complex decision rules, and an output schema), the description provides sufficient context: it explains the decision criteria, the critical vague-restriction rule, and the tool's place in the workflow. Since an output schema exists, the description need not describe return values. The only minor gap is that it does not explicitly state the ternary nature of the output (true/false/unknown), but the output schema presumably covers that. It is complete enough for an agent to understand when and how to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — every parameter has a detailed description including regulatory references (e.g., '1904.7(b)(4)(iii)' for restriction confined to day of injury). The description itself does not elaborate on individual parameters, but that is unnecessary given the schema's thoroughness. The description does add context about the overall decision logic, but it does not go beyond what the schema already explains for each parameter. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action: 'Decide whether a work restriction or job transfer actually counts as restricted work'. It immediately differentiates itself from siblings by mandating that it runs BEFORE passing 'restricted_work_or_transfer' to osha_assess_recordability, and it lists the exact regulatory references (29 CFR 1904.7(b)(4) subsections). This is a specific verb+resource with explicit sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is precisely defined: 'Run this BEFORE passing restricted_work_or_transfer as an outcome to osha_assess_recordability'. It also enumerates what does and does not count as restricted work, including the critical caveat about vague restrictions that must be recorded unless clarified. It further warns that it is 'Reference and triage only — not legal advice,' setting clear boundaries for its use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

osha_route_to_establishment_logRoute a Case to the Right Establishment Log (29 CFR 1904.30)A

Read-onlyIdempotent

Decide WHICH establishment's OSHA 300 Log a recordable case belongs on — the last question about an individual incident, and one multi-site employers routinely get backwards. Under 1904.30(b)(4) the case follows the PLACE, not the person: an injury occurring at one of the employer's establishments is recorded on THAT establishment's log even when the employee normally works elsewhere, while an injury away from all of them (a customer site, in transit, remote work) goes on the log of the establishment where the employee normally works. Also reports whether the destination needs its own log — required for establishments expected to operate a year or longer (1904.30(a)), optional for short-term sites which may share a combined log (b)(1) — and, when records are kept centrally, the 7-calendar-day transmission deadline and the two conditions central recordkeeping depends on (b)(2)). Reference and triage only — not legal advice.

ParametersJSON Schema

Name	Required	Description
`records_kept_centrally`	No	Are the establishment's records kept at headquarters or another central location? Permitted only on the two conditions in 1904.30(b)(2).
`date_information_received`	No	ISO 8601 date the employer received information that a recordable case occurred. Used with central recordkeeping to compute the 7-calendar-day transmission deadline (1904.30(b)(2)(i)).
`employee_was_telecommuting_from_home`	No	Was the employee working from home at the time? A home is NEVER a business establishment and needs no separate 300 Log (1904.46(3)) — the case goes on the log of the establishment the telecommuter is linked to under 1904.30(b)(3). Pass false for occurred_at_one_of_your_establishments in this case.
`occurred_at_one_of_your_establishments`	Yes	Did the injury or illness occur AT one of the employer's own establishments? True even if it is not the employee's usual site. False for a customer site, in transit, or working from home. An establishment is a single physical location where business is conducted (1904.46); for mobile work — construction, transportation, utilities — it is the office, terminal or station that supervises the activity or is the base for it.
`destination_expected_to_operate_a_year_or_longer`	No	Is the establishment whose log will carry the case expected to be in operation for a year or longer? If not, no separate log is required — its cases may go on a combined short-term log, optionally per division or geographic region (1904.30(a), (b)(1)).

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`value`	Yes
`cfr_cite`	Yes
`source_url`	Yes
`last_verified`	Yes

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description fully aligns with these. It goes beyond annotations by elaborating the regulatory framework and edge cases (e.g., telecommuting, mobile work, short-term establishments), providing transparency about the tool's decision-making behavior without contradiction. No side effects are implied, consistent with read-only nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While lengthy, the description is well-structured and information-dense. It front-loads the core purpose and then systematically explains the decision logic, referencing specific regulations and edge cases. Every sentence adds value, and the regulatory citations (1904.30(a), (b)(1)-(4), 1904.46) are precise. No redundancy or filler is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of OSHA regulations, the description is remarkably complete. It covers the main rule (place of injury), exceptions (telecommuting, mobile work), and ancillary considerations (short-term establishments, central recordkeeping deadlines). Since an output schema exists, the lack of explicit return-value description is acceptable. The description equips an agent to make the correct routing decision without ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with all 5 parameters described in detail. The description adds semantic depth by explaining the significance of each parameter (e.g., 'occurred_at_one_of_your_establishments' definition includes mobile work nuances, and 'employee_was_telecommuting_from_home' clarifies that a home is never an establishment). This exceeds the schema's basic descriptions and provides the rationale for parameter values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to decide which establishment's OSHA 300 Log a recordable case belongs on. It uses a specific verb ('Decide') and a specific resource ('establishment's OSHA 300 Log'), and it distinguishes itself from sibling tools like check_recordkeeping_obligation and determine_recording_employer by focusing on the final routing decision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly positions this as 'the last question about an individual incident,' making clear it is used after other recordability steps. It also provides detailed regulatory context (1904.30(b)(4)) and explains the decision logic, effectively guiding when to use this tool versus alternatives. The 'last question' phrasing implies it's the final step in a sequence, which is sufficient for routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesv0.1.0Aug 23, 2026
- First observedosha_assess_new_case
- First observedosha_assess_recordability
- First observedosha_assess_work_relatedness
- First observedosha_check_privacy_case
- First observedosha_check_recordkeeping_obligation
- First observedosha_check_severe_injury_reporting
- First observedosha_classify_300_log_entry
- First observedosha_determine_recording_employer
- First observedosha_evaluate_hearing_loss
- First observedosha_evaluate_restricted_work
- First observedosha_route_to_establishment_log

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-08-23 00:41 across 11 tools

Disambiguation4/5

Each tool maps to a distinct, named regulatory decision point in the Part 1904 pipeline, and the cross-references ('Run this BEFORE...') make the flow clear. However, there is residual ambiguity risk: 'assess' tools (work_relatedness, new_case) are near-synonyms for 'evaluate' tools (restricted_work, hearing_loss), and an agent could initially hesitate between osha_assess_recordability and its sub-tools despite the explicit guidance. The two 'check' obligation gates are also conceptually parallel, though the domain separation is real.

Naming Consistency4/5

All tool names follow a uniform snake_case `osha_<verb>_<object>` pattern, and the object nouns are clear and meaningful. However, the verb choices — assess, evaluate, check, determine, classify, route — are largely interchangeable near-synonyms that follow a subtle internal logic (check=obligation gates, assess=decision nodes, evaluate=sub-computations) that is not self-evident from the names alone. The pattern is consistent but the verb selection is slightly muddier than a strict verb_noun taxonomy.

Tool Count5/5

With 11 tools, the server is well within the ideal 3-15 range for a domain as broad as Part 1904 recordkeeping. Each tool earns its place by covering a genuine regulatory gate, and the count feels appropriately granular — not so few that decisions are conflated, not so many that the surface becomes unmanageable. The split of the 1904.4 decision tree into discrete tools is justified by the complexity of each step.

Completeness4/5

The end-to-end recordkeeping lifecycle is thoroughly covered: threshold obligation → employer attribution → work-relatedness → new case → recordability → classification → privacy → establishment routing, plus severe-injury reporting. Notable gaps include the 300A annual summary and posting requirement, employee/authorized-representative access to records, and corrections to already-filed logs, but these are administrative follow-ons rather than core decision dead-ends. The coverage of 1904.8-1904.12 specific-case criteria is also mostly folded into the broader tools.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Sophon Consulting A
consulting.sophon
Read-only, deterministic AI triage and readiness tools implementing Sophon's published rubrics.
AI & Machine Learning Testing & QA Tools
22
DenialPath A
io.github.maxbeech
Deterministic CMS NCCI/MUE claim scrubbing and CARC/RARC denial explanations, cited to source.
Biology & Medicine Legal & Compliance
62
ARBITER C
fyi.grip
Deterministic contextual decision arbitration and action routing for autonomous software. Takes current state, context, or intent plus caller-supplied candidate actions, state transitions, routes, refusals, escalations, tools, or models and returns a deterministic ordered candidate field. Also provides persistent machine representations for memory, retrieval, indexing, and downstream coherence measurement.
Agent Orchestration Autonomous Agents Knowledge & Memory
21
VeteranHQ A
app.veteranhq
VA disability rating and compensation calculations, condition lookup, and 38 CFR authority search
Government Data Legal & Compliance
111

Related MCP Servers

intake_triage_mcp
Legal & Compliance CRM
granolacowboy
A
license
Not graded
quality
B
maintenance
A deterministic MCP server for legal intake triage that provides practice-area lookup, conflict screening, matter validation, follow-up drafting, and triage logging with a hard conflicts gate.
Updated 7 days ago (2026-09-06 07:33 UTC)
Apache 2.0
Quellgeist
Monitoring Observability
Rajeev-Shyam
A
license
A
quality
A
maintenance
First-line incident triage you can trust: ranked root-cause hypotheses where every claim cites a real evidence handle — and the agent abstains rather than guess.
Updated a month ago (2026-08-18 00:15 UTC)
1
1
MIT
mcp-osha
Government Data Legal & Compliance Search
pipeworx-io
A
license
Not graded
quality
B
maintenance
MCP server for US workplace-safety standards (OSHA 29 CFR parts 1900–1990). Enables querying safety regulations via natural language through the Pipeworx gateway.
Updated 18 days ago (2026-08-26 17:30 UTC)
13 npm
MIT
triage-desk-mcp
Customer Support AI & Machine Learning Monitoring
babyquad
F
license
Not graded
quality
C
maintenance
Provides policy-grounded triage of Trust & Safety reports via MCP, with tools for triage, policy search, and operational telemetry.
Updated a month ago (2026-08-08 05:49 UTC)
-

OSHA Recordkeeping MCP — 29 CFR Part 1904

Using it

Why this tool exists

Division of labor: LLM narrates, tool decides

The anchor tool: osha_assess_recordability

Protocol surface (all three MCP primitives)

Provenance & enforced decay

The incident-triage chain (shipped)

Scope: Part 1904, and nothing else

Distribution: a server and a Skill

The server — three entry points, one engine

Rate limiting

What the tools receive

Host and Origin validation

The Skill

Layout

Continuous integration

Change control & versioning

Develop

Evaluations

Disclaimer

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

The anchor tool: `osha_assess_recordability`