What can you do with this server?

nexusfeed-mcp provides real-time LTL freight fuel surcharge data and US state ABC liquor license compliance records to AI agents via the Model Context Protocol. LTL Freight Tools: * ltl_get_fuel_surcharge — Current weekly fuel surcharge percentages for major carriers (ODFL, Saia, Estes, ABF, R+L, TForce, XPO, SEFL, Averitt), including the DOE diesel price that triggered each rate and up to 5 years of history * ltl_list_carriers — Metadata for all supported LTL carriers: SCAC codes, available data products, update schedules, and extraction methods * ltl_get_accessorials (coming soon) — Accessorial fee schedules (liftgate, residential delivery, re-delivery, etc.) — not yet available ABC Liquor License Tools: * abc_search_licenses — Search CA, TX, NY, and FL ABC license databases by trade name, owner name, or address; returns license type, status (ACTIVE/SUSPENDED/EXPIRED/REVOKED), expiration date, and suspension history * abc_lookup_license — Point-in-time lookup of a specific license by state-issued license number * abc_list_states — State coverage metadata: agency name, data freshness SLA, extraction method, and CAPTCHA requirements Key Features: * Every response includes a _verifiability block with extraction timestamp, confidence score, source URL, and freshness TTL for data quality assessment * Extracts data from JS-rendered pages, PDFs, and CAPTCHA-protected portals inaccessible to raw LLM browsing * Built-in workflow prompts: freight_audit_workflow for LTL invoice auditing and license_compliance_check for multi-state compliance verification * Response times <500ms for cached data; freemium access with 10 requests/day free tier

Which integrations are available for this server?

Provides API access via RapidAPI subscriptions for LTL fuel surcharge and ABC license compliance data, enabling integration with external systems through RapidAPI marketplace listings.

de en es ja ko ru zh

nexusfeed-mcp

Q: Which integrations are available for this server?

Provides API access via RapidAPI subscriptions for LTL fuel surcharge and ABC license compliance data, enabling integration with external systems through RapidAPI marketplace listings.

by NexusFeed

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

nexusfeed-mcp

PyPI version Python 3.12+ License: MIT

Real-time LTL freight fuel surcharge rates and US state ABC liquor license compliance records — served as normalized, verifiable JSON for AI agents via the Model Context Protocol.

Data is extracted from carrier tariff pages and state ABC portals (JS-rendered, CAPTCHAs, session state) that are structurally inaccessible to raw LLM browsing. Every response includes a _verifiability block — extraction timestamp, confidence score, and source URL — so agents can assess data quality before acting.

Tools

Tool	Description
`ltl_get_fuel_surcharge`	Weekly fuel surcharge % for ODFL, Saia, Estes, ABF, R+L, TForce, XPO, SEFL, Averitt — DOE diesel price and up to 5 years of history
`ltl_list_carriers`	Carrier coverage metadata (SCAC codes, update schedule, extraction method)
`abc_search_licenses`	Search CA, TX, NY, FL license databases by trade name, owner, or address
`abc_lookup_license`	Point-in-time license status by state-issued license number
`abc_list_states`	State coverage, latency, and CAPTCHA requirements

Related MCP server: us-legal-mcp

Workflow Prompts

Prompt	Description
`freight_audit_workflow`	Multi-step LTL invoice audit against published carrier tariffs
`license_compliance_check`	Compliance verification before distributor orders, insurance binding, or merchant onboarding

Get API Access

Subscribe via RapidAPI to receive your X-API-Key. Freemium plans available (10 req/day free).

Product	RapidAPI Listing
LTL Fuel Surcharge	rapidapi.com/ladourv/api/ltl-fuel-surcharge-api
ABC License Compliance	rapidapi.com/ladourv/api/abc-license-compliance-api

Install

pip install nexusfeed-mcp
# or with uv/uvx (no install needed):
uvx nexusfeed-mcp

Configure

export MCP_API_BASE_URL=https://api.nexusfeed.dev
export MCP_API_KEY=sk_live_your_key_here

Run (stdio)

# LTL tools only — 3 tools, 1 prompt
nexusfeed-ltl

# ABC tools only — 3 tools, 1 prompt
nexusfeed-abc

# All tools — 5 tools, 2 prompts
nexusfeed-mcp

Claude Desktop Configuration

LTL fuel surcharge only:

{
  "mcpServers": {
    "nexusfeed-ltl": {
      "command": "uvx",
      "args": ["--from", "nexusfeed-mcp", "nexusfeed-ltl"],
      "env": {
        "MCP_API_BASE_URL": "https://api.nexusfeed.dev",
        "MCP_API_KEY": "sk_live_your_key_here"
      }
    }
  }
}

ABC license compliance only:

{
  "mcpServers": {
    "nexusfeed-abc": {
      "command": "uvx",
      "args": ["--from", "nexusfeed-mcp", "nexusfeed-abc"],
      "env": {
        "MCP_API_BASE_URL": "https://api.nexusfeed.dev",
        "MCP_API_KEY": "sk_live_your_key_here"
      }
    }
  }
}

All tools:

{
  "mcpServers": {
    "nexusfeed-mcp": {
      "command": "uvx",
      "args": ["nexusfeed-mcp"],
      "env": {
        "MCP_API_BASE_URL": "https://api.nexusfeed.dev",
        "MCP_API_KEY": "sk_live_your_key_here"
      }
    }
  }
}

Cline (VS Code) Configuration

Open Cline settings → MCP Servers → Add Server manually:

LTL only:

{
  "nexusfeed-ltl": {
    "command": "uvx",
    "args": ["--from", "nexusfeed-mcp", "nexusfeed-ltl"],
    "env": {
      "MCP_API_BASE_URL": "https://api.nexusfeed.dev",
      "MCP_API_KEY": "sk_live_your_key_here"
    }
  }
}

ABC only:

{
  "nexusfeed-abc": {
    "command": "uvx",
    "args": ["--from", "nexusfeed-mcp", "nexusfeed-abc"],
    "env": {
      "MCP_API_BASE_URL": "https://api.nexusfeed.dev",
      "MCP_API_KEY": "sk_live_your_key_here"
    }
  }
}

Streamable HTTP (Smithery / remote clients)

Server	URL
LTL tools	`https://api.nexusfeed.dev/mcp-ltl/`
ABC tools	`https://api.nexusfeed.dev/mcp-abc/`

Pass your X-API-Key header on every request. Server metadata (no auth):

https://api.nexusfeed.dev/.well-known/mcp/server-card-ltl.json
https://api.nexusfeed.dev/.well-known/mcp/server-card-abc.json

Verifiability

Every tool response includes:

"_verifiability": {
  "source_timestamp": "2026-04-05T09:00:00Z",
  "extraction_confidence": 0.97,
  "raw_data_evidence_url": "https://odfl.com/...",
  "extraction_method": "api_mirror",
  "data_freshness_ttl_seconds": 604800
}

extraction_confidence >= 0.90 is required before using data in compliance-critical decisions
source_timestamp within data_freshness_ttl_seconds means data is fresh from cache
raw_data_evidence_url is the canonical source — agents can independently verify

Example Usage

Audit an LTL freight invoice:

Use the freight_audit_workflow prompt with carrier="ODFL", invoice_date="2026-04-01",
invoiced_fuel_surcharge_pct="23.5" to check whether the billed rate matches the
published tariff.

Verify a liquor license before a distributor transaction:

Use abc_search_licenses with state="CA" and trade_name="Total Wine" to check
current license status, then abc_lookup_license for the full record with suspension history.

Troubleshooting

Symptom	Fix
401 on every call	`MCP_API_KEY` is not set or is invalid
"Could not reach API server"	`MCP_API_BASE_URL` not set — should be `https://api.nexusfeed.dev`
TX endpoints return 503	TX TABC requires 2Captcha configured server-side; use CA, NY, or FL instead
`extraction_confidence` < 0.90	Data quality degraded — verify independently via `raw_data_evidence_url`

License

Client code (this repository): MIT. See LICENSE.

