Crawlora MCP

bringatrailer_listing

Read-only

Get one Bring a Trailer auction by slug (the /listing/{slug}/ segment or the full listing URL returned by bringatrailer_results and bringatrailer_live). Returns status (sold, reserve_not_met, withdrawn, live or ended), result text, price and currency, end time, bid, comment, view and watcher counts, lot number, seller and seller URL, location, chassis, the listing-details list, description and lead image. bid_history=true adds every bid (amount, currency, time, and any soft-close end-time extension) oldest first, with no bidder names, plus bid_history_complete (true when it holds as many bids as the page reports); it needs no extra request. Comments and bidder identities are never returned.

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": {
      "slug": "<slug>"
    },
    "name": "bringatrailer_listing"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	Yes	Required. Listing slug from a bringatrailer URL (/listing/{slug}/), for example 1978-ford-f-150-122. A full listing URL is also accepted.
`bid_history`	No	Optional. true adds bid_history: every bid with its amount, currency and time, oldest first, without bidder names. Needs no extra upstream request.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / bid_history

Added value: +{
+  "description": "Optional. true adds bid_history: every bid with its amount, currency and time, oldest first, without bidder names. Needs no extra upstream request.",
+  "type": "boolean"
+}

AddedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: it lists returned auction statuses and fields, explains that bid_history returns bids oldest first without bidder names, and states that bid_history_complete is true only when the bid count matches the page. It also explicitly discloses that comments and bidder identities are never returned and that bid history needs no extra request.

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 front-loaded with the primary purpose and remains readable despite dense detail. It is somewhat long because it enumerates many return fields that are also covered by the output schema, but the additional behavioral notes are valuable.

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 output schema, annotations, and 100% schema coverage, the description is complete enough for an agent to call the tool correctly. It covers input source, return content, bid-history behavior, and privacy constraints without needing to restate every schema detail.

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 useful meaning about the bid_history outcome: full bid records, no bidder names, oldest-first ordering, no extra request, and the completeness flag. It also reinforces that slug may be a listing segment or a full URL.

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: get one Bring a Trailer auction by slug. It clearly scopes the tool to a single listing and distinguishes it from the list-oriented siblings by naming the results and live tools as sources of the URL.

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?

Explains how to supply the slug, including that a full listing URL from bringatrailer_results or bringatrailer_live is accepted. It gives clear usage context but does not explicitly say when not to use it versus other Bring a Trailer tools.

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

All Crawlora MCP tools Inspect

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.