FMCSA Carrier Intelligence

get_safety_history

Read-onlyIdempotent

Historical snapshots and changelog entries for a carrier. Paid — you pay only when a call returns records; an exact-key miss is free.

changelog may legitimately be empty for a carrier without two distinct-date snapshots yet — a diff needs both. authority_types, oos_orders_active, insurance_bipd_on_file, insurance_cargo_on_file, insurance_bond_on_file, has_been_revoked, and last_revocation_date are null (not false/empty) on a history row recorded before 2026-09-02 — carrier_history wasn't tracking those fields yet, so null there means "not tracked on this date," not a negative answer. Likewise has_been_suspended/last_suspension_date are null before 2026-09-06, and has_authority_reinstated/last_reinstatement_date/ has_insurance_identity_mismatch are null before 2026-09-12, and insurance_cancel_pending/days_to_cancel_effective/ soonest_cancel_effective_date are null before 2026-10-04. changelog holds real changes only (change_kind "value_changed"): the row the warehouse writes when a field first starts being tracked is never returned. About 97% of authority_status changes are dated 2026-09-02, when FMCSA's licensing data switched systems; treat that date's authority_status changes with some caution. Likewise most safety_tier_derived changes dated 2026-10-10 come from a method change (a second SMS file added; never-inspected carriers moved from tier 1 to null), not from the carrier. Carries no contact information (legal_name, dba_name, addresses, phone, email — removed 2026-09-19, see schemas.CarrierProfile); changelog excludes field_name in {legal_name, dba_name, phone, email} for the same reason — a changed value is still the value.

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": {
      "usdot_number": "<usdot_number>"
    },
    "name": "get_safety_history"
  }
}

Input Schema

Name	Required	Description	Default
`since_date`	No	Optional ISO date (YYYY-MM-DD); only snapshots and changes on or after it are returned.
`usdot_number`	Yes	Carrier USDOT number (digits only), the canonical FMCSA carrier identifier.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

addedInput schema / properties / since_date / description

Added value: +"Optional ISO date (YYYY-MM-DD); only snapshots and changes on or after it are returned."

addedInput schema / properties / usdot_number / description

Added value: +"Carrier USDOT number (digits only), the canonical FMCSA carrier identifier."

First observedOct 3, 2026

TDQS

A3.6/5.0

Behavior5/5

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

Beyond the read-only annotations, the description discloses important behavior: billing only on record-returning calls, legitimate empty changelogs, null-as-not-tracked semantics with specific cutoff dates, excluded field names, and known data anomalies around authority_status and safety_tier_derived changes. This adds substantial operational context for correct interpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and cost warning are front-loaded, and most caveats are meaningful, but the definition is a long, dense paragraph with many field names and dates. It would benefit from clearer structure despite the relevance of the content.

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?

For a complex historical retrieval tool with no output schema, the description does a lot to explain null meanings, changelog behavior, and data-quality caveats. It still does not fully describe the shape of returned snapshots or changelog entries, leaving some output interpretation to inference.

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 both parameters are already documented in the input schema. The description does not add parameter-specific meaning for usdot_number or since_date, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns historical snapshots and changelog entries for a carrier. This is a specific verb-and-resource purpose, but it does not explicitly differentiate the tool from sibling history or summary tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies historical lookup usage but gives no explicit when-to-use guidance, exclusions, or comparison to alternatives. An agent is left to infer when this tool is preferred over sibling carrier-history or inspection-summary tools.

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

All FMCSA Carrier Intelligence 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.