NexusFeed backend service (https://api.nexusfeed.dev): commercial. The MIT license above covers only the Python client wrapper in this repo. It does not grant rights to the data service, which requires a paid API key and is governed by a separate Terms of Service. Contact ops@nexusfeed.dev for enterprise SLA and licensing.

Available Tools

6 tools

abc_list_statesA

Returns metadata for all US states currently supported by the ABC License API, including the agency name, data freshness SLA, extraction method, and whether CAPTCHA is present. Use this first when building a multi-state compliance workflow to understand coverage.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It describes the return content adequately but does not disclose any side effects, authentication needs, or rate limits. For a stateless, read-only list tool, this is acceptable but not exemplary.

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?

Two concise sentences: first states action and content, second provides usage guidance. No extraneous words, front-loaded with 'Returns metadata.' Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameterless tool with an output schema, the description covers the main purpose and usage context. It lists example output fields and advises initial use. However, it could mention if the output contains all fields from the schema or if authentication is required, but overall adequate.

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 tool has zero parameters, so no parameter information is needed. The schema coverage is 100% trivially. The description adds value by detailing the output fields, which is beyond the schema's scope, earning a high score.

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 it returns metadata for all supported US states, listing specific fields (agency name, SLA, extraction method, CAPTCHA). The phrase 'Use this first' distinguishes it from siblings like abc_lookup_license, establishing its role as a preliminary overview tool.

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 advises using this tool first when building a multi-state workflow to understand coverage. It gives a clear context of use but does not elaborate on when not to use it or provide alternatives beyond the implied sibling relationship.

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

abc_lookup_licenseA

Looks up a specific liquor license by its state-issued license number and returns the full current record including status, expiration, address, conditions, and suspension history. Faster and more precise than abc_search_licenses when you already have the license number. Use this for point-in-time verification (e.g., 'Is license CA-20-621547 currently ACTIVE?'). The _verifiability block contains the exact source URL — agents can independently verify the result by fetching that URL.

ParametersJSON Schema

Name	Required	Description	Default
`license_number`	Yes
`state`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

No annotations provided, but description fully discloses behavioral details: returns full current record with specific fields, mentions speed advantage, and reveals the _verifiability block for independent verification.

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?

Three efficient sentences, no filler, front-loaded with action and resource, each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, alternative, use case, and verifiability. Missing error handling or prerequisites, but for a lookup tool with output schema, this is near-complete.

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 has 0% description coverage, but description adds context by referring to 'state-issued license number' and implies state parameter. Could add format examples, but overall adds meaning beyond 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 verb 'looks up' and the resource 'specific liquor license by its state-issued license number', and explicitly contrasts with sibling abc_search_licenses, making it distinct.

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?

Provides explicit guidance on when to use (when license number is known) and not to use (use abc_search_licenses otherwise), plus a concrete use case for point-in-time verification.

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

abc_search_licensesA

Searches a US state ABC (Alcoholic Beverage Control) board database for liquor licenses matching a business name, owner name, or address. Returns license type, current status (ACTIVE / SUSPENDED / EXPIRED / REVOKED), expiration date, and any suspension history. Use this before approving a distributor order, binding an insurance policy, or onboarding a merchant to verify they hold a valid liquor license. Supports CA, TX, NY, and FL (TX requires TWOCAPTCHA_API_KEY configured server-side; NY uses NY Open Data API — active licenses only; FL searches the DBPR licensing portal across all board types). Always check the _verifiability block: extraction_confidence >= 0.90 and source_timestamp within data_freshness_ttl_seconds are required for compliance decisions. Note: city, county, zip, and license_status filters are accepted but not yet applied server-side — results may need post-filtering.

ParametersJSON Schema

Name	Required	Description	Default
`state`	Yes
`trade_name`	No
`owner_name`	No
`address`	No
`city`	No
`county`	No
`zip`	No
`license_status`	No
`include_inactive`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully carries the transparency burden. It discloses that city/county/zip/license_status filters are accepted but not applied server-side, state-specific API variations, and the need to check the verifiability block for compliance. It also notes the output includes license type, status, expiration, and suspension history.

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 a single paragraph that efficiently front-loads the main purpose and then provides use cases, state notes, and caveats. Every sentence adds value, though it could be slightly more structured (e.g., bullet points for parameters) to improve readability.

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 (multiple states, varying APIs, filter limitations, compliance requirements), the description covers all necessary aspects: operation, usage context, state-specific behaviors, parameter limitations, and output fields. The presence of an output schema reduces the need to document return values, but the description still mentions key output fields.

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 has 0% description coverage, so the description must add parameter meaning. It explains that city/county/zip/license_status are not applied server-side, and specifies that trade_name, owner_name, address are search criteria. While not describing each parameter exhaustively, it adds valuable context beyond the bare schema titles.

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 searches US state ABC board databases for liquor licenses by business name, owner name, or address. It specifies the resource (licenses), action (searches), and scope (specific states and use cases), which distinguishes it from siblings like abc_lookup_license (likely a direct lookup) and abc_list_states (likely listing supported states).

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 concrete use cases ('before approving a distributor order, binding an insurance policy, or onboarding a merchant') and state-specific requirements (e.g., TX requires TWOCAPTCHA_API_KEY, NY only active licenses). However, it does not explicitly tell when to use this tool over siblings like abc_lookup_license, though the context implies it for name/address searches.

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

ltl_get_accessorialsB

[COMING SOON] Returns the current accessorial fee schedule for LTL carriers — liftgate, residential delivery, re-delivery, inside delivery, limited access, notification, appointment fees, and more. This tool is not yet available and will return an unavailability message. Use ltl_get_fuel_surcharge for current carrier data.

ParametersJSON Schema

Name	Required	Description	Default
`carriers`	No
`fee_types`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior4/5

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

No annotations are present, so the description bears full responsibility. It discloses that the tool is not yet available and will return an unavailability message, which is important behavioral context. No other traits like auth or side effects are mentioned, but the core constraint is clearly stated.

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 brief with two major sentences plus the coming-soon tag. It front-loads the purpose. While concise, the '[COMING SOON]' marker could be placed after the description for better flow. Overall, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a not-yet-available tool with an output schema, the description adequately explains its intended function, current unavailability, and directs to a sibling alternative. It lacks parameter details and output content hints, but given the 'coming soon' status, the context is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description provides no explanation of the two parameters (carriers and fee_types). It does not clarify allowed values, formats, or how they influence the output, leaving the agent without meaningful guidance beyond the schema's type information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the current accessorial fee schedule for LTL carriers, listing examples like liftgate and residential delivery. It distinguishes from sibling tool ltl_get_fuel_surcharge. However, the '[COMING SOON]' prefix may temporarily confuse about availability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises 'Use ltl_get_fuel_surcharge for current carrier data', providing a specific alternative. It implies this tool is for accessorials but does not explicitly state when to use it over other tools or that it is currently unavailable for actual queries.

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

ltl_get_fuel_surchargeA

Returns current LTL carrier fuel surcharge percentages and the DOE diesel price that triggered each rate. Data is extracted weekly from carrier tariff pages and cached — response time <500ms. Use this instead of browsing carrier websites: those pages are JS-rendered, PDFs, or require session state that makes raw browsing unreliable. Covers ODFL and SAIA (Sprint 1-2); Estes, ABF, R+L, TForce arriving in Sprint 4. Each response includes a _verifiability block with extraction timestamp and confidence score — check this before using the data in a freight cost calculation or invoice audit.

ParametersJSON Schema

Name	Required	Description	Default
`carriers`	No
`weeks`	No
`include_doe_price`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. It thoroughly discloses caching (<500ms), weekly extraction, data source (tariff pages), carrier coverage, and verifiability block, with no contradictions to 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?

Description is information-dense and front-loaded with core purpose, but a bit lengthy and includes future sprint plans which could be separated. Nonetheless, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite thorough behavior description, the complete absence of parameter explanations creates a significant gap in completeness, especially with 0% schema coverage and no annotations to fall back on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter descriptions in schema). Description fails to explain any of the three parameters (carriers, weeks, include_doe_price), leaving the agent without necessary usage 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?

Description clearly states the tool returns LTL fuel surcharge percentages with DOE diesel price, and explicitly distinguishes from browsing carrier websites, which is a specific verb+resource with sibling differentiation.

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?

Explicitly states when to use (instead of browsing unreliable carrier websites) and mentions caching and carrier coverage scope, though lacks explicit when-not-to-use conditions.

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

ltl_list_carriersA

Returns metadata for all LTL carriers supported by this API, including their SCAC code, which data products are available, fuel surcharge update day, and extraction method. Use this to discover coverage before building a carrier comparison workflow.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden of disclosure. It accurately describes the tool as returning metadata with no side effects, which is sufficient for a read-only list operation. No contradictions or omissions noted.

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?

Two concise sentences, front-loaded with the primary action and resource, no redundant information.

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 adequately covers the tool's purpose, output content, and usage context given its simplicity (no parameters, has output schema). It mentions specific fields and provides a use case, making it complete for an agent.

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?

There are no parameters (0 params = baseline 4). The description adds value by detailing what the output contains, though it doesn't need to explain parameters since none exist.

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 it returns metadata for all LTL carriers, listing specific fields (SCAC code, data products, etc.), which directly answers what the tool does and distinguishes it from siblings like ltl_get_accessorials.

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 advises to use this tool 'to discover coverage before building a carrier comparison workflow,' providing clear context for when to use it, though it does not specify when not to use it.

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.

