Crawlora MCP

bringatrailer_price_history

Read-only

Price history of a Bring a Trailer make or model: count, min, median, mean and max of sold and reserve-not-met final bids, sold prices by closing year, and the most recent auctions as dated points (points_limit 0 to 1000, default 100). Exactly one of make (a name from bringatrailer_makes) and model_id (from bringatrailer_makes) is required; q, exclude, category, era, origin, country, type, recency, min_year, max_year and max_bid narrow it like bringatrailer_results. Bring a Trailer returns only the most recent 10,000 auctions; truncated is true when the cap was hit. Large makes can take up to about 50 seconds.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "bringatrailer_price_history"
  }
}

Input Schema

Name	Required	Description
`q`	No	Optional. Keyword that must appear in the listing.
`era`	No	Optional. Comma-separated decade ids from bringatrailer_filters.
`make`	No	Make name exactly as listed by bringatrailer_makes (for example Porsche). Exactly one of make and model_id is required.
`type`	No	Optional. premium or noreserve.
`origin`	No	Optional. Comma-separated origin ids from bringatrailer_filters.
`country`	No	Optional. Comma-separated ISO 3166-1 alpha-2 country codes.
`exclude`	No	Optional. Keyword that must not appear in the listing.
`max_bid`	No	Optional. Maximum final bid in USD.
`recency`	No	Optional. Closed within: 7D, 30D, 1Y, 2Y or 5Y.
`category`	No	Optional. Comma-separated category ids from bringatrailer_filters.
`max_year`	No	Optional. Maximum model year (1885 to 2100).
`min_year`	No	Optional. Minimum model year (1885 to 2100).
`model_id`	No	Numeric model id from bringatrailer_makes. Exactly one of make and model_id is required.
`points_limit`	No	Optional. Most recent auctions to list in points, 0 to 1000. Defaults to 100; 0 returns only the summaries.

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.

AddedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond readOnlyHint and openWorldHint, it discloses non-obvious behavior: the 10,000-auction cap with a 'truncated' flag when hit, and that large makes can take about 50 seconds. Those are exactly the operational facts an agent needs to set expectations and avoid retries, and nothing contradicts the 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?

A single front-loaded paragraph that moves from what is returned to input constraints to operational caveats. Every clause carries information; it is dense but not padded, though the long filter enumeration slows reading slightly.

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?

For a 14-parameter aggregating tool with an output schema, the description covers return content, input exclusivity, source of enum-like values, truncation behavior, and latency. Nothing an agent needs to call it correctly is missing.

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; the description earns extra by adding cross-parameter meaning the schema lacks: the mutually exclusive make/model_id rule, that points_limit defaults to 100 and that 0 returns only summaries, and that values must come from bringatrailer_makes.

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 ('Price history of a Bring a Trailer make or model') and enumerates what the payload contains (count, min, median, mean, max, sold-by-year, recent points). This clearly separates it from bringatrailer_results and bringatrailer_listing, which return individual auctions rather than aggregates.

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?

It gives the hard selection rule ('Exactly one of make and model_id is required'), points to bringatrailer_makes as the source of valid values, and explains that the remaining filters 'narrow it like bringatrailer_results'. It does not explicitly state when to prefer this over bringatrailer_results, but the aggregate-vs-list distinction is implied clearly enough.

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.

Resources

Need Help?