de en es ja ko ru zh

osha-recordkeeping-mcp

Name: osha-recordkeeping-mcp
Author: srhtdmrkl

by srhtdmrkl

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

OSHA Recordkeeping MCP — 29 CFR Part 1904

Ein deterministischer Model Context Protocol-Server, der einem Sicherheitsmanager hilft, die Frage zu beantworten, die sich bei jeder Verletzung stellt: ist das OSHA-aufzeichnungspflichtig?

Elf Tools begleiten einen Vorfall von jemand wurde verletzt bis zu einem korrekten Log-Eintrag, wobei jedes eine zitierte Entscheidung liefert, statt einer Erinnerung des Modells an die Regel. MIT-lizenziert und kostenlos nutzbar.

Nur Referenz und Triage — keine Rechtsberatung und keine medizinische Feststellung. Jede Entscheidung trägt ihr CFR-Zitat und das Datum, an dem die zugrunde liegenden Daten zuletzt gegen eCFR verifiziert wurden, sodass die Begründung nachvollziehbar statt behauptet ist.

Verwendung

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

Fügen Sie es dann zur claude_desktop_config.json von Claude Desktop hinzu:

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

Verwenden Sie einen absoluten Pfad zu Ihrer node-Binärdatei, wenn Sie nvm verwenden — Claude Desktop lädt Ihr Shell-Profil nicht, daher wird ein bloßes node nicht aufgelöst.

Das begleitende Skill enthält das Verfahren: wann die Kette greift, was vor dem Aufruf zu klären ist und was die Tools nicht entscheiden können.

Related MCP server: secops-agent-triage

Warum dieses Tool existiert

Die Bewertung der Aufzeichnungspflicht von Arbeitsunfällen nach 29 CFR Part 1904 erfolgt bei jedem Vorfall. Falsche Entscheidungen bergen direkte Compliance-Risiken: Über-Aufzeichnung bläht die Total Recordable Incident Rate (TRIR) künstlich auf, während Unter-Aufzeichnung OSHA-Zitate nach 29 CFR 1904.4 nach sich zieht.

Die Aufzeichnungspflicht nach Part 1904 bewertet mehrere unabhängige Auslöser: allgemeine Kriterien (Todesfall, Ausfalltage, Arbeitsplatzbeschränkung, Bewusstseinsverlust, PLHCP-Diagnosen nach 1904.7), spezifische Fallregeln (Nadelstiche, medizinische Entfernung, Hörverlust, TB nach 1904.8–1904.12) und Behandlungsklassifikation. Für die Behandlung definiert 1904.7(b)(5)(ii) eine geschlossene, 14 Punkte umfassende enumerierte Liste von Erste-Hilfe-Behandlungen. Die Implementierung dieser geschlossenen regulatorischen Regeln in typisierten Tools ersetzt die LLM-Interpolation über regulatorischen Text durch reproduzierbare Nachschlagelogik.

Arbeitsteilung: LLM erzählt, Tool entscheidet

Das aufrufende Modell tut, was es gut kann — eine unübersichtliche Vorfallserzählung lesen und auf kanonische Codes abbilden (Behandlungsarten, Ergebnisse). Das Tool tut, was ein Modell für eine rechtliche Entscheidung nicht tun darf — die geschlossene Liste deterministisch anwenden und eine zitierte Antwort zurückgeben. Das Tool akzeptiert niemals Freitext-Behandlungsbeschreibungen; es akzeptiert ein kontrolliertes Vokabular, damit die Entscheidung reproduzierbar ist.

Das Anker-Tool: `osha_assess_recordability`

Eingabe. Das Modell bildet die Erzählung auf diese ab; es übergibt niemals Freitext.

