FMCSA Carrier Intelligence

screen_carrier_identity

Read-onlyIdempotent

Free triage screen for a carrier: whether it's flagged under FMCSA's own chameleon-carrier methodology, how big its identity cluster is, and how many linked carriers carry a motive — with no member detail. Call check_carrier_identity (paid) for that.

This is the entire discovery/sales motion in an agent-only channel, not a discount tier — free by design (Identity-API-Revision- 2026-09-06.md Section 1), so it never bills and never requires payment. By the same design, it withholds anything that identifies a linked carrier: no member USDOT number, no legal name, no link type, no identifier hash. A caller learns THAT there is something to look at here, not WHAT.

confidence_caveat discloses the known ~6% artifact rate and that recall is not measurable in FMCSA's public data — read it, don't just check the flagged boolean. match_score_practical_ceiling is computed per carrier from which ARCHI terms were actually available for it, not a flat constant — most carriers cap out well below the theoretical 8.5.

An unknown USDOT number returns a not_found error.

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": "screen_carrier_identity"
  }
}

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."
```
First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, but the description adds substantial context: it never bills, never requires payment, and deliberately withholds member USDOT, legal name, link type, and identifier hash. It also flags the ~6% artifact rate via confidence_caveat and explains that match_score_practical_ceiling is computed per carrier from available ARCHI terms rather than being a constant.

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 the core purpose and outcome, then the withholding policy and caveats. Slightly bloated by the internal design-document citation ('Identity-API-Revision-2026-09-06.md Section 1') and the 'agent-only channel, not a discount tier' justification, which serve sales narrative more than tool selection.

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 one-parameter tool with no output schema, the description covers what the caller receives (flag, cluster size, motive count), what is intentionally absent, the confidence caveat, and the error case. An agent can invoke and interpret it without opening anything else.

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 schema coverage is 100%, so the schema already documents usdot_number as digits-only canonical identifier. The description adds only the error behavior for an unknown value, not new semantics about the parameter itself; baseline 3 applies.

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 and resource ('free triage screen for a carrier') and immediately enumerates what the caller learns: FMCSA chameleon-carrier flag, identity cluster size, and count of motive-linked carriers. It explicitly distinguishes itself from the paid sibling check_carrier_identity, which returns member detail.

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?

Clear when-to-use: free triage / discovery when you only need to know THAT something is worth looking at. Explicit alternative and escalation path ('Call check_carrier_identity (paid) for that'). Also states the failure mode for an unknown USDOT number (not_found error).

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.