Crawlora MCP

bringatrailer_makes

Read-only

List Bring a Trailer's Makes and Models Directory (about 425 makes and 2,300 models). Each model carries the numeric model_id that bringatrailer_results accepts, and each make carries the name that its make filter accepts. q matches make or model names (case-insensitive); make is an exact make slug such as porsche. Call without arguments for the full directory.

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_makes"
  }
}

Input Schema

Name	Required	Description	Default
`q`	No	Optional. Case-insensitive text matched against make and model names.
`make`	No	Optional. Exact make slug (for example porsche) to return a single make with its models.

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.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavior beyond that: the approximate result size, the fact that each record carries a model_id and a make name, and the no-argument default. It does not discuss pagination or ambiguity when q matches multiple makes, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with what the tool is and why the output matters, then parameter notes, then the no-argument default. No filler and nothing redundant.

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 two-optional-parameter lookup tool with an output schema and read-only annotations, the description covers scale, output identifiers, how results feed bringatrailer_results, input semantics, and the zero-argument behavior — everything an agent needs to call it correctly.

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 coverage is 100%, and the description's parameter text ('q matches make or model names (case-insensitive); make is an exact make slug such as porsche') largely restates the schema descriptions verbatim. It adds the downstream significance of the returned identifiers but no new syntax, format, or edge-case semantics for the inputs, so baseline 3 applies.

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 ('List Bring a Trailer's Makes and Models Directory') and quantifies scope ('about 425 makes and 2,300 models'), so an agent immediately knows this is a taxonomy/lookup endpoint rather than a listings endpoint like bringatrailer_results.

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?

Explicitly tells the agent to 'Call without arguments for the full directory' and frames the primary use case: resolving the numeric model_id and make slug that bringatrailer_results consumes. It stops short of naming alternative siblings (e.g. bringatrailer_suggest or bringatrailer_filters) or stating when not to use this tool, so it is strong context without full routing guidance.

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?