Skip to main content
Glama
srhtdmrkl

osha-recordkeeping-mcp

by srhtdmrkl

Classify OSHA 300 Log Entry (29 CFR 1904.29)

osha_classify_300_log_entry
Read-onlyIdempotent

Classify a recordable case into the correct OSHA 300 Log outcome column. Uses the most-serious-outcome rule and capped day counts, with special rules for medical removal, TB, and chemical exposure.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deathNoDid the injury/illness result in death?
illness_typeNoThe injury/illness type column (M).injury
is_recordableYesIs the case recordable? Run osha_assess_recordability first. If false, it does not go on the 300 Log.
tuberculosis_caseNoIs this a tuberculosis case? 1904.11(a) requires the RESPIRATORY CONDITION column.
days_away_from_workNoCALENDAR 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_caseNoIs 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_receivedNoISO 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_transferNoCALENDAR 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_evidenceNoFor 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_recordingNoHas 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_exposureNoDid 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

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?

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.

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