Jobsite Safety Reference (free)

Training a trade needs, from Jobsite's inventory

training_required_for

Read-onlyIdempotent

What training Jobsite's requirements inventory assigns a construction trade in a US state, optionally for roles the worker also holds (supervisor, competent person, forklift operator, scaffold erector and others). Every obligation comes from Jobsite's inventory, never from general knowledge, and carries its citation and the regulation text quoted verbatim: quote it as given. Each row's kind matters and must be kept: a mandate is an unconditional legal training duty; a condition applies only when the condition it names exists on the job; a policy is training Jobsite assigns without a legal mandate there, with its basis stated. A not-found answer means "not in Jobsite's requirements inventory", never "no training required". The inventory holds federal OSHA rows plus California, Washington, Oregon and Nevada rows. search_law_corpus returns the full text of any cited rule.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "state": "<state>"
    },
    "name": "training_required_for"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max obligations to return (default 40, up to 80).
`roles`	No	Roles or designations the worker also holds. A competent person is designated per topic, so pair it with topic to narrow.
`state`	Yes	The US state the work is in: a two-letter code or name, e.g. "CA".
`topic`	No	Narrow to one training topic.
`trade`	No	The worker's trade in plain words, e.g. "roofer", "electrician", "sheet metal". An unknown trade returns the trades Jobsite knows.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses provenance (every obligation comes from the inventory, never general knowledge), output structure (kind values: mandate, condition, policy, each with its basis), and the exact citation plus verbatim regulation text included with each row. It also disambiguates failure semantics, stating that a not-found answer means 'not in Jobsite's requirements inventory' rather than 'no training required' — a genuinely important behavioral trait for a zero-result read.

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 lead sentence is front-loaded with purpose and scope, followed by provenance, output-kind semantics, and the not-found caveat in a logical order. Sentences are dense but each carries distinct information an agent needs; the wording is slightly packed and could be split, but there is no filler.

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 read-only, non-open-world lookup with no output schema, the description supplies everything an agent needs: what the rows mean, that citations and verbatim rule text are attached and must be reproduced as given, which jurisdictions are covered, and how to interpret an empty result. The absence of an output schema is fully compensated.

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 parameter documentation already does the work; the description adds only the notion that roles narrow the result set and that obligations are tied to the trade/state pair. It says nothing extra about the limit or topic parameters beyond the schema text. Baseline 3 applies where the schema carries the semantics.

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 opening clause names a specific resource (Jobsite's requirements inventory) and outcome (what training a construction trade is assigned) with the scoping dimensions (trade, US state, roles). It also names the sibling tool search_law_corpus and what that one is for (full text of a cited rule), so an agent can separate the two without opening a schema.

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 makes clear this is the lookup for assigned training obligations and points to search_law_corpus only when the underlying rule text beyond the quoted citation is needed. It also states the coverage boundary (federal OSHA rows plus California, Washington, Oregon and Nevada), which tells the agent when this tool will not apply. It stops short of an explicit 'do not use this when…' exclusion.

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

All Jobsite Safety Reference (free) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?