Skip to main content
Glama

KeyVex

get_osha_enforcement

Read-only

Returns OSHA workplace-safety enforcement records from the Department of Labor's enforcement data: inspection cases (who was inspected, where, why, when) with optional violation citations attached (standard cited, violation type, penalties, abatement dates). Use this when the user asks about: a company's workplace-safety record, OSHA penalties or citations, fatality/catastrophe investigations, inspection activity by state or industry (NAICS), or contractor safety research. Result rows are INSPECTIONS. Pass include_violations=true to attach each inspection's citations under a violations array (or pass activity_nr for a direct lookup, which always includes them). min_penalty keeps only inspections with at least one violation whose initial or current penalty meets the threshold (implies include_violations). insp_type codes (DOL's own legend): A=Accident, B=Complaint, C=Referral, D=Monitoring, E=Variance, F=FollowUp, G=Unprog Rel, H=Planned, I=Prog Related, J=Unprog Other, K=Prog Other, L=Other-L, M=Fat/Cat (fatality/catastrophe), N=Unprog Emph. Each record carries insp_type_label with the decoded value. Violation viol_type codes: S=Serious, W=Willful, R=Repeat, O=Other, U=Unclassified. Violations carry delete_flag='X' when the source later deleted the citation — rows are kept with the flag, never dropped. Filter combinations note: server-side indexes support ONE of state / naics_code combined with the open_date sort + since/until. Other filters (establishment_name substring, insp_type, state+naics together, min_penalty) post-filter client-side over a widened fetch window. sort_by=case_mod_date is the 'recently updated cases' firehose and cannot be combined with state / naics_code / since / until. Pure-publisher posture: DOL's enforcement rows as published — codes kept verbatim (with the source's own legend decoded alongside), no safety scoring. Each record's source_url links to the osha.gov establishment inspection-detail page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum inspections to return. Default 50, max 500.
sinceNoInspection open_date lower bound (YYYY-MM-DD inclusive).
stateNoTwo-letter site state (e.g., 'TX', 'CA').
untilNoInspection open_date upper bound (YYYY-MM-DD inclusive).
sort_byNoSort key. Default: open_date. case_mod_date = most recently UPDATED cases (cannot combine with state/naics_code/since/until).
insp_typeNoOne-letter inspection-type code (e.g., 'M' Fat/Cat, 'B' Complaint, 'H' Planned — full legend in the tool description).
naics_codeNoExact NAICS industry code of the inspected site (e.g., '238160' roofing contractors). Note: '000000' on many pre-NAICS-era records.
sort_orderNoDefault: desc (most recent first).
activity_nrNoDirect lookup by OSHA inspection activity number (e.g., '317465899'). Returns the inspection with its violations attached. Fastest path.
min_penaltyNoKeep only inspections with at least one violation whose initial or current penalty is >= this amount (dollars). Implies include_violations=true.
establishment_nameNoCase-insensitive substring against the inspected establishment's name (e.g., 'amazon', 'dollar general'). Client-side filter.
include_violationsNoWhen true, attaches each returned inspection's violation citations under a `violations` array (standard, type, penalties, abatement/contest dates). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnly/openWorld/destructive=false) by disclosing index/filter-combination behavior, the case_mod_date 'firehose' that cannot combine with state/naics/since/until, client-side vs server-side filtering, delete_flag='X' retention semantics, and the pure-publisher (no safety scoring) posture. These are real behavioral traits an agent needs before calling.

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?

Purpose and use-cases are front-loaded, then return shape, then parameter/filter behavior, then data posture. Dense and mostly earning its space, though the insp_type and filter-combination passages are long enough that some tightening is possible.

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 12 parameters, no output schema, and no required fields, the description carries the burden well: it states rows are inspections, how violations attach, the meaning of min_penalty/activity_nr behavior, and source_url provenance. Nothing essential to correct invocation is missing.

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 already 100%, so baseline is 3, but the description adds meaning the schema does not: full decoded insp_type legend (M=Fat/Cat etc.), violation viol_type codes, and the delete_flag='X' semantics. Schema enums for sort_by/insp_type are explained rather than merely restated.

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?

States a specific verb+resource: returns OSHA workplace-safety enforcement records (inspections with optional violation citations), and explicitly says 'Result rows are INSPECTIONS'. This distinguishes it from sibling enforcement tools like get_epa_enforcement and get_nlrb_cases, which cover different agencies.

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?

Provides a concrete use-case list: company workplace-safety record, OSHA penalties/citations, fatality/catastrophe investigations, inspection activity by state or NAICS, contractor safety research. It also explains which paths to take (activity_nr for direct lookup, min_penalty implication, sort_by=case_mod_date constraint), but never names a sibling alternative or an explicit 'don't use this for X' exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources