Skip to main content
Glama
srhtdmrkl

osha-recordkeeping-mcp

by srhtdmrkl

Check Severe-Injury Reporting Deadline (29 CFR 1904.39)

osha_check_severe_injury_reporting
Read-onlyIdempotent

Check if a fatality, hospitalization, amputation, or eye loss is OSHA-reportable. Get the 8-hour or 24-hour deadline and see if exclusions apply.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outcomeYesThe severe outcome, if any. 'none' means no 1904.39 reporting is triggered.
amputation_kindNoFor 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_datetimeYesISO 8601 datetime the employer LEARNED of the outcome. Reporting deadlines run from this moment.
outcome_datetimeNoISO 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_datetimeYesISO 8601 datetime of the work-related incident, e.g. 2026-07-25T09:40:00-05:00.
reporting_exclusionNoWhether 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_onlyNoFor 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

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
valueYes
cfr_citeYes
source_urlYes
last_verifiedYes
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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/srhtdmrkl/osha-recordkeeping-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server