A
licenseNot graded
qualityC
maintenanceProvides keyless access to US FMCSA motor-carrier registry data, enabling lookup of DOT/MC numbers, names, operating authority, and safety information.
15
MIT
carrierscore
Server Details
FMCSA motor-carrier risk scores, monitoring, and carrier-selection evidence reports for AI agents.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- csprout3/carrierscore-mcp
- GitHub Stars
- 0
- Server Listing
- CarrierScore MCP Server
Available Tools
8 toolsaudit_entriesList Archived Evidence ReportsARead-onlyIdempotentInspect
List the immutable audit-archive entries for the caller's API key: every Montgomery evidence report the key generated (text or json), newest first, each with its entry id, generation timestamp, DOT number, scoring date, methodology version and the SHA-256 of the archived report text. Requires a paid CarrierScore API key.
Use it to answer "which carriers did we generate evidence for, and when?" and to find the entry id to cite or verify for a given carrier and date. Monitor keys see the last 90 days; Compliance keys see everything ever archived.
Args:
dot_number (optional): only entries for this US DOT number
since (optional): YYYY-MM-DD; only entries generated on/after this date (UTC)
limit (optional): 1-500, default 50
Returns JSON: { tier, retention_days, total_entries, matched, count, entries: [{ entry_id, generated_at, dot_number, sha256, format_requested, scored_as_of, score_version }] }.
Errors: 403 without a paid key; 400 if since is malformed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries to return (default 50) | |
| since | No | Only entries generated on/after this date (YYYY-MM-DD, UTC) | |
| dot_number | No | US DOT number of the carrier, digits only (e.g. "1234567") |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tier | Yes | Caller's tier (monitor / compliance) |
| count | Yes | Entries returned (<= limit) |
| entries | Yes | Newest first |
| matched | Yes | Entries matching the filters within the retention window |
| total_entries | Yes | All entries ever archived for this key |
| retention_days | Yes | Retrieval window in days (monitor 90; compliance null = unlimited) |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses immutability ('immutable'), read-only nature ('List'), idempotent behavior (implied by list operation with no side effects), authentication requirement ('Requires a paid CarrierScore API key'), retention rules for different key tiers, and error conditions (403/400). These go beyond the annotations (readOnlyHint, idempotentHint, openWorldHint) by providing specific behavioral details about key tiers, errors, and the nature of the data.
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 defining purpose, followed by usage guidance, key tier info, parameter list, return structure, and error handling. Each part adds value. While slightly long, it front-loads the core purpose and is efficiently organized with bullet-like formatting for parameters and returns.
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?
Given the tool has 3 parameters (all documented), an output schema exists (the description even provides the structure), and the tool is a straightforward list operation, the description is complete. It covers purpose, usage context, key tier differences, parameter details, return format, and error scenarios. No additional information seems missing for an agent to correctly select and invoke this tool.
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 input schema covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by clarifying optionality ('optional') for dot_number, specifying the default for limit ('default 50' which is not in the schema), and explicitly stating the range '1-500' and format for since ('YYYY-MM-DD; only entries generated on/after this date (UTC)'). This extra context raises the score above baseline.
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 lists immutable audit-archive entries for the caller's API key, specifying the verb 'list' and the resource 'audit-archive entries' with details about content (every Montgomery evidence report) and ordering (newest first). It distinguishes from siblings like montgomery_file (which likely retrieves a specific file) and verify_evidence (which verifies evidence), as it focuses on listing entries for the caller's key.
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?
The description explicitly states when to use the tool: 'Use it to answer which carriers did we generate evidence for, and when? and to find the entry id to cite or verify for a given carrier and date.' It also provides context about key tiers (Monitor vs Compliance keys seeing different retention). However, it does not explicitly exclude alternatives or contrast with sibling tools like montgomery_file for downloading files or verify_evidence for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
carrier_lookupLook Up Carrier IdentityARead-onlyIdempotentInspect
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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dot_number | Yes | US DOT number of the carrier, digits only (e.g. "1234567") |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| phy_zip | No | |
| add_date | No | Date added to the FMCSA census (YYYY-MM-DD) |
| dba_name | No | Doing-business-as name, if any |
| phy_city | No | |
| phy_state | No | |
| dot_number | Yes | US DOT number |
| legal_name | No | Registered legal name |
| phy_street | No | |
| mcs150_date | No | Latest MCS-150 filing date (YYYY-MM-DD) |
| power_units | No | Fleet size: number of power units |
| status_code | No | FMCSA operating status code (e.g. "A" = active) |
| safety_rating | No | FMCSA safety rating code (e.g. "S" = satisfactory) |
| total_drivers | No | Total 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.
carrier_scoreGet Carrier Risk IndicesARead-onlyIdempotentInspect
Get the CarrierScore risk indices for a carrier by US DOT number: two first-class, separately validated indices (0-100, HIGHER = RISKIER), each with a full component breakdown.
This is the core "is this carrier safe to book?" signal for AI booking agents. Served methodology v0.5 returns TWO indices, both population-relative and built from point-in-time public FMCSA data:
inspection_risk — inspection / compliance risk: violations and out-of-service rates per roadside inspection (24-month chronic, 6-month acute). Historically validated against the carrier's future out-of-service rate (validation block on the index).
crash_risk — crash risk: reportable crashes, fatal/injury crashes and tow-away crashes per roadside inspection (24 months). Historically validated against future reportable crashes (validation block on the index). Present BOTH indices; do not collapse them into one number. Hard flags (active out-of-service order, no active insurance filing, high-confidence reincarnated-carrier link) add explicit surcharges — a carrier with any flag deserves extra scrutiny regardless of index values.
Returns JSON: { dot_number, legal_name, inspection_risk: { label, description, score, base, surcharge, percentile_basis, band, band_note, data_sufficiency, components: { : { label, value, percentile, weight } }, validation: { auc_holdout, label, holdout_origins, post_selection_origin, source, text } }, crash_risk: { ...same shape... }, legacy_composite: { score, base_score, surcharge, rule, rule_text, validated: false, note }, carrier_score (backward-compatible: == legacy_composite.score under v0.5), base_score, surcharge, score_version ("0.5"), methodology_note, components (flat, backward-compatible), flags: string[], data_sufficiency (0-1, share of the components resting on observed vs neutral-imputed data), scored_as_of, disclaimer }. Older opt-in methodologies keep their shapes: v0 (six components), v0.3 (sub_indices), v0.4 (indices + composite).
Interpreting for booking decisions: treat the indices as documented decision-support evidence, not an approve/deny verdict. legacy_composite / carrier_score is NOT validated and is kept only so older integrations keep working — never present it as the carrier's risk score. Low data_sufficiency means limited inspection history — common for new carriers, itself a risk signal. Always relay each index's validation text and the disclaimer when presenting the result.
Errors: 404 if the DOT is not in the scored population; 503 if scores have not been computed yet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dot_number | Yes | US DOT number of the carrier, digits only (e.g. "1234567") |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| flags | Yes | Hard flags (OOS order, no insurance, reincarnation link) |
| indices | No | v0.4 only: inspection_risk / crash_risk first-class indices (0-100), each with components, percentile basis and band |
| composite | No | v0.4 only: how the headline carrier_score is derived from the two indices |
| surcharge | No | Additional points from hard flags |
| base_score | No | Score before hard-flag surcharges (v0.5: legacy composite base) |
| components | Yes | Flat component map keyed by component name (v0.5: within-index weights of both indices, for backward compatibility; the per-index components live under inspection_risk / crash_risk) |
| crash_risk | No | v0.5 (served default): CRASH RISK index 0-100 (higher = riskier) — crashes, fatal/injury and tow-away crashes per roadside inspection relative to the population; validated against future reportable crashes. Read this second. |
| disclaimer | No | Methodology disclaimer — relay verbatim |
| dot_number | Yes | US DOT number |
| legal_name | No | |
| sub_indices | No | v0.3 only: inspection_risk / crash_risk sub-indices (0-100) and their weights |
| scored_as_of | No | Date of the scoring run (YYYY-MM-DD) |
| carrier_score | No | 0-100, higher = riskier. Under v0.5 this equals legacy_composite.score (kept for backward compatibility); under v0/v0.3/v0.4 it is that version's headline score |
| score_version | No | Documented methodology version ("0.5" is the served default; "0", "0.3", "0.4" are opt-in) |
| inspection_risk | No | v0.5 (served default): INSPECTION / COMPLIANCE RISK index 0-100 (higher = riskier) — violations and out-of-service rates per roadside inspection relative to the population; validated against future out-of-service rate. Read this first. |
| data_sufficiency | No | 0-1: share of the score resting on observed vs neutral-imputed data |
| legacy_composite | No | v0.5: backward-compatible legacy composite (0.70 x higher index + 0.30 x lower index + surcharges). Not validated, not the headline — do not present it as the carrier's risk score. |
| methodology_note | No | One-line description of the weighting used |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnly/idempotent, the description adds substantial behavior: two separately validated indices, point-in-time data, legacy_composite being unvalidated, hard flags adding surcharges, data_sufficiency caveats, and 404/503 error conditions. This goes far beyond the annotation safety profile.
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 long but densely informative and front-loaded with the core purpose. It could be tightened because the inline JSON return shape duplicates what an output schema would provide, but each section (methodology, interpretation, errors) earns its place.
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 complex, high-stakes risk tool, the description covers inputs, output shape, methodology versions, validation status, flags, data sufficiency, booking-decision interpretation, backward compatibility, and error semantics. It is fully self-sufficient for an agent to select and invoke correctly.
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 only parameter dot_number is already fully described in the schema with type, pattern, and example. The description merely references 'US DOT number' and adds no additional semantic detail, so baseline 3 is appropriate given 100% schema coverage.
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 opens with a specific verb and resource: 'Get the CarrierScore risk indices for a carrier by US DOT number.' It clearly identifies the two indices and distinguishes this risk-scoring tool from sibling lookup/monitoring tools by positioning it as the core booking-safety signal.
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 provides strong context ('core is this carrier safe to book? signal') and explicit interpretation guidance ('treat the indices as documented decision-support evidence, not an approve/deny verdict', 'never present it as the carrier's risk score'). It does not name sibling alternatives directly, but gives clear when-to-use and when-not-to-use framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_alertsGet Alerts for a Saved Carrier ListARead-onlyIdempotentInspect
Retrieve the alert history for a saved carrier list (see save_carrier_list), newest first. Requires the same paid API key that saved the list.
Each alert records one change detected between consecutive daily scoring runs for one carrier: type (oos_order_activated, authority_lost, insurance_lapsed, status_changed, inspection_risk_jump, crash_risk_jump, score_jump, reincarnation_link), severity (critical / high / medium / low), the field that changed with its before/after values, the DOT and legal name, and the scoring dates compared. inspection_risk_jump / crash_risk_jump (index base up >= 10 points, medium) are the primary deterioration signals; score_jump on the legacy composite is emitted at low severity for backward compatibility. Use it to answer "did anything change on my carrier list?" — critical alerts (new OOS order, authority lost) mean the carrier should not be dispatched until verified; follow up with carrier_score or montgomery_file for the full picture.
Args:
list_id: the lst_... id returned by save_carrier_list
since (optional): YYYY-MM-DD; only alerts from scoring runs on/after this date
Returns JSON: { list_id, since, count, alerts: [{ ts, as_of, prev_as_of, list_id, list_name, dot, legal_name, type, severity, field, before, after }] }. An empty alerts array means no monitored change since the given date (alerts only exist once two daily scoring runs have happened).
Errors: 403 without a paid key; 404 if the list id is unknown for this key; 400 if since is not YYYY-MM-DD.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Only alerts from scoring runs on/after this date (YYYY-MM-DD) | |
| list_id | Yes | Saved list id from save_carrier_list |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of alerts returned |
| since | No | Lower bound applied (YYYY-MM-DD) or null |
| alerts | Yes | Alert history, newest first |
| list_id | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description details the alert generation process (only after two daily scoring runs), the alert types and severity semantics, and the exact error codes (403/404/400). This gives the agent a clear model of the tool's behavior without contradicting the 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 approximately 250 words, organized into three paragraphs. It is dense but structured: purpose first, then alert semantics, then args/returns/errors. Some details duplicate the output schema, but the length is justified by the tool's complexity. A 4 rather than 5 due to redundancy with schema.
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 description covers the tool's purpose, usage context, alert taxonomy, return shape, error conditions, and prerequisite. It also explains edge cases like empty alerts and the necessity of two scoring runs, making it complete for an agent to invoke correctly.
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 coverage is 100%, so the baseline is 3. The description adds only marginal parameter context (e.g., list_id comes from save_carrier_list and since filters by scoring run date), but these are also present in the schema. Therefore no significant extra semantics beyond the schema are provided.
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 opens with 'Retrieve the alert history for a saved carrier list,' a specific verb and resource naming. It distinguishes this tool from siblings by explicitly directing follow-up to carrier_score or montgomery_file and referencing save_carrier_list.
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?
It explicitly answers 'did anything change on my carrier list?' and says critical alerts mean 'the carrier should not be dispatched until verified.' It names alternatives for follow-up and states the paid API prerequisite, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
monitor_carriersMonitor Carrier ListARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dot_numbers | Yes | US DOT numbers to check, 1-100 per call |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | How many were found in the scored population |
| carriers | Yes | Score summary per found carrier |
| not_found | Yes | Requested DOTs absent from the scored population |
| requested | Yes | How many DOT numbers were requested |
| disclaimer | No | Methodology disclaimer — relay verbatim |
| scored_as_of | No | Date 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.
montgomery_fileGenerate Montgomery Evidence FileARead-onlyIdempotentInspect
Generate a timestamped Montgomery file — a carrier-selection evidence report — for a carrier by US DOT number.
Since Montgomery v. Caribe Transport II (SCOTUS, May 2026), freight brokers are exposed to state-law negligent-selection claims and need documented, timestamped, safety-data-based carrier selection. This report is that artifact: the two risk indices (inspection / compliance risk and crash risk, each with its components, percentiles, activity-band context and its own historical-validation line), the legacy composite (labelled backward-compatibility only), hard flags, FMCSA safety rating, and the methodology disclaimer, dated as of the scoring run. A booking agent should generate and retain this file at the moment a carrier is selected for a load.
Args:
dot_number: US DOT number, digits only
format: "text" (default; the filing-ready plain-text report, available on the free tier) or "json" (structured fields; requires an API key on the monitor or compliance tier)
Returns: format="text" gives the plain-text report (structured field report_text); format="json" gives structured fields { report, generated, dot_number, legal_name, dba_name, safety_rating, status_code, power_units, inspection_risk, crash_risk, legacy_composite (v0.5), carrier_score (backward-compatible), components, flags, data_sufficiency, score_version, scored_as_of, disclaimer } (v0.4 parquets return indices + composite instead). Every report embeds the disclaimer verbatim — keep it when storing or quoting the report.
Audit archive (paid tiers): every report generated with an API key is stored immutably server-side and the result carries audit_entry_id + sha256 (SHA-256 of the plain-text report). Quote both when citing the report; later, verify_evidence(entry_id) proves the archived copy is unchanged and audit_entries lists what was generated. Monitor keys can retrieve the last 90 days (2,000 reports/month); Compliance keys have unlimited retention and reports.
Errors: 403 if format=json without an API key; 404 unknown DOT; 429 if a Monitor key has used its 2,000 reports this month (upgrade hint in the message); 503 if scores are not computed yet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | "text" = filing-ready report (free tier); "json" = structured fields (requires API key) | text |
| dot_number | Yes | US DOT number of the carrier, digits only (e.g. "1234567") |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| flags | No | |
| report | No | Report title line (format="json") |
| sha256 | No | Paid tiers: SHA-256 of the archived plain-text report — cite it alongside the entry id |
| indices | No | |
| dba_name | No | |
| composite | No | |
| generated | No | Report generation date (YYYY-MM-DD) |
| surcharge | No | |
| base_score | No | |
| components | No | |
| crash_risk | No | v0.5: crash risk index with components and validation |
| disclaimer | No | |
| dot_number | No | |
| legal_name | No | |
| power_units | No | |
| report_text | No | Filing-ready plain-text evidence report (format="text") |
| status_code | No | |
| sub_indices | No | |
| scored_as_of | No | |
| carrier_score | No | 0-100, higher = riskier (v0.5: == legacy_composite.score) |
| safety_rating | No | |
| score_version | No | |
| audit_entry_id | No | Paid tiers: id of the immutable archived copy of this report (use with verify_evidence / audit_entries) |
| inspection_risk | No | v0.5: inspection / compliance risk index with components and validation |
| data_sufficiency | No | |
| legacy_composite | No | v0.5: legacy composite, backward compatibility only |
| methodology_note | No |
TDQS
A3.7/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations. Annotations claim readOnlyHint=true, but the description states that reports are stored immutably server-side (a write side effect) and each call generates a new audit entry, violating idempotentHint=true. Per the rules, this contradiction scores 1.
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 description is front-loaded with the purpose and includes substantial detail, but it is verbose (multiple paragraphs, legal background, exhaustive error list). While every sentence adds value, it could be more concise without losing clarity.
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?
Given the tool's complexity (2 params, output schema, annotations), the description covers purpose, usage, parameters, return values, audit storage, tier limitations, and error conditions. It references sibling tools appropriately and leaves no obvious gaps.
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 baseline is 3. The description adds significant extra meaning: it explains the default format, return structures for each format (text vs json), and the implications of each parameter choice (free tier vs API key). This goes beyond the schema descriptions.
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 purpose: 'Generate a timestamped Montgomery file — a carrier-selection evidence report — for a carrier by US DOT number.' It uses specific verbs and resources, and the legal context and mention of 'filing-ready' distinguish it from sibling tools like carrier_score or carrier_lookup.
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?
The description provides explicit usage context: 'A booking agent should generate and retain this file at the moment a carrier is selected for a load.' It also explains format choices and tier requirements. However, it does not explicitly compare to sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_carrier_listSave Carrier List for Daily MonitoringAInspect
Save a named list of carriers (by US DOT number) for continuous monitoring. Requires a paid CarrierScore API key (Monitor or Compliance tier) — connect with your key via OAuth (or set CARRIERSCORE_API_KEY on a self-hosted server); the free tier gets a 403 with an upgrade link.
Once saved, CarrierScore diffs every carrier on the list against the previous day's scoring run after each daily run and records alerts: new out-of-service order (critical), operating authority lost (critical), insurance filing lapsed (high), operating status leaving Active (high), risk score up 10+ points (medium), high-confidence reincarnated-carrier link appearing (medium). Alerts are always retrievable with list_alerts; optionally they are also pushed to a webhook (JSON POST, HMAC-signed via the X-CarrierScore-Signature header with the per-key secret from GET /v1/lists) and/or summarized in one daily digest email.
Use this when a broker asks to "watch" or "keep an eye on" their carrier roster. Caps: 500 DOTs total across all lists on the Monitor tier, 5000 on Compliance; up to 50 lists per key. Saving the same DOT twice in one list is deduped.
Args:
name: short label for the list (1-100 chars)
dot_numbers: array of DOT number strings (1-8 digits each)
webhook_url (optional): https URL to POST new alerts to
email (optional): address for the daily digest
Returns JSON: { list_id, name, dots, created, updated, webhook_url?, email? }. Keep list_id — list_alerts needs it.
Errors: 403 without a paid key; 400 on invalid DOTs, empty list, or exceeding the tier cap (message says which); 401 bad key.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | List name, e.g. "Active roster Q3" | |
| No | Optional daily digest email | ||
| dot_numbers | Yes | US DOT numbers to monitor | |
| webhook_url | No | Optional https URL to receive alert POSTs |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| dots | Yes | US DOT numbers on the list (deduped) |
| name | Yes | List name |
| No | Daily digest email, if configured | |
| created | No | Creation timestamp (ISO 8601 UTC) |
| list_id | Yes | Saved list id (lst_...) — use with list_alerts |
| updated | No | Last update timestamp (ISO 8601 UTC) |
| webhook_url | No | Alert webhook URL, if configured |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, etc.), the description discloses substantial behavioral traits: daily diffing against previous scoring runs, alert severity levels, paid-tier requirement with 403 on free tier, optional webhook/email push, caps, and dedupe behavior. No contradiction with annotations.
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?
The description is long but well-organized into clear sections: purpose, post-save behavior, usage context, limits, arguments, return value, and errors. Each sentence adds necessary operational detail, and the core purpose is front-loaded.
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 four parameters, background monitoring behavior, auth requirements, and error conditions, the description covers all relevant aspects: purpose, side effects, limits, output format, and relationship to list_alerts. It is fully sufficient for an agent to invoke the tool correctly.
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 coverage is 100%, so baseline is 3. The description's Args section mostly restates schema descriptions (e.g., length limits, digit counts). It adds minor operational context like caps and dedupe but does not significantly deepen parameter understanding beyond the schema.
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 purpose with a specific verb and resource: 'Save a named list of carriers (by US DOT number) for continuous monitoring.' It also distinguishes itself from the sibling tool list_alerts by noting alerts are retrievable via that tool, making the purpose even clearer.
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?
The description gives an explicit use case: 'Use this when a broker asks to "watch" or "keep an eye on" their carrier roster.' It provides context but does not name alternative tools or explicitly state when not to use this tool, even though sibling tools like monitor_carriers exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_evidenceVerify Archived Evidence Report HashARead-onlyIdempotentInspect
Verify an archived Montgomery evidence report by its audit entry id: CarrierScore re-reads the immutable stored copy, recomputes its SHA-256 and reports whether it matches the hash recorded at generation time (and, optionally, a hash the caller supplies — e.g. the sha256 printed on a broker's filed copy). Requires the same paid API key that generated the report.
Use it when a broker or auditor needs to prove that a filed evidence report is exactly what CarrierScore produced on the stated date. match=true means the archived report is byte-identical to what was served; match_supplied compares against the caller's own hash. Follow up with the audit_entries list to find ids, or with montgomery_file to generate a fresh report.
Args:
entry_id: the audit_entry_id returned by montgomery_file (also listed by audit_entries)
sha256 (optional): a 64-hex SHA-256 to compare against the archived report (text or canonical json)
Returns JSON: { entry_id, dot_number, generated_at, scored_as_of, score_version, format_requested, sha256_stored, sha256_computed, match, sha256_json_stored, sha256_json_computed, match_json, sha256_supplied?, match_supplied? }.
Errors: 403 without a paid key, or (Monitor tier) if the entry is older than the 90-day retrieval window; 404 if the entry id is unknown for this key.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | No | Optional SHA-256 to compare against the archived report | |
| entry_id | Yes | Audit entry id from montgomery_file / audit_entries |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| match | Yes | true = the archived report is byte-identical to what was served |
| entry_id | Yes | |
| dot_number | No | |
| match_json | No | |
| generated_at | No | |
| scored_as_of | No | |
| score_version | No | |
| sha256_stored | No | Hash recorded when the report was archived |
| match_supplied | No | Whether the supplied hash matches the archived report |
| sha256_computed | Yes | Hash recomputed now from the stored report text |
| sha256_supplied | No | Echo of the hash the caller supplied, if any |
| format_requested | No | |
| sha256_json_stored | No | |
| sha256_json_computed | No |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds value by explaining the verification process (re-reads stored copy, recomputes SHA-256, compares hashes). It also discloses authentication requirement ('Requires the same paid API key') and error conditions (403, 404, Monitor tier 90-day limit), which go beyond 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 (verb+resource), usage section, parameter explanations, and return value summary. At about 120 words, it is efficient but could be slightly more terse in the return value explanation since an output schema exists. Still, every major sentence adds value.
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?
Given the tool's moderate complexity (2 params, output schema present, descriptive annotations), the description is complete: it explains purpose, usage context, parameters, return fields, error cases, and authentication. The presence of output schema reduces the burden for return values, and the description focuses on what the schema and annotations don't cover.
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 baseline is 3. The description adds meaning by explaining the source of entry_id ('from montgomery_file / audit_entries') and the optional sha256 parameter's purpose ('caller supplies — e.g. the sha256 printed on a broker's filed copy'). It also clarifies the patterns but schema already has regex. The description earns extra for explaining how parameters relate to the verification logic.
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 verb 'verify' and the specific resource 'Archived Montgomery evidence report hash'. It distinguishes the tool from siblings like 'montgomery_file' (generates fresh reports) and 'audit_entries' (lists ids) by explaining that this tool checks integrity of stored reports.
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 explicitly says 'Use it when a broker or auditor needs to prove that a filed evidence report is exactly what CarrierScore produced on the stated date.' It also provides context on when not to use it implicitly (e.g., to generate a fresh report use montgomery_file) and gives follow-up actions (audit_entries list, montgomery_file).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
- Added
audit_entries - Changed
montgomery_file2 fields changed- added
Output schema / properties / audit_entry_idAdded value: +{ + "description": "Paid tiers: id of the immutable archived copy of this report (use with verify_evidence / audit_entries)", + "type": "string" +} - added
Output schema / properties / sha256Added value: +{ + "description": "Paid tiers: SHA-256 of the archived plain-text report — cite it alongside the entry id", + "type": "string" +}
- Added
verify_evidence
3 tool updates
- Changed
carrier_score16 fields changed- changed
Output schema / properties / base_score / descriptionPrevious value: -"Score before hard-flag surcharges"New value: +"Score before hard-flag surcharges (v0.5: legacy composite base)" - changed
Output schema / properties / carrier_score / descriptionPrevious value: -"CarrierScore 0-100, higher = riskier"New value: +"0-100, higher = riskier. Under v0.5 this equals legacy_composite.score (kept for backward compatibility); under v0/v0.3/v0.4 it is that version's headline score" - added
Output schema / properties / components / additionalProperties / $refAdded value: +"#/properties/inspection_risk/properties/components/additionalProperties" - removed
Output schema / properties / components / additionalProperties / additionalPropertiesRemoved value: -true - removed
Output schema / properties / components / additionalProperties / propertiesRemoved value: -{ - "label": { - "description": "Human-readable component label", - "type": "string" - }, - "percentile": { - "description": "Population percentile of the value, 0-1", - "type": [ - "number", - "null" - ] - }, - "value": { - "description": "Raw component value", - "type": [ - "number", - "null" - ] - }, - "weight": { - "description": "Component weight in the base score", - "type": "number" - } -} - removed
Output schema / properties / components / additionalProperties / requiredRemoved value: -[ - "label" -] - removed
Output schema / properties / components / additionalProperties / typeRemoved value: -"object" - changed
Output schema / properties / components / descriptionPrevious value: -"Score components keyed by component name"New value: +"Flat component map keyed by component name (v0.5: within-index weights of both indices, for backward compatibility; the per-index components live under inspection_risk / crash_risk)" - added
Output schema / properties / crash_riskAdded value: +{ + "$ref": "#/properties/inspection_risk", + "description": "v0.5 (served default): CRASH RISK index 0-100 (higher = riskier) — crashes, fatal/injury and tow-away crashes per roadside inspection relative to the population; validated against future reportable crashes. Read this second." +} - added
Output schema / properties / indices / additionalProperties / $refAdded value: +"#/properties/inspection_risk" - removed
Output schema / properties / indices / additionalProperties / additionalPropertiesRemoved value: -true - removed
Output schema / properties / indices / additionalProperties / propertiesRemoved value: -{ - "band": { - "description": "Carrier's 24m inspection-count band", - "type": [ - "string", - "null" - ] - }, - "band_note": { - "type": "string" - }, - "base": { - "description": "Percentile blend before surcharge (0-100)", - "type": [ - "number", - "null" - ] - }, - "components": { - "additionalProperties": { - "$ref": "#/properties/components/additionalProperties" - }, - "type": "object" - }, - "data_sufficiency": { - "type": [ - "number", - "null" - ] - }, - "description": { - "type": "string" - }, - "label": { - "type": "string" - }, - "percentile_basis": { - "description": "\"global\" or \"banded\" (24m inspection-activity band)", - "type": "string" - }, - "score": { - "description": "Index 0-100 incl. its own surcharge, higher = riskier", - "type": [ - "number", - "null" - ] - }, - "surcharge": { - "type": [ - "number", - "null" - ] - }, - "surcharges_applied": { - "items": { - "type": "string" - }, - "type": "array" - } -} - removed
Output schema / properties / indices / additionalProperties / typeRemoved value: -"object" - added
Output schema / properties / inspection_riskAdded value: +{ + "additionalProperties": true, + "description": "v0.5 (served default): INSPECTION / COMPLIANCE RISK index 0-100 (higher = riskier) — violations and out-of-service rates per roadside inspection relative to the population; validated against future out-of-service rate. Read this first.", + "properties": { + "band": { + "description": "Carrier's 24m inspection-count band", + "type": [ + "string", + "null" + ] + }, + "band_note": { + "type": "string" + }, + "base": { + "description": "Percentile blend before surcharge (0-100)", + "type": [ + "number", + "null" + ] + }, + "components": { + "additionalProperties": { + "additionalProperties": true, + "properties": { + "label": { + "description": "Human-readable component label", + "type": "string" + }, + "percentile": { + "description": "Population percentile of the value, 0-1", + "type": [ + "number", + "null" + ] + }, + "value": { + "description": "Raw component value", + "type": [ + "number", + "null" + ] + }, + "weight": { + "description": "Component weight in the base score", + "type": "number" + } + }, + "required": [ + "label" + ], + "type": "object" + }, + "type": "object" + }, + "data_sufficiency": { + "type": [ + "number", + "null" + ] + }, + "description": { + "type": "string" + }, + "label": { + "type": "string" + }, + "percentile_basis": { + "description": "\"global\" or \"banded\" (24m inspection-activity band)", + "type": "string" + }, + "score": { + "description": "Index 0-100 incl. its own surcharge, higher = riskier", + "type": [ + "number", + "null" + ] + }, + "surcharge": { + "type": [ + "number", + "null" + ] + }, + "surcharges_applied": { + "items": { + "type": "string" + }, + "type": "array" + }, + "validation": { + "additionalProperties": true, + "description": "v0.5: this index's own historical validation (point-in-time backtest, held-out cohorts)", + "properties": { + "auc_holdout": { + "description": "Held-out AUC range on the index's own outcome", + "type": "string" + }, + "auc_post_selection_holdout": { + "type": "string" + }, + "holdout_origins": { + "items": { + "type": "string" + }, + "type": "array" + }, + "label": { + "description": "The future outcome the index was validated against", + "type": "string" + }, + "post_selection_origin": { + "type": [ + "string", + "null" + ] + }, + "source": { + "description": "Path of the validation report in docs/research", + "type": "string" + }, + "text": { + "description": "One-line validation statement — relay with the index", + "type": "string" + }, + "top_decile_lift": { + "type": "string" + } + }, + "type": "object" + } + }, + "type": "object" +} - added
Output schema / properties / legacy_compositeAdded value: +{ + "additionalProperties": true, + "description": "v0.5: backward-compatible legacy composite (0.70 x higher index + 0.30 x lower index + surcharges). Not validated, not the headline — do not present it as the carrier's risk score.", + "properties": { + "base_score": { + "type": [ + "number", + "null" + ] + }, + "note": { + "type": "string" + }, + "rule": { + "type": "string" + }, + "rule_text": { + "type": "string" + }, + "score": { + "description": "Legacy composite 0-100 (== top-level carrier_score)", + "type": [ + "number", + "null" + ] + }, + "surcharge": { + "type": [ + "number", + "null" + ] + }, + "validated": { + "description": "Always false: the composite is not validated or gated", + "type": "boolean" + } + }, + "type": "object" +} - changed
Output schema / properties / score_version / descriptionPrevious value: -"Documented methodology version (e.g. \"0\", \"0.3\")"New value: +"Documented methodology version (\"0.5\" is the served default; \"0\", \"0.3\", \"0.4\" are opt-in)"
- Changed
monitor_carriers3 fields changed- changed
Output schema / properties / carriers / items / properties / carrier_score / descriptionPrevious value: -"0-100, higher = riskier"New value: +"0-100, higher = riskier (v0.5: legacy composite, backward compatibility only — use the two indices)" - changed
Output schema / properties / carriers / items / properties / crash_risk / descriptionPrevious value: -"v0.3/v0.4 parquets: crash-history risk index 0-100"New value: +"Crash risk index 0-100 (v0.5 headline; also present for v0.3/v0.4 parquets)" - changed
Output schema / properties / carriers / items / properties / inspection_risk / descriptionPrevious value: -"v0.3/v0.4 parquets: inspection risk index 0-100"New value: +"Inspection / compliance risk index 0-100 (v0.5 headline; also present for v0.3/v0.4 parquets)"
- Changed
montgomery_file13 fields changed- changed
Output schema / properties / carrier_score / descriptionPrevious value: -"CarrierScore 0-100, higher = riskier"New value: +"0-100, higher = riskier (v0.5: == legacy_composite.score)" - added
Output schema / properties / components / additionalProperties / $refAdded value: +"#/properties/inspection_risk/properties/components/additionalProperties" - removed
Output schema / properties / components / additionalProperties / additionalPropertiesRemoved value: -true - removed
Output schema / properties / components / additionalProperties / propertiesRemoved value: -{ - "label": { - "description": "Human-readable component label", - "type": "string" - }, - "percentile": { - "description": "Population percentile of the value, 0-1", - "type": [ - "number", - "null" - ] - }, - "value": { - "description": "Raw component value", - "type": [ - "number", - "null" - ] - }, - "weight": { - "description": "Component weight in the base score", - "type": "number" - } -} - removed
Output schema / properties / components / additionalProperties / requiredRemoved value: -[ - "label" -] - removed
Output schema / properties / components / additionalProperties / typeRemoved value: -"object" - added
Output schema / properties / crash_riskAdded value: +{ + "$ref": "#/properties/inspection_risk", + "description": "v0.5: crash risk index with components and validation" +} - added
Output schema / properties / indices / additionalProperties / $refAdded value: +"#/properties/inspection_risk" - removed
Output schema / properties / indices / additionalProperties / additionalPropertiesRemoved value: -true - removed
Output schema / properties / indices / additionalProperties / propertiesRemoved value: -{ - "band": { - "description": "Carrier's 24m inspection-count band", - "type": [ - "string", - "null" - ] - }, - "band_note": { - "type": "string" - }, - "base": { - "description": "Percentile blend before surcharge (0-100)", - "type": [ - "number", - "null" - ] - }, - "components": { - "additionalProperties": { - "$ref": "#/properties/components/additionalProperties" - }, - "type": "object" - }, - "data_sufficiency": { - "type": [ - "number", - "null" - ] - }, - "description": { - "type": "string" - }, - "label": { - "type": "string" - }, - "percentile_basis": { - "description": "\"global\" or \"banded\" (24m inspection-activity band)", - "type": "string" - }, - "score": { - "description": "Index 0-100 incl. its own surcharge, higher = riskier", - "type": [ - "number", - "null" - ] - }, - "surcharge": { - "type": [ - "number", - "null" - ] - }, - "surcharges_applied": { - "items": { - "type": "string" - }, - "type": "array" - } -} - removed
Output schema / properties / indices / additionalProperties / typeRemoved value: -"object" - added
Output schema / properties / inspection_riskAdded value: +{ + "additionalProperties": true, + "description": "v0.5: inspection / compliance risk index with components and validation", + "properties": { + "band": { + "description": "Carrier's 24m inspection-count band", + "type": [ + "string", + "null" + ] + }, + "band_note": { + "type": "string" + }, + "base": { + "description": "Percentile blend before surcharge (0-100)", + "type": [ + "number", + "null" + ] + }, + "components": { + "additionalProperties": { + "additionalProperties": true, + "properties": { + "label": { + "description": "Human-readable component label", + "type": "string" + }, + "percentile": { + "description": "Population percentile of the value, 0-1", + "type": [ + "number", + "null" + ] + }, + "value": { + "description": "Raw component value", + "type": [ + "number", + "null" + ] + }, + "weight": { + "description": "Component weight in the base score", + "type": "number" + } + }, + "required": [ + "label" + ], + "type": "object" + }, + "type": "object" + }, + "data_sufficiency": { + "type": [ + "number", + "null" + ] + }, + "description": { + "type": "string" + }, + "label": { + "type": "string" + }, + "percentile_basis": { + "description": "\"global\" or \"banded\" (24m inspection-activity band)", + "type": "string" + }, + "score": { + "description": "Index 0-100 incl. its own surcharge, higher = riskier", + "type": [ + "number", + "null" + ] + }, + "surcharge": { + "type": [ + "number", + "null" + ] + }, + "surcharges_applied": { + "items": { + "type": "string" + }, + "type": "array" + }, + "validation": { + "additionalProperties": true, + "description": "v0.5: this index's own historical validation (point-in-time backtest, held-out cohorts)", + "properties": { + "auc_holdout": { + "description": "Held-out AUC range on the index's own outcome", + "type": "string" + }, + "auc_post_selection_holdout": { + "type": "string" + }, + "holdout_origins": { + "items": { + "type": "string" + }, + "type": "array" + }, + "label": { + "description": "The future outcome the index was validated against", + "type": "string" + }, + "post_selection_origin": { + "type": [ + "string", + "null" + ] + }, + "source": { + "description": "Path of the validation report in docs/research", + "type": "string" + }, + "text": { + "description": "One-line validation statement — relay with the index", + "type": "string" + }, + "top_decile_lift": { + "type": "string" + } + }, + "type": "object" + } + }, + "type": "object" +} - added
Output schema / properties / legacy_compositeAdded value: +{ + "additionalProperties": true, + "description": "v0.5: legacy composite, backward compatibility only", + "properties": { + "base_score": { + "type": [ + "number", + "null" + ] + }, + "note": { + "type": "string" + }, + "rule": { + "type": "string" + }, + "rule_text": { + "type": "string" + }, + "score": { + "description": "Legacy composite 0-100 (== top-level carrier_score)", + "type": [ + "number", + "null" + ] + }, + "surcharge": { + "type": [ + "number", + "null" + ] + }, + "validated": { + "description": "Always false: the composite is not validated or gated", + "type": "boolean" + } + }, + "type": "object" +}
3 tool updates
- Changed
carrier_score2 fields changed- added
Output schema / properties / compositeAdded value: +{ + "additionalProperties": true, + "description": "v0.4 only: how the headline carrier_score is derived from the two indices", + "properties": { + "base_score": { + "type": [ + "number", + "null" + ] + }, + "carrier_score": { + "type": [ + "number", + "null" + ] + }, + "note": { + "type": "string" + }, + "rule": { + "type": "string" + }, + "rule_text": { + "type": "string" + }, + "surcharge": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" +} - added
Output schema / properties / indicesAdded value: +{ + "additionalProperties": { + "additionalProperties": true, + "properties": { + "band": { + "description": "Carrier's 24m inspection-count band", + "type": [ + "string", + "null" + ] + }, + "band_note": { + "type": "string" + }, + "base": { + "description": "Percentile blend before surcharge (0-100)", + "type": [ + "number", + "null" + ] + }, + "components": { + "additionalProperties": { + "$ref": "#/properties/components/additionalProperties" + }, + "type": "object" + }, + "data_sufficiency": { + "type": [ + "number", + "null" + ] + }, + "description": { + "type": "string" + }, + "label": { + "type": "string" + }, + "percentile_basis": { + "description": "\"global\" or \"banded\" (24m inspection-activity band)", + "type": "string" + }, + "score": { + "description": "Index 0-100 incl. its own surcharge, higher = riskier", + "type": [ + "number", + "null" + ] + }, + "surcharge": { + "type": [ + "number", + "null" + ] + }, + "surcharges_applied": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" + }, + "description": "v0.4 only: inspection_risk / crash_risk first-class indices (0-100), each with components, percentile basis and band", + "type": "object" +}
- Changed
monitor_carriers2 fields changed- added
Output schema / properties / carriers / items / properties / crash_riskAdded value: +{ + "description": "v0.3/v0.4 parquets: crash-history risk index 0-100", + "type": [ + "number", + "null" + ] +} - added
Output schema / properties / carriers / items / properties / inspection_riskAdded value: +{ + "description": "v0.3/v0.4 parquets: inspection risk index 0-100", + "type": [ + "number", + "null" + ] +}
- Changed
montgomery_file2 fields changed- added
Output schema / properties / compositeAdded value: +{ + "additionalProperties": true, + "properties": { + "base_score": { + "type": [ + "number", + "null" + ] + }, + "carrier_score": { + "type": [ + "number", + "null" + ] + }, + "note": { + "type": "string" + }, + "rule": { + "type": "string" + }, + "rule_text": { + "type": "string" + }, + "surcharge": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" +} - added
Output schema / properties / indicesAdded value: +{ + "additionalProperties": { + "additionalProperties": true, + "properties": { + "band": { + "description": "Carrier's 24m inspection-count band", + "type": [ + "string", + "null" + ] + }, + "band_note": { + "type": "string" + }, + "base": { + "description": "Percentile blend before surcharge (0-100)", + "type": [ + "number", + "null" + ] + }, + "components": { + "additionalProperties": { + "$ref": "#/properties/components/additionalProperties" + }, + "type": "object" + }, + "data_sufficiency": { + "type": [ + "number", + "null" + ] + }, + "description": { + "type": "string" + }, + "label": { + "type": "string" + }, + "percentile_basis": { + "description": "\"global\" or \"banded\" (24m inspection-activity band)", + "type": "string" + }, + "score": { + "description": "Index 0-100 incl. its own surcharge, higher = riskier", + "type": [ + "number", + "null" + ] + }, + "surcharge": { + "type": [ + "number", + "null" + ] + }, + "surcharges_applied": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" + }, + "type": "object" +}
2 tool updates
- Changed
carrier_score3 fields changed- added
Output schema / properties / methodology_noteAdded value: +{ + "$ref": "#/properties/legal_name", + "description": "One-line description of the weighting used" +} - added
Output schema / properties / score_versionAdded value: +{ + "$ref": "#/properties/legal_name", + "description": "Documented methodology version (e.g. \"0\", \"0.3\")" +} - added
Output schema / properties / sub_indicesAdded value: +{ + "additionalProperties": { + "additionalProperties": true, + "properties": { + "label": { + "type": "string" + }, + "value": { + "description": "Sub-index 0-100, population-relative", + "type": [ + "number", + "null" + ] + }, + "weight": { + "description": "Sub-index weight in the composite", + "type": "number" + } + }, + "type": "object" + }, + "description": "v0.3 only: inspection_risk / crash_risk sub-indices (0-100) and their weights", + "type": "object" +}
- Changed
montgomery_file3 fields changed- added
Output schema / properties / methodology_noteAdded value: +{ + "$ref": "#/properties/legal_name" +} - added
Output schema / properties / score_versionAdded value: +{ + "$ref": "#/properties/legal_name" +} - added
Output schema / properties / sub_indicesAdded value: +{ + "additionalProperties": { + "additionalProperties": true, + "properties": { + "label": { + "type": "string" + }, + "value": { + "description": "Sub-index 0-100, population-relative", + "type": [ + "number", + "null" + ] + }, + "weight": { + "description": "Sub-index weight in the composite", + "type": "number" + } + }, + "type": "object" + }, + "type": "object" +}
6 tool updates
- First observed
carrier_lookup - First observed
carrier_score - First observed
list_alerts - First observed
monitor_carriers - First observed
montgomery_file - First observed
save_carrier_list
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Freight carrier intel: new FMCSA authority feed, carrier lookup by DOT/MC, safety screen (CSA/SMS).
US motor-carrier registry: DOT/MC/name lookup, operating authority, safety — keyless
Leads of businesses that just legally need commercial insurance: new FMCSA authority + new entities.
Pay-per-call US government data: carrier safety, visa sponsors, contracts, employer risk.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceAn MCP server for freight dispatchers that takes natural language orders, selects vehicles, checks regulations via RAG, and prepares documents for clients and drivers.-
- AlicenseNot gradedqualityDmaintenanceOcean container shipping intelligence for AI agents — D\&D tariffs, freight rates, vessel schedules, port congestion, inland haulage across 6 major carriers. 24 MCP tools.MIT
- AlicenseAqualityCmaintenanceReal-time LTL freight fuel surcharge rates for 9 US carriers and US state ABC liquor license compliance lookups (CA, TX, NY, FL). Every response includes a verifiability block with extraction confidence and source URL so agents can assess data quality before acting.61MIT
Try in Browser
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.