TruckerFetch MCP

Official

Overview Schema Source Related Servers Discussions Admin

request_export

Request a pinned CSV export of carrier data by scope and filters, then follow the owner approval link and repeat with the same idempotency key to retrieve it.

Instructions

Request a pinned CSV export. Follow the owner approval link and repeat with the same key. The local REST bridge additionally requires confirm_action=true after user approval.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "selection": "<selection>",
      "idempotency_key": "<idempotency_key>",
      "confirm_action": "<confirm_action>"
    },
    "name": "request_export"
  }
}

Input Schema

Name	Required	Description
`selection`	Yes
`confirm_action`	Yes	Local bridge only: confirm this exact mutation with the user before setting true.
`idempotency_key`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 6, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), the description discloses two non-obvious behaviors: an out-of-band owner approval gate and an idempotency-key replay requirement. It still doesn't say whether an unapproved request is queued, rejected, or returns a link, nor how the export is later retrieved.

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?

Three short, front-loaded sentences with no filler; the approval workflow precedes the environment-specific caveat. The phrasing is compressed to the point of ambiguity ("repeat" with what payload, alongside which other arguments).

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

Completeness3/5

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

For a mutation with a nested selection schema, an approval gate, and no output schema, the description covers the approval/idempotency mechanics but leaves the selection model and the return value (export id? approval link? status?) unexplained. It is adequate to attempt the call, not to construct a correct selection.

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 description coverage is only 33% (only confirm_action carries a description), and the description meaningfully extends idempotency_key semantics by requiring the same key on retry. However the largest and most complex parameter, the nested `selection` object with scope enum, list_id/edition_id/window_days/date_basis and fifteen filter fields, receives no explanation at all.

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 first sentence gives a specific verb and resource ("Request a pinned CSV export") and the word "pinned" signals a snapshot artifact rather than a live query. It does not name or distinguish the obvious sibling get_export, so an agent must infer that this creates the request and that one retrieves it.

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 embeds a real procedural workflow: complete the owner approval step, then re-issue the request with the same idempotency key, and on the local bridge set confirm_action=true only after user approval. That is useful when-to-use context, but it never states when to prefer this over get_export or what to do if approval is denied or pending.

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