Skip to main content
Glama
srhtdmrkl

osha-recordkeeping-mcp

by srhtdmrkl

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

osha_evaluate_restricted_work
Read-onlyIdempotent

Determine if a work restriction or transfer qualifies as restricted work under OSHA 1904.7. Verify before recording to avoid misclassification on the 300 Log.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reduced_output_onlyNoIs 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_vagueNoIs the recommendation vague — 'light duty', 'take it easy for a week' — rather than specific? (1904.7(b)(4)(vii))
worked_partial_shiftNoDid 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_jobNoWas 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_clarifiedNoIf 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_injuryYesDoes 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_shiftYesDoes 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

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

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