6 tool updatesApr 13, 2026
- First observedabc_list_states
- First observedabc_lookup_license
- First observedabc_search_licenses
- First observedltl_get_accessorials
- First observedltl_get_fuel_surcharge
- First observedltl_list_carriers

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-04-29 21:40 across 6 tools

Disambiguation5/5

Each tool targets a distinct domain and action: ABC tools handle license verification (list states, search by business, lookup by license number), while LTL tools cover carrier information (list carriers, fuel surcharge, accessorials). Clear descriptions prevent confusion.

Naming Consistency5/5

All tool names follow a consistent 'domain_verb_noun' pattern in snake_case (abc_list_states, ltl_get_fuel_surcharge). The naming is predictable and uniform across both domains.

Tool Count4/5

Six tools is a reasonable count for the two domains. However, one tool (ltl_get_accessorials) is non-functional (returns 'coming soon'), slightly reducing its value. Still, the count is appropriate for the scope.

Completeness3/5

The ABC domain is well-covered with list, search, and lookup operations. The LTL domain has a gap: accessorial fees are not yet available. Additionally, abc_search_licenses notes that some filters are not applied server-side, limiting its completeness.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

freight-intel A
com.dropwatchhq
Freight carrier intel: new FMCSA authority feed, carrier lookup by DOT/MC, safety screen (CSA/SMS).
Government Data Travel & Transportation
92
Govparse Government Data Gateway A
io.govparse
Pay-per-call US government data: carrier safety, visa sponsors, contracts, employer risk.
Government Data Open Data Research & Data
822
UNITECARGO U.S. Logistics Provider Directory
com.unitecargo
Verified U.S. logistics provider search with canonical profiles, freshness, and read-only tools.
Travel & Transportation Search
1
ANTT: Calcular Piso Mínimo de Frete A
io.github.mcp-dir
ANTT: Calcular Piso Mínimo de Frete, official-source lookup. Platform-hosted, pay per query with pre
Government Data
71

Related MCP Servers

Aviationstack MCP Server
Travel & Transportation Search
Pradumnasaraf
A
license
B
quality
B
maintenance
An MCP server using the AviationStack API to fetch real-time flight data, including airline flights, airport schedules, future flights and aircraft types.
Updated 8 days ago (2026-09-02 20:17 UTC)
12
25
MIT
us-legal-mcp
Government Data Legal & Compliance Search
JamesANZ
A
license
Not graded
quality
F
maintenance
An MCP server that provides comprehensive US legislation.
Updated 5 months ago (2026-04-20 03:40 UTC)
13
37
MIT
Verilex Data
Government Data Legal & Compliance Research & Data
carrierone
A
license
B
quality
C
maintenance
Query 20 structured datasets from AI agents — healthcare providers (9M NPI records), SEC EDGAR filings, PACER federal courts, USPTO patents and trademarks, OFAC sanctions screening, crypto whale wallets, DeFi liquidation signals, Polymarket smart money, economic indicators (FRED/BLS), federal contracts, NOAA weather, and OTC shell risk scoring. Pay per query, no subscriptions
Updated 6 months ago (2026-03-18 09:25 UTC)
75
1
MIT
hazmat-cfr-mcp
Legal & Compliance Government Data
andretaki
A
license
Not graded
quality
B
maintenance
Enables AI agents to look up and validate hazardous materials shipping descriptions using public 49 CFR citations, providing structured JSON with proper shipping names, hazard classes, labels, and regulatory references.
Updated 10 days ago (2026-09-01 17:10 UTC)
69
1
MIT

Appeared in Searches

A server for finding information about USA logistics