Skip to main content
Glama
Sign In

LiveDataLink

by io.github.blackboxfoundry
OverviewDiscussionsAdmin

carrier_vetting_evidence_pack

Read-onlyIdempotent

Produce a dated public-carrier evidence record for a human reviewer. Prefer an exact USDOT; existing MC and name inputs remain supported, with name matches requiring manual identity confirmation. Returns allowlisted FMCSA facts, explicit missing/unavailable source states, field dates separate from retrieval time, deterministic official source links, and separate human follow-up tasks. Export markdown (default), JSON, or printable HTML. No safety/booking verdict or verified-insurance claim; unavailable data is never a clean result.

Input Schema

NameRequiredDescriptionDefault
mcNoMC/MX number without the prefix.
dotNoUSDOT number (preferred exact identifier).
nameNoLegal carrier name when DOT/MC is unavailable.
formatNoRecord export format; HTML is a standalone printable document, not a hosted link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
+  "description": "Record export format; HTML is a standalone printable document, not a hosted link.",
+  "enum": [
+    "markdown",
+    "json",
+    "html"
+  ],
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / dot / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / properties / mc / type
      Previous value: -"number"New value: +"integer"
  3. Changed4 schema fields changed
    • changedInput schema / properties / dot / description
      Previous value: -"USDOT number (preferred). Accepts 3405079 or USDOT 3405079."New value: +"USDOT number (preferred exact identifier)."
    • changedInput schema / properties / dot / type
      Previous value: -[
-  "number",
-  "string"
-]New value: +"number"
    • changedInput schema / properties / mc / description
      Previous value: -"MC/MX number. Accepts 123456 or MC-123456."New value: +"MC/MX number without the prefix."
    • changedInput schema / properties / mc / type
      Previous value: -[
-  "number",
-  "string"
-]New value: +"number"
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds rich behavior beyond them: allowlisted FMCSA facts, explicit missing/unavailable source states, field dates separated from retrieval time, deterministic source links, separate human follow-up tasks, and the caveat that unavailable data is never a clean result.

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?

Four sentences, front-loaded with the core purpose and packed with information; each sentence carries distinct content (inputs, returns, formats, limitations). Dense but not padded.

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?

With no output schema, the description does the work of describing returns (allowlisted facts, source states, dates, links, follow-up tasks) plus export formats and limitations. Covers purpose, inputs, outputs, and constraints adequately; only the routing-vs-siblings context is thin.

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 the baseline is 3, but the description adds value the schema lacks: the USDOT-over-MC/name preference, the manual identity confirmation caveat for name matches, and the 'markdown (default)' export default.

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?

States a specific verb and resource ('Produce a dated public-carrier evidence record') and clarifies the audience ('for a human reviewer'). It explicitly disclaims what it is NOT ('No safety/booking verdict or verified-insurance claim'), which distinguishes it from the carrier_vetting_score sibling.

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?

Gives clear context ('for a human reviewer') and input-selection guidance ('Prefer an exact USDOT; existing MC and name inputs remain supported'). It does not explicitly name or route against alternatives like carrier_vetting_batch, carrier_vetting_score, or carrier_monitor_recheck, so it stops short of a 5.

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

All LiveDataLink toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources