Skip to main content
Glama
Sign In

FMCSA Carrier Intelligence

by io.github.KMCTO
OverviewDiscussionsAdmin

find_carrier_by_mc

Read-onlyIdempotent

Free. Finds the USDOT number for an operating-authority docket number (MC, MX or FF), so a broker holding the MC number from a rate confirmation can reach the other tools, which take a USDOT number.

mc_number may be written "MC123456", "MC-123456", "mc 123456" or just "123456" (a bare number is taken as MC); zero-padding is ignored, because FMCSA's own files disagree on it. authority_holder_usdot_number is the carrier FMCSA's authority records tie the docket to, and there is never more than one. usdot_numbers lists every carrier that lists the docket (FMCSA's census lists about 26,000 dockets under a second carrier too, so a docket can legitimately appear under two), the holder first. docket_status and status_source say how current that is: "motus" is live, "legacy_li" is FMCSA's archive as of 2026-05-14, "census" is the census file's code. Returns only identifiers and a status, no names or addresses. An unknown docket is a not_found error; an unreadable one is invalid_arguments. Never billed.

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": {
      "mc_number": "<mc_number>"
    },
    "name": "find_carrier_by_mc"
  }
}

Input Schema

NameRequiredDescriptionDefault
mc_numberYesOperating authority docket number, e.g. MC12345 or 12345 (MC, MX or FF prefix accepted).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / mc_number / description
      Added value: +"Operating authority docket number, e.g. MC12345 or 12345 (MC, MX or FF prefix accepted)."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent and non-destructive, and the description still adds substantially: cost ('Free', 'Never billed'), output field meaning, the fact that a docket can legitimately appear under two carriers with the authority holder listed first, and per-source status freshness ('motus' live, 'legacy_li' archive as of 2026-05-14, 'census'). Error behavior is spelled out as well — not_found for unknown dockets, invalid_arguments for unreadable ones.

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

Conciseness5/5

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

Front-loaded with cost and purpose in the first line, then input tolerance, then return-field semantics, then error cases. The density is high but there is no filler; even the parenthetical about ~26,000 second-carrier dockets exists to justify the two-entry list.

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?

There is no output schema, so the description carries the full burden of explaining return values, and it does: which fields come back, their ordering, their provenance, and that no names or addresses are included. Nothing an agent needs to call this correctly or interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds meaning beyond it: accepted writings ('MC123456', 'MC-123456', 'mc 123456', bare '123456'), the rule that a bare number is treated as MC, and that zero-padding is ignored because FMCSA's own files disagree on it. That last point prevents a class of avoidable failures.

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 both resources: it finds the USDOT number for an operating-authority docket number (MC, MX or FF). It also explains why the mapping matters — the other tools take a USDOT number — so an agent can place it precisely in the workflow without opening any 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?

Gives a concrete trigger: a broker holding an MC number from a rate confirmation who needs to reach the USDOT-keyed tools. It does not name a specific alternative or state a when-not case, but the calling condition is unambiguous.

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 toolsInspect
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