Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

bringatrailer_price_history

Retrieve Bring a Trailer auction price history for a make or model, including sold and reserve-not-met summaries, yearly sold prices, and recent dated auction points.

Instructions

Bring a Trailer auction price history. Returns the price chart Bring a Trailer draws for a make or a model: summaries (count, min, median, mean, max) of sold and reserve-not-met final bids, sold prices by closing year, and the most recent auctions as dated points. Exactly one of make and model_id is required; the same filters as bringatrailer_results narrow the chart. Bring a Trailer returns at most the most recent 10,000 auctions, reported as truncated. 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

NameRequiredDescriptionDefault
qNoKeyword that must appear in the listing
eraNoComma-separated decade ids from bringatrailer_filters
makeNoMake name from bringatrailer_makes; exactly one of make and model_id is required
typeNoAuction type
originNoComma-separated origin ids from bringatrailer_filters
countryNoComma-separated ISO 3166-1 alpha-2 country codes
excludeNoKeyword that must not appear in the listing
max_bidNoMaximum final bid in USD
recencyNoClosed within
categoryNoComma-separated category ids from bringatrailer_filters
max_yearNoMaximum model year
min_yearNoMinimum model year
model_idNoNumeric model id from bringatrailer_makes; exactly one of make and model_id is required
points_limitNoMost recent auctions to list in points; 0 returns only the summaries

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

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 the full burden and does a solid job: it discloses the 10,000-auction cap with truncation reporting, a worst-case ~50 second latency for large makes, and what points_limit=0 does. It does not cover error behavior for invalid makes/model ids or whether results are cached, so real gaps remain.

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 what the tool returns, then constraints, then scale limits. Dense but each sentence carries distinct information; the return-shape sentence is long but justified given there is no output schema.

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 tool with no output schema and no annotations, the description compensates well: it describes the return structure (summaries, sold-by-year, dated points), the truncation and latency behavior, and the filter relationship to a sibling. An agent has enough to call it correctly and interpret the response.

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 description coverage is 100%, so baseline is 3, and the description adds a meaningful cross-reference that the filter parameters behave identically to bringatrailer_results, plus the semantics of points_limit=0 returning summaries only. Note it restates the make/model_id exclusivity already stated in the schema, so the added value is modest.

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 ('Returns the price chart Bring a Trailer draws for a make or a model') and then enumerates the three components of the response, which distinguishes it from a listing-search sibling like bringatrailer_results. An agent can tell immediately this is an aggregate/chart tool rather than a raw listing 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?

Gives the key selection constraint ('Exactly one of make and model_id is required') and clarifies that 'the same filters as bringatrailer_results narrow the chart', which implies the two tools share a filter vocabulary. It stops short of an explicit when-to-use-this-instead-of-the-sibling statement, but the context is clear.

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

Deploy Server

Other Tools