Skip to main content
Glama
srhtdmrkl

osha-recordkeeping-mcp

by srhtdmrkl

Check Whether Recordkeeping Applies (29 CFR 1904.1)

osha_check_recordkeeping_obligation
Read-onlyIdempotent

Run this first to determine if an employer must keep OSHA injury records—checks company size and industry exemptions to avoid unnecessary log entries.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
establishment_naics_codeNoThe 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_recordsNoHas 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_yearYesThe 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_industryNoFallback 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

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 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.

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