FMCSA Carrier Intelligence

check_applicant_against_roster

Read-onlyIdempotent

Screens one applicant carrier against a roster of carriers you already do business with (or are vetting) — the batch generalization of confirm_identity_link, for the real-world case of catching a carrier that was previously cut from your network (revoked, suspended, or otherwise let go) trying to re-enter under a new USDOT number. usdot_number is the applicant; roster_usdot_numbers is your own list, supplied by you.

Returns linked (true if the applicant shares an identity cluster with ANY roster member) and matched_roster_usdot_numbers (which ones, always a subset of what you supplied — never a carrier you didn't already name). roster_not_found lists any roster entries that simply don't resolve to a known carrier (still your own input, not a new disclosure). usdot_number's own cluster_id is always included, same as check_carrier_identity's convention — it's the applicant's own data, not something withheld pending a match.

usdot_number must not also appear in roster_usdot_numbers, and roster_usdot_numbers must be a non-empty list of at most settings.roster_screen_max_size distinct entries (currently 100) — either violation is a free invalid_arguments; split a larger roster into multiple calls rather than expecting it to be truncated for you. An unresolved usdot_number (the applicant itself) is a free not_found, same as confirm_identity_link/check_carrier_identity.

Paid, metered: price = price_check_applicant_against_roster_base + price_check_applicant_against_roster_per_entry * (the deduped roster size) — see get_catalog for current rates. A "not linked to anything on your roster" result is a complete, valuable answer and bills the same as a match, same reasoning as check_carrier_identity's cluster_size == 1.

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>",
      "roster_usdot_numbers": "<roster_usdot_numbers>"
    },
    "name": "check_applicant_against_roster"
  }
}

Input Schema

Name	Required	Description	Default
`usdot_number`	Yes	USDOT number of the applicant carrier to screen.
`roster_usdot_numbers`	Yes	Your own roster: 1 to 100 USDOT numbers. Duplicates are counted once; the price depends on the size.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

addedInput schema / properties / roster_usdot_numbers / description

Added value: +"Your own roster: 1 to 100 USDOT numbers. Duplicates are counted once; the price depends on the size."

addedInput schema / properties / usdot_number / description

Added value: +"USDOT number of the applicant carrier to screen."

First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context: the exact return fields and their guarantees (matched_roster_usdot_numbers is always a subset of input, roster_not_found is the caller's own unresolved input), the pricing formula and metering behavior, and the fact that a no-match result bills identically. It stops just short of stating rate limits or latency behavior, but that is deferred to get_catalog by design.

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?

The key facts (what it does, what it returns, constraints, pricing) are front-loaded and each block is purposeful. It is on the long side, and the repeated reassurances that roster inputs are 'still your own input, not a new disclosure' restate the same trust point twice, costing a little tightness.

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 carries the full burden of explaining return values and does so field by field, plus error codes and billing semantics. For a two-parameter paid screening tool, nothing an agent needs to call it correctly or interpret a null result is missing.

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 both parameters are already documented in the schema and baseline 3 applies. The description adds real meaning beyond the schema: usdot_number must not appear in roster_usdot_numbers, duplicates are deduped and pricing scales with deduped size, and the caller must split oversized rosters rather than relying on server-side truncation.

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 ('screens one applicant carrier against a roster') and explicitly positions itself as the batch generalization of confirm_identity_link, so an agent can distinguish it from the single-pair sibling without opening a schema. The real-world scenario (catching a revoked carrier re-entering under a new USDOT number) makes the intent unambiguous.

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?

Gives explicit when-to-use framing (batch screening against your own roster rather than a single identity link) and concrete when-not boundaries: split rosters larger than the max into multiple calls, don't pass the applicant in the roster, don't expect truncation. Error-triggering conditions are spelled out per case.

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.