Skip to main content
Glama

bringatrailer_search

Read-only

Search Bring a Trailer (q, 2 to 100 characters without double quotes, for example sunroof delete). Returns live listings, make and model pages, previous auctions (sold, reserve_not_met or withdrawn with final prices), past events and editorial stories, each with a total in totals. section is all (default), live_listings, models, previous_auctions, events or stories and pages through one list; lists page 12 rows at a time, previous auctions 24, and live listings (up to 100, live_listings_truncated when cut) come back only on page 1. A term that is exactly a make, model or category name (Ferrari, BMW 2002, boat) makes the site redirect to that page: the response then has redirect and empty lists, and phrase=true searches instead. Member profiles are never returned. Use models[].make and models[].model with bringatrailer_makes, and a previous auction's url with bringatrailer_listing.

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": {
      "q": "<q>"
    },
    "name": "bringatrailer_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
qYesRequired. Text to search, 2 to 100 characters without double quotes (for example turbo or sunroof delete).
pageNoOptional. Page number from 1. Every list pages 12 rows at a time; live_listings is not paged.
phraseNoOptional. true matches the text as an exact phrase. Needed when q is exactly a make, model or category name (for example Ferrari or BMW 2002), because the site otherwise redirects those to the make, model or category page and the response carries redirect instead of results.
sectionNoOptional. all (default), live_listings, models, previous_auctions, events or stories. A single section pages through only that list.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, and the description adds substantial behavior beyond them: per-section page sizes, that live listings are capped at 100 and flagged via live_listings_truncated, that live listings appear only on page 1, and that a redirect response carries empty lists. These are non-obvious runtime traits an agent could not infer from the schema or 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?

Front-loaded with the query constraint and the return contents, then behavior, then routing hints — a sensible order. It is a single dense run-on paragraph, and the paging and redirect clauses take a second read to parse, but every sentence carries operational information rather than filler.

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?

Despite an output schema existing, the description still covers what an agent needs to call it correctly: pagination behavior per section, truncation signaling, the redirect edge case and the empty-list consequence, plus where to send make/model and auction urls next. Nothing material about invoking this search is left unstated.

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 goes further by explaining why phrase exists (redirect on exact make/model terms) and by giving section-specific paging detail not in the schema (previous auctions page 24 while other lists page 12). That adds real meaning beyond the structured fields, though it introduces a minor inconsistency with the schema's 'every list pages 12 rows' wording.

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?

States a specific verb and resource ('Search Bring a Trailer') and enumerates what the search covers: live listings, make/model pages, previous auctions, events and stories. It differentiates partially by noting it returns multiple sections at once and routing make/model output to bringatrailer_makes and auction urls to bringatrailer_listing, but it never contrasts itself with bringatrailer_results, bringatrailer_live or bringatrailer_filters, so the sibling boundary is left partly implicit.

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 concrete usage context: section defaults to 'all', phrase=true is the escape hatch when q is exactly a make/model/category name because the site otherwise redirects, and member profiles are never returned. It stops short of an explicit 'use X instead of this tool when...' comparison against the other Bring a Trailer siblings, so alternatives are only partly addressed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.