Skip to main content
Glama

Generate Montgomery Evidence File

montgomery_file
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNo"text" = filing-ready report (free tier); "json" = structured fields (requires API key)text
dot_numberYesUS DOT number of the carrier, digits only (e.g. "1234567")

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
flagsNo
reportNoReport title line (format="json")
sha256NoPaid tiers: SHA-256 of the archived plain-text report — cite it alongside the entry id
indicesNo
dba_nameNo
compositeNo
generatedNoReport generation date (YYYY-MM-DD)
surchargeNo
base_scoreNo
componentsNo
crash_riskNov0.5: crash risk index with components and validation
disclaimerNo
dot_numberNo
legal_nameNo
power_unitsNo
report_textNoFiling-ready plain-text evidence report (format="text")
status_codeNo
sub_indicesNo
scored_as_ofNo
carrier_scoreNo0-100, higher = riskier (v0.5: == legacy_composite.score)
safety_ratingNo
score_versionNo
audit_entry_idNoPaid tiers: id of the immutable archived copy of this report (use with verify_evidence / audit_entries)
inspection_riskNov0.5: inspection / compliance risk index with components and validation
data_sufficiencyNo
legacy_compositeNov0.5: legacy composite, backward compatibility only
methodology_noteNo

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.

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.