Skip to main content
Glama

carrierscore

by io.carrierscore

Monitor Carrier List

monitor_carriers
Read-onlyIdempotent

Batch risk check for a list of carriers by US DOT number (max 100 per call): score summary and hard flags for each.

Use when an agent is screening multiple candidate carriers for a load, or re-checking a broker's active carrier roster ("did any of my carriers pick up an out-of-service order or drop insurance?"). For a full breakdown of any single carrier that looks risky here, follow up with carrier_score or montgomery_file.

Args:

  • dot_numbers: array of DOT number strings, 1-100 entries

Returns JSON: { scored_as_of, requested, found, carriers: [{ dot_number, legal_name, inspection_risk (0-100 inspection / compliance risk index, higher = riskier), crash_risk (0-100 crash risk index), carrier_score (legacy composite under v0.5 — backward compatibility only; use the two indices), data_sufficiency, flags: string[] }], not_found: string[], disclaimer }. DOTs in not_found are absent from the scored population — verify them with carrier_lookup; an unknown DOT on your roster is itself a red flag.

Errors: 400 if the list is empty or exceeds 100 (split into batches); 503 if scores are not computed yet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dot_numbersYesUS DOT numbers to check, 1-100 per call

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
foundYesHow many were found in the scored population
carriersYesScore summary per found carrier
not_foundYesRequested DOTs absent from the scored population
requestedYesHow many DOT numbers were requested
disclaimerNoMethodology disclaimer — relay verbatim
scored_as_ofNoDate of the scoring run (YYYY-MM-DD)

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive. Description adds meaningful context: 100 per call limit, 400/503 errors, legacy carrier_score semantics, not_found meaning as red flag. No contradiction.

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?

Structured into focused paragraphs: main purpose, when to use, args, returns, errors. No redundant sentences; front-loaded with key capability.

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?

Single parameter, output schema present, and description covers return payload fields, error conditions, and follow-up actions. Sufficient for an agent to invoke correctly and interpret results.

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?

The schema already fully documents dot_numbers with pattern, min/max. Description supplements by explaining batching (split into batches) and that dot_numbers are carriers. It clarifies interpretation of results per DOT but doesn't need to repeat schema details.

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?

Clear verb+resource: 'Batch risk check for a list of carriers by US DOT number.' It specifies scope (max 100) and output (score summary and hard flags). Distinguishes from siblings by naming carrier_score and montgomery_file for single-carrier follow-up.

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?

Explicit when-to-use: 'Use when an agent is screening multiple candidate carriers...' and 're-checking a broker's active carrier roster.' Also gives alternatives for follow-up (carrier_score/montgomery_file) and verification (carrier_lookup).

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