Skip to main content
Glama

carrierscore

by io.carrierscore

Look Up Carrier Identity

carrier_lookup
Read-onlyIdempotent

Look up an FMCSA-registered motor carrier's identity by US DOT number: legal name, DBA, operating status, FMCSA safety rating, fleet size (power units, drivers), physical address, and registration dates.

Use this first when a booking/dispatch agent needs to confirm WHO a carrier is — that a DOT number is real, active, and matches the company name on a rate confirmation. It does not return risk indices (use carrier_score for those).

Returns JSON: { dot_number, legal_name, dba_name, status_code, safety_rating, power_units, total_drivers, phy_street, phy_city, phy_state, phy_zip, add_date, mcs150_date }.

Errors: 404 if the DOT is not in the FMCSA census (likely a typo or a fraudulent/never-registered carrier — treat as a red flag for booking).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dot_numberYesUS DOT number of the carrier, digits only (e.g. "1234567")

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
phy_zipNo
add_dateNoDate added to the FMCSA census (YYYY-MM-DD)
dba_nameNoDoing-business-as name, if any
phy_cityNo
phy_stateNo
dot_numberYesUS DOT number
legal_nameNoRegistered legal name
phy_streetNo
mcs150_dateNoLatest MCS-150 filing date (YYYY-MM-DD)
power_unitsNoFleet size: number of power units
status_codeNoFMCSA operating status code (e.g. "A" = active)
safety_ratingNoFMCSA safety rating code (e.g. "S" = satisfactory)
total_driversNoTotal drivers reported

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations by explaining the 404 error meaning (likely typo/fraudulent carrier) and what the tool does not return (risk indices). This is useful operational detail not present in annotations.

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 description is well-structured with a clear first sentence, usage guidance, a JSON return example, and error handling. It is a bit long but every section earns its place, and it is front-loaded with the purpose. The JSON example might be redundant given an output schema exists, but it is still useful context.

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?

The tool is a simple lookup with one parameter and a rich output schema. The description covers the purpose, when to use it, what it returns, what it does not return, and error behavior. Given the complexity, this is complete.

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?

The input schema has 100% coverage for the single parameter dot_number, including a pattern and descriptive example. The tool description adds no additional parameter-level meaning beyond restating 'by US DOT number.' Baseline of 3 is appropriate since the schema does the heavy lifting.

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 clearly states the tool's function: 'Look up an FMCSA-registered motor carrier's identity by US DOT number' and enumerates the returned fields. It explicitly differentiates from sibling carrier_score by noting it does not return risk indices, so an agent can distinguish between the tools.

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?

The description provides direct guidance: 'Use this first when a booking/dispatch agent needs to confirm WHO a carrier is' and states a clear exclusion: 'It does not return risk indices (use carrier_score for those).' This gives explicit when-to-use and an alternative, exceeding the minimum.

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

All carrierscore toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct function: identity lookup, detailed risk scoring, batch monitoring, alert history, report generation, and list management. There is no meaningful overlap between them; even carrier_score and montgomery_file differ in that one returns raw indices and the other produces a documented artifact.

Naming Consistency4/5

All names use snake_case and are readable, but there is a slight mix of verb-first (list_alerts, monitor_carriers, save_carrier_list) and noun-first (carrier_lookup, carrier_score, montgomery_file) patterns. This is a minor deviation; the names are still clear and predictable.

Tool Count5/5

Six tools is well-scoped for a domain-specific risk-assessment API. Each tool serves a clear purpose in the workflow, covering identity verification, scoring, batch checks, monitoring, alerting, and report generation without bloat.

Completeness4/5

The core lifecycle is covered: lookup, score, monitor, alert, report. However, there is no tool to update or delete a saved carrier list, nor a way to list the current contents of a list. These are minor gaps that can be worked around by creating new lists or relying on alert data.

Resources