Skip to main content
Glama

Screen a carrier's DOT or MC number and onboarding packet against the public FMCSA record

double_brokering_and_identity
Read-onlyIdempotent

Carrier onboarding screen for freight brokers, shippers and factoring companies. Send a USDOT number and/or an MC number, and optionally what the carrier's packet claims (legal name, phone, email, street, city, state, zip). It reads the public FMCSA records and returns what to review before onboarding: not found, inactive, no active authority, a record under 180 days old, an MCS-150 not updated in 730 days, an MC number that belongs to a different DOT number, a claimed name, phone, email or address that is not the one on file, and the same phone or email on other carrier records that are no longer active (how double-brokering and carrier-identity fraud usually shows up in public data). Answer fields: verdict (nothing_to_review, review, incomplete, not_found), checks (each with status and plain detail), review (the short list), record (public fields, phone and email masked), sources with dates, rules, observation, signature; ok false with a message for bad input (400), a source that cannot be reached (502, or verdict incomplete when only the shared-contact lookup failed) or the hourly limit (429). Free for now; paid calls planned at $5 per check, not charging. No model, nothing stored, signed record. It does not say a carrier is a fraud or is safe, and it is not legal, insurance or credit advice.

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

Input Schema

NameRequiredDescriptionDefault
claimedNoWhat the carrier's packet says; send only what you have. Each field is compared with the public record and not stored.
mc_numberNoMC (docket) number, digits only (an 'MC' prefix is fine), up to 8.
dot_numberNoUSDOT number, digits only, up to 8.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses the hourly rate limit with the 429 code, the 502 source-unreachable path and the partial-failure verdict, the 400 bad-input path, that nothing is stored, that the record is signed, and the pricing posture (free now, $5 planned, not charging). It also bounds the claim explicitly — it does not assert fraud or safety and is not legal, insurance or credit advice — which is exactly the kind of 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.

Conciseness3/5

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

The opening sentence is well front-loaded, but the middle collapses into a long comma-chained enumeration of checks and another of answer fields, and the trailing disclaimers and pricing note are appended without structure. Nearly every sentence carries real information, but the density and run-on phrasing make it slower to parse than it needs to be.

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 enumerating the verdict values, the checks/review/record/sources/rules/signature fields, and the error-code behavior is necessary and is fully done here. For a three-parameter, nested-object, open-world screening tool, an agent has everything needed to call it and interpret the result.

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?

Schema description coverage is 100% and the nested claimed object already documents every field, including that each is compared and not stored. The description reinforces the semantics — 'send only what you have', and the MC-belongs-to-a-different-DOT check that explains why both identifiers matter — but adds little syntax or format detail beyond the schema. Baseline 3 is appropriate.

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?

The description names a specific verb and resource — screen a carrier's USDOT/MC number and claimed packet details against public FMCSA records — and names the audience (freight brokers, shippers, factoring companies). It is clearly distinguishable from siblings like vat_number_check or agent_identity_check because the data source and the double-brokering/identity-fraud framing are stated outright.

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?

It gives a clear operating context (pre-onboarding screening) and tells the caller exactly what to send, including that DOT and/or MC are both acceptable and the packet fields are optional. It stops short of explicit when-not-to-use guidance or naming an alternative tool, so it falls just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources