FMCSA Carrier Intelligence

check_broker_authority

Read-onlyIdempotent

Does this broker hold active broker authority, and what does FMCSA's record say around it? Give exactly one of mc_number (the broker's MC docket, written MC123456, MC-123456 or 123456) or usdot_number. Paid, flat price; billed whenever the carrier resolves, including when it holds no broker authority (that is the answer). An unknown docket or USDOT number is a free not_found; giving neither or both, or a docket FMCSA lists under several carriers without naming a holder, is a free error.

Returns holds_active_broker_authority and the broker dockets (docket number, status, how current that status is, active types, first grant and last event dates); the bond (BMC-84/85) on-file flag with its continuity (coverage unbroken since, current gap, closed lapses in 24 and 60 months, longest gap, data-through date); the authority event history (grants, reinstatements, revocations, suspensions, in total and over 24 and 60 months); revocation, suspension and reinstatement flags; and the identity linkage screen. A record, not a recommendation or a rating.

How far to trust "holds active broker authority": it is as complete as the two FMCSA sources behind it. FMCSA froze its legacy licensing archive on 2026-05-14, so a docket known only from it (status_source legacy_li) describes that date, and a docket whose status changed afterwards and is not yet on FMCSA's live MOTUS roster is not seen. There is no independent count of real brokers to check against. Confirm the broker's current authority and bond with FMCSA before relying on it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_broker_authority"
  }
}

Input Schema

Name	Required	Description	Default
`mc_number`	No	Docket number, e.g. MC12345. Give this or usdot_number.
`usdot_number`	No	Carrier USDOT number. Give this or mc_number.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026
- addedInput schema / properties / mc_number / description
```
Added value: +"Docket number, e.g. MC12345. Give this or usdot_number."
```
- addedInput schema / properties / usdot_number / description
```
Added value: +"Carrier USDOT number. Give this or mc_number."
```
AddedOct 15, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already establish this as a safe, idempotent read, and the description adds value well beyond them: a paid flat-price billing model that charges even when no authority exists, free not_found and free error paths, and the ambiguity case where a docket maps to several carriers. It also discloses data-provenance limits (the legacy_li archive frozen 2026-05-14 versus the live MOTUS roster) and frames the result as a record rather than a rating.

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 question, then inputs, billing, returned fields, and trust caveats in a sensible order. The returned-fields sentence is a long enumeration, but with no output schema it is doing necessary work rather than padding.

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 tool with no output schema, no annotations about cost, and external data dependencies, the description covers everything an agent needs: inputs, charge model, error taxonomy, return shape, and the freshness/coverage limitations of the underlying FMCSA sources.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds real semantics: the mutually exclusive one-of rule, the accepted MC formats (MC123456, MC-123456, 123456), and the rule that an ambiguous multi-carrier docket is an error rather than a guess. That is meaningful constraint information the schema does not encode.

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 opening question plus the reciprocal input constraint ("Give exactly one of mc_number ... or usdot_number") makes the verb and resource unmistakable: resolve a broker docket and report FMCSA authority status. It is clearly narrower in scope than general carrier-lookup siblings, but it never names an alternative tool, so it stops short of explicit sibling differentiation.

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?

Usage conditions are unusually concrete: exactly one identifier, formats accepted, and which inputs produce a free not_found versus a free error, plus an explicit instruction to confirm with FMCSA before relying on the result. The gap is that it never routes the agent to a sibling (e.g. find_carrier_by_mc or lookup_carrier) when broker authority is not the question being asked.

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.