FMCSA Carrier Intelligence

get_inspection_crash_summary

Read-onlyIdempotent

A carrier's roadside inspection, violation and crash summary on its own. Paid, flat price; billed whenever the USDOT number resolves, even if the carrier had no inspections (that is the finding). An unknown number is a free not_found.

inspections (SMS data, a 24-month window that ends weeks before today: read window_end): inspection counts by driver and vehicle, out-of-service counts and rates (FMCSA's own method; no national average is carried, so cite FMCSA's), violation counts in total and by BASIC, last inspection date. When there were no inspections the measures are null, never zero, and data_quality_flags says why: inspection_summary_no_inspections (in SMS, none in the window) or inspection_summary_unavailable (in neither SMS file, so SMS says nothing either way). A carrier inspected only after window_end reads as having none.

crashes (federally recordable crashes, trailing 730 days ending at the build date): counts by fatal, injury, tow-away and hazmat release, plus fatalities and injuries and the last crash date. A floor, not a total: about 19% of crash records carry no USDOT number and cannot be attributed to any carrier.

Counts, not a rating: this does not say a carrier is safe or unsafe, and it carries no contact information.

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_inspection_crash_summary"
  }
}

Input Schema

Name	Required	Description	Default
`usdot_number`	Yes	Carrier USDOT number (digits only), the canonical FMCSA carrier identifier.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026
- addedInput schema / properties / usdot_number / description
```
Added value: +"Carrier USDOT number (digits only), the canonical FMCSA carrier identifier."
```
AddedOct 15, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses pricing and billing rules (flat price, charged even with zero inspections, free on not_found), the 24-month window ending weeks before today, null-instead-of-zero semantics with named data_quality_flags, and the ~19% unattributed crash floor. This is exactly the behavioral context annotations cannot carry.

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?

Front-loaded with a one-line summary of what it returns and what it costs, then organized into clearly labeled inspections and crashes blocks. It is long, but the density is justified by the null-semantics and window-end caveats; a few clauses could be tightened.

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 no output schema, the description fully covers the returned fields (driver/vehicle counts, out-of-service rates, BASIC violations, fatal/injury/tow-away/hazmat breakdowns), the meaning of nulls and flags, and the temporal limits of each dataset. An agent can interpret results correctly without further documentation.

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?

Only one parameter, and the schema already documents usdot_number at 100% coverage as the canonical FMCSA identifier. The description adds no further format or input guidance, so the baseline 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 names a concrete resource set (roadside inspections, violations, crash summary) keyed to a carrier USDOT number, and explicitly scopes it as 'counts, not a rating' with 'no contact information.' It stops short of naming a sibling such as get_safety_history or lookup_carrier to disambiguate overlapping-sounding tools, so it is clear but not sibling-differentiated.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the reader infers this is the tool for inspection/crash counts on a known USDOT number. It does give valuable decision context (billed whenever the number resolves, free not_found), but never says when to prefer it over get_safety_history or the other carrier 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.