Feld	Bedeutung
`work_related`	1904.5 — von `osha_assess_work_relatedness` übernehmen, hier nicht selbst beurteilen
`new_case`	1904.6 — von `osha_assess_new_case` übernehmen
`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-Auslöser — Nadelstich, medizinische Entfernung, Hörverlust, TB, blutübertragene Exposition mit Diagnose
`plhcp_recommendations_not_followed`	Die drei Stellen, an denen eine Empfehlung bindet, auch wenn der Mitarbeiter sie ignoriert hat (1904.7(b)(3)(ii), (b)(4)(viii), (b)(5)(v))
`medical_removal_was_voluntary_and_early`	Schutz für 1904.9(b)(3) — jemanden frühzeitig herauszuziehen ist nicht aufzeichnungspflichtig
`tuberculosis_test_was_pre_employment`	Schutz für 1904.11(b)(1) — ein positiver Einstellungs-Check ist nicht beruflich
`treatments`	Kontrollierte Codes. Erste-Hilfe-Codes stammen aus der geschlossenen Liste; zwei Codes sind weder Erste Hilfe noch medizinische Behandlung (1904.7(b)(5)(i))

Die ersten drei Arrays sind bewusst erforderlich. Ein Standardwert von [] kann nicht von „Ich habe geprüft und es gab keine" unterschieden werden, daher würde ein Standardwert eine unter-spezifizierte Erzählung zu einem selbstbewussten, zitierten falsch-negativen Ergebnis führen — der Unter-Aufzeichnungsrichtung, die ein Zitat nach sich zieht.

Ausgabe. Ein RuleRecord, dessen Wert recordable, basis, triggering_factors (jeweils mit eigenem Unterabschnitts-Zitat), severe_injury_reporting_note wenn 1904.39 relevant sein könnte, log_entry_notes für Konsequenzen, die ein Kriterium dem Log selbst auferlegt, und under_specified wenn überhaupt nichts behauptet wurde. Die Registrierungsebene fügt determination_final und clarification_required hinzu — siehe Elicitation unten.

Entscheidungslogik (deterministisch) — der 1904.4(b)(2)-Entscheidungsbaum in Reihenfolge:

Wenn work_related falsch ist → nicht aufzeichnungspflichtig (1904.5).
Wenn new_case falsch ist → kein neuer Eintrag, aber den bestehenden aktualisieren, wenn sich Tageszahlen oder Ergebnis geändert haben (1904.6). Der Baum leitet hierher; er stoppt nicht einfach.
Sonst, wenn ein specific_case_criteria vorhanden ist → aufzeichnungspflichtig nach 1904.8-1904.12, ohne die Erste-Hilfe-Liste überhaupt zu konsultieren.
Sonst, wenn ein outcome vorhanden ist → aufzeichnungspflichtig (allgemeine Aufzeichnungskriterien, 1904.7(b)(1)).
Sonst, wenn eine significant_diagnosis vorhanden ist → aufzeichnungspflichtig auch wenn nur Erste Hilfe geleistet wurde (1904.7(b)(7)).
Sonst, wenn eine treatment nicht in der geschlossenen Erste-Hilfe-Liste ist → aufzeichnungspflichtig (medizinische Behandlung über Erste Hilfe hinaus, 1904.7(b)(5)(i)).
Sonst → nicht aufzeichnungspflichtig (nur Erste Hilfe und kein spezifisches Fallkriterium).

Schritt 3 existiert, weil 1904.4(a)(3) eine Disjunktion ist: 1904.7 oder die spezifischen Fälle von 1904.8-1904.12. Ohne sie kam ein kontaminierter Nadelstich, der mit Reinigung und einem Pflaster behandelt wurde, als „nicht aufzeichnungspflichtig" zurück — mit angehängtem Zitat — während das Datenschutz-Tool desselben Servers ihn korrekt als Datenschutzfall bezeichnete. Aufzeichnungskriterien, die die Erste-Hilfe-Liste nie konsultieren, müssen vor ihr geprüft werden, nicht nach ihr.

Protokolloberfläche (alle drei MCP-Primitive)

Dieser Server nutzt das volle Protokoll, nicht nur Tools:

Tools — die elf Entscheidungen, die unter Die Incident-Triage-Kette unten aufgeführt sind. Jedes deklariert ein outputSchema und gibt typisierte structuredContent zurück, keinen JSON-String, und jedes ist mit readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false annotiert — sicher, wiederholbar, reine Nachschlageoperationen.
Resources — alle fünfzehn Datensätze sind direkt exponiert, sodass ein Client die Referenzdaten als Kontext laden kann, statt sie nur über einen Tool-Aufruf zu erreichen. Das Datenmodell ist das Produkt; Resources machen es sichtbar. URIs sind osha://data/<id>, wobei <id> der Schlüssel in src/datasets.ts ist — z. B. osha://data/first-aid-treatments, osha://data/partially-exempt-industries, osha://data/privacy-cases.
Prompt — triage_incident führt einen Vorfall als einen einzigen benutzeraufgerufenen Workflow durch die gesamte Kette: Umfang → aufzeichnungspflichtiger Arbeitgeber → Arbeitsbezug → neuer Fall → eingeschränkte Arbeit → Hörverlust → Aufzeichnungspflicht → Meldefrist → 300-Log-Spalte → Datenschutzfall → Betriebsstätte.

Elicitation — osha_assess_recordability löst den einen Randfall, den es nicht erraten darf: OTC- vs. verschreibungspflichtige Medikamentenstärke. Nicht-verschreibungspflichtige Stärke ist Erste Hilfe; verschreibungspflichtige Stärke ist medizinische Behandlung und aufzeichnungspflichtig. Wenn die Erzählung schweigt, übergibt das Modell medication_unspecified_strength und die Stärke wird durch Nachfragen bei einem Menschen aufgelöst — niemals durch das Tool.

Zweistufige Auflösung. Elicitation ist eine optionale MCP-Fähigkeit, daher prüft der Server getClientCapabilities() und wählt seinen Kanal:

Client wirbt `elicitation`	Kanal	Ergebnis
Ja	Server fragt den Benutzer direkt	In einem Tool-Aufruf aufgelöst
Nein	Gibt `determination_final: false` + `clarification_required` zurück	Modell fragt im Chat, ruft dann mit dem aufgelösten Code erneut auf

In beiden Fällen erreicht die Frage einen Menschen und das Tool rät nie. Das vorläufige Ergebnis bleibt konservativ — recordable: true, Basis als ausstehende Bestätigung markiert — und clarification_required trägt die Frage, den CFR-Grund und den genauen Behandlungscode, der für jede Antwort zurückzusenden ist.

In welcher Stufe ein bestimmter Client landet, sollte man prüfen statt annehmen. Hier verifiziert: Der Chat-Client von Claude Desktop wirbt keine elicitation-Fähigkeit, ebenso wenig MCP Inspector 0.15.0 oder 1.0.0. Agentische Clients können sich unterscheiden, und ein Client, der den Benutzer über seinen eigenen Mechanismus fragt, sieht von außen identisch aus. Der Server protokolliert elicitation=supported|NOT supported auf stderr bei Verbindung — starten Sie ihn unter einem beliebigen Client und lesen Sie diese Zeile.

Herkunft & erzwungener Verfall

RuleRecord<T> (siehe src/types.ts) trägt regulatorische Regeln: cfr_cite, source_url, last_verified und, wo eCFR sie liefert, amendment_history und editorial_note. Es gibt kein effective_date-Feld; Datensätze tragen aktuellen eCFR-Text, und last_verified gibt das Datum der regulatorischen Verifizierung an.

Der Verfall wird über scripts/check-decay.ts erzwungen, das den Build fehlschlagen lässt, wenn last_verified eines Datensatzes seine Verfallsschwelle überschreitet. Es läuft bei Push und nach einem wöchentlichen CI-Zeitplan, validiert die source_url-Ziele der Unterabschnitte und prüft auf eCFR-editorial_note-Einträge.

Die Incident-Triage-Kette (ausgeliefert)

Elf deterministische Tools, die einen Vorfall von „jemand wurde verletzt" bis zu einem korrekten Log-Eintrag begleiten:

osha_check_recordkeeping_obligation (1904.1, 1904.2) — die Frage, die jede andere Feststellung voraussetzt: Muss dieser Arbeitgeber überhaupt Aufzeichnungen führen? Die Größenausnahme wird über das gesamte Unternehmen anhand der Spitzenbeschäftigung im letzten Kalenderjahr gemessen – nicht als Durchschnitt, nicht für einen Standort. Die Branchenausnahme bezieht sich auf die Betriebsstätte, und das Tool löst sie anhand der geschlossenen 82-Code-Liste in Anhang A auf, wenn eine NAICS-Code angegeben wird. Beide sind teilweise: 1904.39 Meldepflicht für schwere Verletzungen überlebt beide, was die Schlussfolgerung ist, die ein ausgenommener Arbeitgeber gefährlich falsch versteht.
osha_determine_recording_employer (1904.31) — eine Schwellenfrage, kein Schritt: Wenn die verletzte Person nicht auf der Lohnliste steht, ist es dann überhaupt der Fall dieses Arbeitgebers? Die tägliche Aufsicht entscheidet, nicht der Gehaltsscheck. Ein Zeitarbeiter auf der Lohnliste einer Agentur, dessen Arbeit Sie täglich leiten, ist von Ihnen aufzuzeichnen; derselbe Zeitarbeiter unter Aufsicht der Agentur nicht. Selbstständige fallen vollständig aus dem OSH Act heraus, und Eigentümer oder Partner einer Einzelfirma sind für die Aufzeichnung keine Arbeitnehmer. (b)(4) verlangt, dass der Fall genau einmal aufgezeichnet wird – niemals in beiden Protokollen.
osha_assess_work_relatedness (1904.5) — das Tor, auf dem alles andere ruht, und bisher das einzige rechtliche Urteil, das dieses Projekt dem Modell überließ. 1904.5(a) vermutet Arbeitsbezogenheit für alles, was in der Arbeitsumgebung entsteht; 1904.5(b)(2) ist eine geschlossene Liste von neun Ausnahmen, die sie widerlegen können. Das Urteil ist bewusst dreiwertig – work_related, not_work_related oder requires_judgment –, weil 1904.5 Pfade enthält, die die Verordnung selbst dem Arbeitgeber zuweist: unklare Herkunft (1904.5(b)(3)), Reisestatus (b)(6), Arbeiten zu Hause (b)(7) und die „ausschließlich"-Feststellung, von der jede Ausnahme abhängt. Diese in einen booleschen Wert zu zwingen, wäre, als würde das Tool bei der umstrittensten Entscheidung in Teil 1904 raten. Es klärt auch Fälle, die das Gedächtnis falsch behält. Ein Kraftfahrzeugunfall beim Pendeln auf dem Firmengelände ist unter (b)(2)(vii) ausgenommen; ein Sturz auf demselben Gelände ist von keiner Ausnahme abgedeckt und bleibt arbeitsbezogen. Und psychische Erkrankungen kehren die übliche Richtung um – nicht arbeitsbezogen, es sei denn, der Arbeitnehmer legt freiwillig eine PLHCP-Stellungnahme vor (b)(2)(ix).
osha_assess_new_case (1904.6) — ein neuer Eintrag im 300-Log oder eine Aktualisierung eines bereits vorhandenen? Die zweite Bedingung der Konjunktion in 1904.4(a). Es trennt die beiden Wiederholungsfälle, die die Verordnung bewusst unterscheidet: Ein Vorfall, der durch eine Arbeitsplatzexposition verursacht wird, ist ein neuer Fall (b)(2) – berufsbedingtes Asthma, das am Fließband ausgelöst wird –, während eine chronische Erkrankung, deren Symptome ohne Exposition wiederkehren, nur einmal aufgezeichnet wird (b)(1). Beachten Sie, dass (b)(1) keine geschlossene Liste ist: Die Verordnung sagt, „Beispiele können umfassen" Krebs, Asbestose, Byssinose und Silikose, daher fragt das Tool nach der Art der Erkrankung, anstatt Krankheitsnamen abzugleichen. Es ist auch das einzige Tool im Server, das sich einer externen Autorität unterordnet. Unter (b)(3) muss ein Arbeitgeber keinen PLHCP konsultieren, aber wenn er einen konsultiert hat, muss er der Empfehlung folgen – eine PLHCP-Stellungnahme überschreibt also die Regel-Logik vollständig, und widersprüchliche Stellungnahmen geben requires_judgment zurück, weil deren Abwägung ausdrücklich Aufgabe des Arbeitgebers ist.
osha_evaluate_restricted_work (1904.7(b)(4)) — zählt die Einschränkung tatsächlich? Nicht jede tut das, und beide Fehler verschieben Fälle auf das Protokoll oder davon weg. Eine Einschränkung, die auf den Tag der Verletzung beschränkt ist, zählt nicht (b)(4)(iii); reduzierte Leistung, während weiterhin alle Routinefunktionen ausgeführt werden, zählt nicht (b)(4)(vi); „Routinefunktionen" bedeutet Tätigkeiten, die mindestens einmal pro Woche ausgeführt werden (b)(4)(ii). Eine Teilschicht zählt (b)(4)(v)), und Versetzungen teilen die Einschränkungsspalte (b)(4)(x)). Interessant ist (b)(4)(vii): Wenn eine vage Empfehlung wie „leichte Arbeit" nicht mit dem PLHCP geklärt werden kann, muss der Fall als eingeschränkte Arbeit aufgezeichnet werden. Das ist die Verordnung, die ihre eigenen Zweifel zugunsten der Aufzeichnung auflöst – und die einzige Standard-zu-Aufzeichnen-Regel in Teil 1904.
osha_evaluate_hearing_loss (1904.10) — das einzige Aufzeichnungskriterium in Teil 1904, das reine Arithmetik ist, und das einzige Tool hier, das berechnet statt nachschlägt. Zwei Tests müssen beide im selben Ohr erfüllt sein: eine Standard-Schwellenwertverschiebung von 10 dB gegenüber der Basislinie und ein Gesamthörpegel von 25 dB oder mehr über dem audiometrischen Nullpunkt, jeweils gemittelt bei 2000, 3000 und 4000 Hz. Eine STS in einem Ohr und ein 25-dB-Pegel im anderen führt nicht zur Aufzeichnung. Die Altersanpassung gilt nur für den Verschiebungstest, niemals für den 25-dB-Test.
osha_assess_recordability (1904.4) — ist es aufzeichnungspflichtig? (der Anker, oben)
osha_check_severe_injury_reporting (1904.39) — muss es OSHA gemeldet werden, und bis wann? Gibt den tatsächlichen Fristzeitstempel zurück (8 Stunden bei einem Todesfall, 24 bei Krankenhausaufenthalt / Amputation / Verlust eines Auges), berechnet ab dem Zeitpunkt, an dem der Arbeitgeber davon erfahren hat, prüft das Berechtigungsfenster ab dem Vorfall und kennzeichnet, ob die Frist bereits überschritten ist.
osha_classify_300_log_entry (1904.29) — welche Ergebnisspalte (G/H/I/J) im 300-Log gemäß der Regel des schwerwiegendsten Ergebnisses, die Spalte für Verletzungs-/Krankheitsart und Tageszählungen, die bei 180 gedeckelt sind.
osha_check_privacy_case (1904.29(b)(6)-(9)) — darf der Name des Arbeitnehmers überhaupt auf das Protokoll? Eine zweite geschlossene Liste, und in beiden Richtungen geschlossen: (b)(7) zählt die sechs Fälle mit Datenschutzbedenken auf, und (b)(8) verbietet, etwas anderes als solchen zu behandeln – ein Arbeitgeber kann sie also weder aus Mitgefühl erweitern noch ignorieren. Gibt den wörtlichen Protokolleintrag ("privacy case") sowie die folgenden Pflichten zurück: die separate vertrauliche Liste ((b)(6)), Ermessen bei der Beschreibung des Falls, wenn allein die Erzählung den Arbeitnehmer identifizieren könnte ((b)(9)), und Schwärzung, wenn Aufzeichnungen an jemand anderen als einen Regierungsvertreter gehen ((b)(10)).
osha_route_to_establishment_log (1904.30) — welches 300-Log der Betriebsstätte, die letzte Frage zu einem einzelnen Vorfall. Die Regel läuft der Intuition zuwider: Ein Fall folgt dem Ort, nicht der Person. Jemand, der verletzt wird, während er eine Schicht in einem anderen Werk des Arbeitgebers übernimmt, wird im Protokoll dieses Werks aufgezeichnet, was die Zahl verschiebt, die dessen Standort-TRIR antreibt. Eine Verletzung außerhalb jeder Betriebsstätte – beim Kunden, unterwegs, remote – geht in das Protokoll des Standorts, an dem der Arbeitnehmer normalerweise arbeitet.

Umfang: Teil 1904 und sonst nichts

Alles hier beantwortet eine Frage – jemand wurde verletzt; was verlangt OSHA von mir, aufzuzeichnen und zu melden? Das ist 29 CFR Teil 1904 von Anfang bis Ende, und die elf Tools oben sind die Feststellungen, die er erzwingt.

Verteilung: ein Server und eine Skill

Zwei Artefakte, weil sie unterschiedliche Fragen beantworten. Der Server entscheidet; die Skill weiß, wann sie ihn fragen muss.

Der Server – drei Einstiegspunkte, eine Engine

Einstiegspunkt	Transport	Für
`dist/index.js`	stdio	Claude Desktop, lokale Entwicklung
`dist/http.js`	Streamable HTTP	ein Container oder Node-Host
`src/worker.ts`	Streamable HTTP	Cloudflare Workers

Alle drei rufen dieselbe createServer() über dieselben elf Tools und fünfzehn Datensätze auf – nichts in src/tools/ weiß, welcher läuft. Diese Portabilität kam aus zwei früheren Entscheidungen und nicht aus Portierungsaufwand: Die Feststellungen sind reine Funktionen, und datasets.ts ist der einzige Kontaktpunkt mit dem JSON.

Jede Variante ist zustandslos – ein frischer Server pro Anfrage, keine Sitzungs-IDs, nichts wird zwischen Aufrufen behalten, weil jedes Tool eine reine Nachschlageoperation über gebündelte Daten ist. /health meldet das Alter jedes Datensatzes gegen seine Verfallsschwelle und gibt 503 zurück, wenn einer veraltet ist, sodass eine gehostete Bereitstellung nach derselben Regel überwacht wird wie der Build.

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 ist der einzige Check, der die Tools unter workerd ausführt. Die anderen beiden Smokes laufen auf Node und können strukturell nicht sehen, wie ein Node-Built-in in einen Codepfad eindringt – genau das, was ein Deployment zuerst aufdecken würde. nodejs_compat ist in wrangler.toml bewusst AUS, damit dieser Fehler in der Entwicklung laut ist und nicht still.

Der Worker akzeptiert nur POST. Ein zustandsloser Server initiiert keine Nachrichten, daher trägt der GET-SSE-Stream nichts und würde für immer offen bleiben; workerd bricht eine Anfrage ab, deren Antwort nie abgeschlossen wird. 405 mit Allow: POST ist die Art des Protokolls zu sagen, dass es keinen Server-zu-Client-Stream gibt.

Keine Authentifizierung, absichtlich. Der Server stellt veröffentlichten Regulierungstext bereit, speichert nichts und hat keine Nebenwirkungen, daher gehört Zugriffskontrolle davor – Cloudflare Access oder eine OAuth-Schicht – statt halb implementiert darin.

Ratenbegrenzung

Ratenbegrenzung ist die Ausnahme, und sie lebt im Worker statt davor. Die Bereitstellung ist auf workers.dev, das keine Zone im Konto ist, daher hat eine WAF-Ratenbegrenzungsregel nichts, woran sie sich festhalten kann. Deklariert als [[ratelimits]]-Bindung in wrangler.toml, was auch bedeutet, dass sie überprüft, versioniert und mit dem Deployment reist, statt in einem Dashboard zu leben, das niemand diffed.

300 Anfragen pro Minute pro Client-IP. Bewusst großzügig: Der Begrenzer schlüsselt nach IP auf, und ein Sicherheitsteam hinter einem gemeinsamen Corporate-NAT teilt sich einen einzigen Schlüssel. Eine Triage-Kette umfasst etwa 15 Anfragen, sodass mehrere Personen, die gleichzeitig arbeiten, legitimerweise 150/Minute überschreiten. Dies ist darauf ausgelegt, ein Modell abzuschneiden, das bei einem Fehler schleift – der Fehler, der eine gehostete Bereitstellung tatsächlich bedroht –, nicht um normale Nutzung zu messen. Über dem Limit gibt es 429 mit Retry-After zurück.

/health liegt über dem Check, sodass ein Uptime-Monitor, der nach Zeitplan pollt, niemals das Budget erschöpfen kann. Die Durchsetzung erfolgt pro Rechenzentrum und nicht global koordiniert, also ist es eine Abschneidung und keine exakte Quote.

Was die Tools empfangen

Der Server ruft nichts ab und speichert nichts. Aber Argumente fließen trotzdem hinein, und sie beschreiben einen realen Vorfall, daher ist „keine Benutzerdaten" eine Behauptung über Speicherung, die nichts über den Transport sagt. Die Unterscheidung ist wert, klar ausgesprochen zu werden, weil sie die ist, die ein EHS-Team bewerten muss.

Keine Eingabe ist ein Identifikator. Es gibt kein Feld in den Schemas für einen Namen, eine Mitarbeiternummer, ein Geburtsdatum, eine Adresse oder eine Freitext-Erzählung – jede Eingabe ist ein Attribut des Falls (work_related, days_away_from_work, treatments), und die Feststellung braucht nichts anderes. Das ist eine Eigenschaft der Schemas, keine Richtlinie: Es gibt kein Feld, in das ein Name eingetragen werden könnte. Die Skill weist das Modell auch an, keine Identität in einen Aufruf zu tragen, sodass die Einschränkung an beiden Enden gilt – siehe Fakten übergeben, niemals Identitäten.

Einige Attribute sind trotzdem sensibel. osha_check_privacy_case nimmt genau die Kategorien, die 1904.29(b)(7) aufzählt – sexual_assault, mental_illness, hiv_hepatitis_or_tuberculosis, contaminated_needlestick_or_sharps. Die Verordnung hebt genau diese hervor, weil sie die sind, die nicht auf einem Protokoll erscheinen dürfen, das ein Kollege lesen kann. Nur-Attribute ist auch nicht dasselbe wie anonym: Ein Artcode plus ein Vorfallsdatum an einer Betriebsstätte mit neun Personen kann jemanden identifizieren, der dort arbeitet.

Wo das landet, hängt vom Transport ab, und nur vom Transport:

Einstiegspunkt	Wohin Argumente gehen
stdio	bleibt auf der Maschine, die den Server ausführt; der KI-Host sieht es trotzdem
node HTTP / Worker	überquert das Netzwerk zu dem, der diese Bereitstellung betreibt

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- und Origin-Validierung

Authentifizierung betrifft wer fragen darf. Host-Validierung betrifft einen Browser, der dazu gebracht wird, im Namen eines anderen zu fragen, was kein vorgelagertes Gateway nachrüsten kann — daher wird dieser Teil in src/httpGuard.ts behandelt und gilt für beide HTTP-Einstiegspunkte.

Der Angriff, den sie schließt, ist DNS-Rebinding: Eine Angreifer-Domain löst erneut zu 127.0.0.1 auf, der Browser behandelt die Anfrage als gleichoriginär und sendet sie ohne Preflight, und ein lokal laufender MCP-Server antwortet. Der Host-Header ist es, der sie immer noch verrät — er trägt die Domain des Angreifers — daher ist eine exakte Host-Allowlist die Prüfung, die funktioniert.

Variable	Node (`dist/http.js`)	Worker
`HOST`	Bindungsadresse, Standard `0.0.0.0`	—
`MCP_ALLOWED_HOSTS`	Standard `localhost:$PORT`, `127.0.0.1:$PORT`, `[::1]:$PORT`	nicht gesetzt = uneingeschränkt
`MCP_ALLOWED_ORIGINS`	nicht gesetzt = uneingeschränkt	nicht gesetzt = uneingeschränkt

Beide akzeptieren eine kommagetrennte Liste; * deaktiviert die Prüfung, wenn ein vorgelagertes Gateway die Entscheidung besitzt. Origin wird nur geprüft, wenn der Header vorhanden ist, da Nicht-Browser-MCP-Clients keinen senden. /health liegt außerhalb der Allowlist — ein Uptime-Monitor ist nicht das Bedrohungsmodell.

Der Node-Einstiegspunkt standardmäßig nur auf Loopback. Eine Container- oder Reverse-Proxy-Bereitstellung wird unter einem anderen Namen erreicht und muss MCP_ALLOWED_HOSTS setzen; sie schlägt mit einem 403 fehl, der den gesehenen Header benennt, was eine Fünf-Sekunden-Korrektur ist. Das Gegenteil als Standard wäre ein Loch, das niemand bemerkt. Beachten Sie, dass die Bindungsadresse nicht der Schutz ist — die Bindung an 0.0.0.0 bleibt der Standard, damit Container funktionieren, und die Allowlist macht das sicher.

Abgelehnte Anfragen erhalten 403 mit einem JSON-RPC--32000-Fehler. Übermäßig große Bodies (>1 MB) erhalten 413, fehlerhaftes JSON erhält 400 — Client-Fehler werden nicht als Vorfälle protokolliert.

Die Skill

skills/osha-incident-triage/ trägt die Vorgehensweise: wann die Kette gilt, was vor dem Aufruf festzustellen ist, wie eine Bestimmung zu präsentieren ist und was die Werkzeuge nicht entscheiden können. Sie enthält Prozessanleitung für Incident-Triage und trägt keine regulatorische Logik direkt.

Aufbau

Die Bestimmungslogik ist rein und testbar; der Server ist Verdrahtung darum herum.

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

Ein Werkzeug hinzuzufügen bedeutet eine Datei in src/tools/ (die Regel), eine in src/registrations/tools/ (wie es beschrieben und zusammengefasst wird) und eine Zeile im Fass. Das register-Präfix hält diese Dateinamen in einer Editor-Tab-Leiste von ihren src/tools/-Gegenstücken unterscheidbar.

Zwei Invarianten, die es wert sind, beibehalten zu werden: Provenienz wird nur von ruleRecord() zusammengestellt, und Ressourcen werden aus derselben DATASETS-Tabelle generiert, aus der die Werkzeuge laden, sodass ein Datensatz nicht unter einem Pfad veröffentlicht werden kann, den kein Werkzeug liest.

Kontinuierliche Integration

.github/workflows/ci.yml führt Typprüfung, Build, Unit-Tests und Smoke-Suiten auf Node 20 und 22 aus.

Die Decay-Prüfung und npm audit laufen beide auf denselben Triggern wie der Rest der CI — Push, Pull-Request und ein wöchentlicher Zeitplan — als separate Jobs gehalten, sodass jeder Fehler für sich erkennbar ist, nicht als ein rotes X unter mehreren. npm audit blockiert den Build bei schwerwiegenden Produktions-Schwachstellenhinweisen; Dev-Abhängigkeitshinweise werden gemeldet, nicht blockierend. Der wöchentliche Zeitplan fängt einen Hinweis ab, der gegen eine bereits auf main befindliche Abhängigkeitsversion veröffentlicht wurde, wo sonst nichts einen erneuten Check auslösen würde.

tsconfig.json schließt test/ aus, sodass tsc --noEmit nur src/ prüft und ts-jest Testdateien während npm test typprüft.

Änderungskontrolle & Versionierung

CHANGELOG.md verfolgt alle Änderungen über zwei unabhängige Release-Dimensionen:

Code: Bestimmungslogik, Tool-Schemas und Server-Transports folgen Semantic Versioning.
Regulatorische Daten: Gebündelte eCFR-JSON-Datensätze unter src/data/. Eine erneute Verifizierung eines Datensatzes gegen den aktuellen eCFR-Text verschiebt sein last_verified-Datum und wird als Patch-Update veröffentlicht, selbst wenn sich der regulatorische Text nicht geändert hat, wodurch eine prüfbare Provenienz für Compliance-Teams erhalten bleibt.
Erzwungener Decay: CI führt scripts/check-decay.ts wöchentlich aus, um den Build fehlschlagen zu lassen, wenn ein Datensatz seine 365-Tage-Decay-Schwelle ohne manuelle Neuverifizierung überschreitet.
Releases: Versionstags (vX.Y.Z) auf GitHub lösen .github/workflows/release.yml aus, um vollständige Validierungssuiten (Typprüfung, Tests, Smokes, Decay, Audit) auszuführen und ein verifiziertes GitHub-Release zu erstellen.

Entwicklung

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

Verbinden Sie sich lokal über npx @modelcontextprotocol/inspector oder fügen Sie claude_desktop_config.json hinzu, das auf dist/index.js zeigt.

npm run smoke:worker und npm run dev:worker benötigen Node 22 oder neuer, weil wrangler das tut. Alles andere läuft auf Node 20, und engines bleibt absichtlich bei >=20: Dieses Feld ist eine Aussage darüber, wer den Server installieren und ausführen kann, der nur das SDK und zod benötigt. Wrangler ist Entwicklungswerkzeug und erreicht nie einen Verbraucher, daher ist seine Anforderung nicht die des Pakets. CI hält Node 20 aus genau diesem Grund in der Matrix und überspringt dort nur den Worker-Smoke.

Evaluierungen

evals/recordkeeping-evals.xml — siebenundvierzig Fragen, die testen, ob ein LLM die richtige Antwort durch die Werkzeuge erreicht, was Unit-Tests nicht abdecken können. Jede Antwort wurde erzeugt, indem der gebaute Server mit einem echten MCP-Client betrieben wurde; die Spur befindet sich in evals/README.md. Die meisten der siebenundvierzig haben eine intuitive falsche Antwort, nach der ein aus dem Gedächtnis argumentierendes Modell greifen wird.

Haftungsausschluss

Nur Referenz und Triage. Keine Rechtsberatung, keine medizinische Feststellung. Grenzfälle der Aufzeichnungspflicht erfordern häufig einen PLHCP oder Rechtsbeistand. Arbeitsbezogenheit (1904.5) wird nur entlang ihrer deterministischen Pfade bestimmt; unklare Herkunft, Reisestatus, Arbeiten von zu Hause und jede nicht festgestellte „ausschließlich"-Feststellung geben requires_judgment zurück, nicht ein Urteil.

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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 recent community issues

Resources

Related MCP Connectors

Jobsite Safety Reference (free)A
com.jobsitecerts
Free, no-login construction safety tools: OSHA rule text, toolbox talks, 1904 recordability.
Legal & Compliance Government Data Education & Learning Tools
91
https://jobsitecerts.com/api/mcp/public
Seb LabsA
dev.seblabs
Typed AI decisions for agents: classify, route, screen evidence, score and batch-label text.
AI & Machine Learning Autonomous Agents
51
https://mcp.seblabs.dev/mcp
Sophon ConsultingA
consulting.sophon
Read-only, deterministic AI triage and readiness tools implementing Sophon's published rubrics.
AI & Machine Learning Testing & QA Tools
22
https://www.sophon.consulting/api/mcp
CairnA
com.cairnsafe
Workplace safety citation counts, penalties and 29 CFR standards data for AI assistants
Government Data Legal & Compliance
31
https://cairnsafe.com/mcp

Related MCP Servers

SafetyOps MCP Server
RAG Systems Knowledge & Memory Search
ANASSIJASSI
A
license
Not graded
quality
D
maintenance
Enables AI assistants to query workplace incident data using RAG, providing search, analysis, and corrective action plans.
Updated 8 months ago (2026-03-17 01:13 UTC)
1
MIT
secops-agent-triage
Security Observability
drummer475-94
A
license
Not graded
quality
D
maintenance
Enables AI agents to perform security alert triage by ingesting raw logs, extracting IOCs, querying threat intelligence sources, and generating structured NIST/MITRE assessments with reasoning traces.
Updated 3 months ago (2026-08-13 21:51 UTC)
MIT
stcc-mcp
Biology & Medicine AI & Machine Learning
devhc123
A
license
Not graded
quality
C
maintenance
Deterministic rule-based medical triage with citations, using a 0.6B LLM only to check criteria (yes/no/unknown).
Updated 2 months ago (2026-08-26 05:07 UTC)
Apache 2.0
Mstari MCP Server
Biology & Medicine Health & Wellness
Roy-Wanyoike
A
license
Not graded
quality
B
maintenance
Enables an agentic triage desk to load and normalise patient intake records, map free-text complaints onto cited South African Triage Scale discriminators, and compute deterministic TEWS-based priorities that sequence an outpatient queue with every source vital cited. Two of its tools are gated, so no priority is published without a named clinician's approval, and every call is written to a JSONL audit log.
Updated 22 days ago (2026-10-16 11:53 UTC)
MIT

OSHA Recordkeeping MCP — 29 CFR Part 1904

Verwendung

Warum dieses Tool existiert

Arbeitsteilung: LLM erzählt, Tool entscheidet

Das Anker-Tool: osha_assess_recordability

Protokolloberfläche (alle drei MCP-Primitive)

Herkunft & erzwungener Verfall

Die Incident-Triage-Kette (ausgeliefert)

Umfang: Teil 1904 und sonst nichts

Verteilung: ein Server und eine Skill

Der Server – drei Einstiegspunkte, eine Engine

Ratenbegrenzung

Was die Tools empfangen

Host- und Origin-Validierung

Die Skill

Aufbau

Kontinuierliche Integration

Änderungskontrolle & Versionierung

Entwicklung

Evaluierungen

Haftungsausschluss

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

Das Anker-Tool: `osha_assess_recordability`