Skip to main content
Glama

Apibara Vehicle Auction Data

by tech.apibara
OverviewDiscussionsAdmin

Server Details

Read-only MCP for Copart and IAA/IAAI search, history, filters, locations, shipping, and usage.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.8% over 23 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored across 8 tools

Disambiguation5/5

Descriptions explicitly delineate boundaries: search_auction_vehicles for broad discovery, get_vehicle for known VIN/lot, get_vehicle_history for retained auction appearances, and get_related_vehicles for comparison. The get_vehicle vs history vs search triad is clearly separated, and calculate_shipping vs list_auction_locations is distinguished.

Naming Consistency5/5

All eight tools follow a consistent snake_case verb_noun pattern (calculate_shipping, get_vehicle, list_auction_locations, search_auction_vehicles). No mixed conventions or vague verbs.

Tool Count5/5

Eight tools is well-scoped for a read-oriented vehicle auction data API, with each tool earning a distinct place (search, fetch, history, related, filters, locations, shipping, quota).

Completeness4/5

The surface covers discovery, single-record retrieval, history, related records, filter metadata, location resolution, and shipping pricing, which is strong for a data API. Minor gaps exist around auction/bid detail or broader sale listings, but core read workflows are covered.

Available Tools

8 tools
calculate_shippingCalculate auction-to-port shippingA
Read-onlyIdempotent
Inspect

Use when the user asks for supported auction-to-port shipping pricing for a known vehicle. Supply either VIN or lot_number; optionally narrow the destination with port or port_id. Availability depends on auction location and route data.

ParametersJSON Schema
NameRequiredDescriptionDefault
vinNoVehicle Identification Number. Provide this or lot_number.
portNoOptional destination port name supported by the shipping endpoint.
port_idNoOptional destination port identifier when known.
lot_numberNoAuction lot number. Provide this or vin.

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat those. It adds valuable context by noting 'Availability depends on auction location and route data,' which is a behavioral constraint beyond what annotations convey. This enriches the agent's understanding of potential failure or limitation.

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?

The description is three concise sentences, all relevant and front-loaded with the usage trigger. It contains no fluff, and every sentence adds value—usage condition, input requirements, and an availability caveat. It is appropriately sized for the tool's complexity.

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 tool has an output schema and only 4 parameters, the description covers all necessary invocation details: when to use, what inputs to supply, and a caveat about availability. Nothing critical is missing, and the output schema handles return value expectations.

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 description coverage is 100%, so all parameters are documented in the schema. The description repeats the essential choice between VIN and lot_number and mentions optional port/port_id, but it adds no deeper semantic detail (e.g., precedence, format constraints, or how port_id relates to port). This is baseline for high schema coverage.

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?

The description clearly states the tool calculates shipping pricing for a known vehicle to a port, using a specific verb and resource. It distinguishes from siblings like get_vehicle or search_auction_vehicles by focusing on shipping, and it specifies the input requirements (VIN or lot number).

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?

The description explicitly says 'Use when the user asks for supported auction-to-port shipping pricing for a known vehicle,' providing a clear trigger condition. It also mentions optional narrowing with port or port_id, but it does not explicitly list when not to use it or alternatives. However, since siblings are unrelated to shipping, the guidance is sufficient.

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

get_api_usageGet API usageA
Read-onlyIdempotent
Inspect

Use to inspect request usage and current plan limits for the supplied X-API-Key. This is account/API-quota metadata, not vehicle data.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by specifying the data type (account/API-quota metadata) and tying it to the X-API-Key, which gives agents a better mental model of what the response will contain without relying solely on the output schema.

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?

The description is only two sentences and front-loads the primary use case ('Use to inspect...'). The second sentence proactively prevents category confusion, and every word contributes meaning.

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 tool's simplicity (no parameters), the presence of a full output schema, and thorough annotations, the description is complete. It clearly explains the resource being queried, disambiguates from siblings, and leaves no operational gaps.

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?

The tool has zero parameters, so there is nothing for the description to add beyond what the empty input schema already shows. The baseline for a no-parameter tool is 4, and the description does not introduce any unnecessary parameter-related details.

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?

The description names a specific verb ('inspect'), the resource ('request usage and current plan limits'), and the relevant credential ('supplied X-API-Key'). It also explicitly excludes vehicle data, which clearly distinguishes it from the vehicle-related sibling tools.

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?

The description gives a clear purpose and a negative discriminator ('not vehicle data'), making it obvious when to use this tool instead of the vehicle-focused siblings. However, it does not name specific alternative tools or provide more granular when-not conditions, so it falls short of a 5.

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

get_vehicleGet vehicleA
Read-onlyIdempotent
Inspect

Use when the user already has a VIN, lot number or supported slug and needs the current normalized vehicle record. Request include history and/or vin_lots when the same tool call should also return retained sale history or other known auction lots for the same VIN.

ParametersJSON Schema
NameRequiredDescriptionDefault
includeNoOptional related data to embed in the vehicle detail result.
identifierYesVIN, lot number or slug_vin accepted by the canonical vehicle detail endpoint.

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo

TDQS

A4/5.0
Behavior3/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description carries less burden. It adds useful context about accepted identifier types and optional inclusion of history or vin_lots, but does not explain normalization behavior, errors, or what 'retained sale history' means in practice.

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?

Two sentences with no fluff. The primary use condition is front-loaded, and the optional include behavior is explained in the second sentence without repeating schema details.

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-parameter read tool with full schema coverage, a rich output schema, and strong annotations, this description is complete. An agent has enough context to decide when to call it and what parameters to provide.

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 real meaning beyond the schema: it clarifies that identifier accepts VIN, lot number, or supported slug, and that include history/vin_lots controls whether additional related data is returned in the same call.

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?

The description clearly states the tool retrieves a current normalized vehicle record using an identifier the user already has, with optional embedded history or lot data. It distinguishes itself from search-oriented siblings by requiring an existing VIN, lot, or slug, but it does not explicitly name or contrast any sibling 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?

It explicitly says to use this tool when the user already has a VIN, lot number, or supported slug, and gives guidance on when to add include history/vin_lots. It does not state when to prefer alternatives such as get_vehicle_history or get_related_vehicles, so exclusions are absent.

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

get_vehicle_filtersGet vehicle filtersA
Read-onlyIdempotent
Inspect

Use before building a dynamic search UI or validating source-backed filter choices. Returns current filter metadata; it does not search inventory itself.

ParametersJSON Schema
NameRequiredDescriptionDefault
platformNoOptional readable auction-source selector. Omit to retrieve combined supported filter metadata.

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, lowering the bar. The description adds value by clarifying the tool's boundary (metadata only, not a search) and the dynamic nature of the data ('current'), which complements the openWorldHint.

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?

Two sentences, zero filler. Usage guidance is front-loaded first, followed by the boundary clarification. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (0 required params, output schema present), so return values don't need description. The description covers when to use it, what it does, and what it doesn't do. Minor gap: nothing about how filter metadata varies across platforms, though the schema's enum partially addresses this.

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 description coverage is 100% and the schema fully documents the optional platform parameter and its omit behavior. The description adds no parameter-level detail, 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 ('Returns') and resource ('current filter metadata'), and explicitly differentiates from search tools with 'it does not search inventory itself'. An agent can distinguish this from search_auction_vehicles immediately.

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 explicit when-to-use context: 'Use before building a dynamic search UI or validating source-backed filter choices.' It implies the exclusion of search usage via 'does not search inventory itself,' but does not name alternative sibling tools explicitly.

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

get_vehicle_historyGet vehicle auction historyA
Read-onlyIdempotent
Inspect

Use for retained Copart + IAAI auction appearances for one supported vehicle. This is auction-specific history, not complete ownership, registration or accident history.

ParametersJSON Schema
NameRequiredDescriptionDefault
identifierYesVIN, lot number or slug_vin accepted by the canonical vehicle detail endpoint.

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
metaNoPagination metadata. Treat cursor values as opaque.

TDQS

A4/5.0
Behavior3/5

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

Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds useful boundaries about the data being auction-specific and retained, but leaves terms like 'retained' and the exact coverage of auction appearances unexplained. It is adequate but not rich.

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?

Two sentences with no filler. The first sentence gives the action and scope; the second clarifies what the tool does not cover. All content earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with an output schema, the description covers the key context: supported sources, scope, and exclusions. It could improve by explaining 'retained' or pointing to an alternative for full history, but nothing critical is missing.

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% for the single identifier parameter, and the schema already explains accepted formats (VIN, lot number, slug_vin). The description adds no additional parameter-level meaning beyond implying one vehicle, so the baseline 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?

The description states the tool is for retrieving retained Copart and IAAI auction appearances for one supported vehicle, and explicitly distinguishes this from complete ownership, registration, or accident history. This makes the purpose concrete and helps separate it from sibling tools like get_vehicle and get_related_vehicles.

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 a clear use case ('for ... one supported vehicle') and a strong exclusion ('not complete ownership, registration or accident history'). It does not name alternative tools explicitly, but the guidance is sufficient for an agent to know when to choose this tool versus a full-history lookup.

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

list_auction_locationsList auction locationsA
Read-onlyIdempotent
Inspect

Use to resolve supported auction yards, branches or facilities and their location metadata. Use calculate_shipping when the user needs auction-to-port pricing instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
sNoFree-text location search, such as a facility name, city or supported location term.
stateNoOptional state or region filter, for example FL.
countryNoOptional country filter supported by the locations endpoint.
platformNoOptional source selector: Copart or IAA / IAAI.

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
metaNoPagination metadata. Treat cursor values as opaque.

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not required to restate those. It adds minimal behavioral context, only mentioning that it resolves 'supported' locations and returns 'location metadata'. Since the output schema exists, return details are covered. The description adds no extra behavioral disclosures like pagination, rate limits, or authentication requirements, so a 3 is appropriate.

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?

The description is a single, front-loaded sentence that delivers the purpose and the key alternative without any wasted words. It is concise and well-structured, earning every word.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has zero required parameters, an output schema, and comprehensive annotations, so the description does not need to explain return values or safety. It clearly states the primary use and a sibling alternative. It could optionally mention that all parameters are optional filters, but the schema already conveys that. The description is complete enough for an agent 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 description coverage is 100%, so all four parameters (s, state, country, platform) have descriptive text in the schema. The description does not add any additional parameter semantics or clarify usage beyond what the schema already provides. Baseline 3 applies when the schema fully documents parameters.

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?

The description states a specific verb ('resolve') and a precise resource ('supported auction yards, branches or facilities') along with their location metadata. It also explicitly differentiates from the sibling 'calculate_shipping' by naming it and the condition that selects it, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('to resolve supported auction yards...') and provides an alternative with a clear condition ('Use calculate_shipping when the user needs auction-to-port pricing instead'). This leaves no inference needed for the primary decision point.

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

search_auction_vehiclesSearch auction vehiclesA
Read-onlyIdempotent
Inspect

Use for broad inventory discovery, filtering and incremental synchronization across supported Copart and IAA / IAAI records. For one known VIN or lot use get_vehicle; for retained auction appearances use get_vehicle_history.

ParametersJSON Schema
NameRequiredDescriptionDefault
sNoSearch by VIN, lot number or vehicle title/model text.
zipNoZIP/postal code used with radius for supported proximity search.
makeNoMake filter for GET /vehicles.
typeNoVehicle type filter for GET /vehicles.
colorNoColor filter for GET /vehicles.
modelNoModel filter for GET /vehicles.
unitsNoDistance and odometer unit system: mi or km.
cursorNoOpaque pagination cursor returned by the API. Send next_cursor back unchanged; do not decode or synthesize it.
damageNoPrimary damage category filter.
radiusNoSearch radius around zip, interpreted using the selected units.
seriesNoSeries / model family filter for GET /vehicles.
has_keyNoKey-availability filter using the documented values No, All or With.
year_toNoYear to filter for GET /vehicles.
per_pageNoRequested page size. Effective maximum is subscription-plan dependent; common public plan limits are 20, 30 or 40 and custom plans may differ.
platformNoReadable auction-source selector: copart or iaai. Omit for combined supported sources.
run_condNoNormalized run-condition filter.
upcomingNoUpcoming selector: all=no upcoming restriction, only=upcoming eligible lots only, without=exclude upcoming lots.
body_typeNoDeprecated compatibility alias for body_style. A string or array is accepted; prefer body_style for new integrations.
cylindersNoCylinders filter for GET /vehicles.
fuel_typeNoFuel type filter for GET /vehicles.
loc_stateNoAuction location state or region, for example FL.
price_maxNoPrice max filter for GET /vehicles.
price_minNoPrice min filter for GET /vehicles.
year_fromNoYear from filter for GET /vehicles.
body_styleNoFilter by vehicle_specs.body_style. A string or array is accepted; multiple values are OR-ed. IAAI uses VehicleClass and Copart uses the source-backed Body Style field.
drive_typeNoDrive type filter for GET /vehicles.
generationNoGeneration filter for GET /vehicles.
lot_statusNoAuction mode filter: All, Timed or Buy Now.
today_onlyNoWhen true, restrict results to the endpoint current-day auction logic.
engine_typeNoEngine type filter for GET /vehicles.
facility_idNoAuction facility identifier used to restrict results to one supported facility.
odometer_toNoOdometer to filter for GET /vehicles.
office_nameNoAuction office or branch name filter.
seller_typeNoNormalized seller type: dealer, finance, insurance or non_insurance.
auction_typeNoNumeric compatibility source selector: 0=all, 1=Copart, 2=IAAI. If both auction_type and platform are supplied, auction_type takes precedence; prefer platform for new integrations.
transmissionNoTransmission filter for GET /vehicles.
generation_idNoGeneration ID filter for GET /vehicles.
include_totalNoInclude exact total filter for GET /vehicles.
odometer_fromNoOdometer from filter for GET /vehicles.
engine_size_toNoEngine size to filter for GET /vehicles.
lot_sub_statusNoNormalized auction state: Open for active/open lots, Live for currently live supported lots, Ended for closed/ended lots.
auction_date_toNoEnd auction date in YYYY-MM-DD format.
engine_size_fromNoEngine size from filter for GET /vehicles.
auction_date_fromNoStart auction date in YYYY-MM-DD format.
has_shipping_priceNoWhen true, return only vehicles with supported shipping-price data.
sale_document_typeNoSale/title document type filter; values are source-backed and can vary.
sale_document_pendingNoWhen true, restrict results to records with a pending sale document state when supported.
updated_within_minutesNoIncremental-sync window. Return records whose updated_at changed within this many minutes; supported range is 1..525600. Use with cursor pagination and an overlap window.

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
metaNoPagination metadata. Treat cursor values as opaque.

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds the incremental-synchronization use case (which pairs with updated_within_minutes and cursor paging) and the multi-source scope, but discloses no rate limits, plan-dependent result caps, or pagination caveats for what is a heavy 48-parameter query.

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?

Two sentences, zero filler, with the primary use case front-loaded and the sibling-routing guidance second. It reads as fully earned content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and full schema coverage, the description need not explain returns or filter formats; it covers purpose, source scope, and routing well. It does not hint at the paging/incremental-sync workflow (cursor plus overlap window, plan-dependent per_page) that dominates correct usage of this endpoint, which is the only material gap.

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 description coverage is 100%, so every parameter including the deprecated auction_type/body_type aliases and the updated_within_minutes overlap-window guidance is already documented in the schema. The description adds no parameter-level meaning beyond restating the Copart/IAAI scope, so the 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 set (discovery, filtering, incremental synchronization) over a specific resource (Copart and IAA/IAAI auction records), and the scope word 'broad' distinguishes it from single-record lookups. An agent can tell it apart from get_vehicle without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: 'For one known VIN or lot use get_vehicle; for retained auction appearances use get_vehicle_history.' Both alternatives are named with the condition that selects each, leaving nothing to inference.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedsearch_auction_vehicles2 fields changed
      • addedInput schema / properties / body_style
        Added value: +{
+  "description": "Filter by vehicle_specs.body_style. A string or array is accepted; multiple values are OR-ed. IAAI uses VehicleClass and Copart uses the source-backed Body Style field.",
+  "oneOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  ]
+}
      • addedInput schema / properties / body_type
        Added value: +{
+  "description": "Deprecated compatibility alias for body_style. A string or array is accepted; prefer body_style for new integrations.",
+  "oneOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  ]
+}
  2. 1 tool update
    • Changedsearch_auction_vehicles4 fields changed
      • removedInput schema / properties / engine_hp_from
        Removed value: -{
-  "description": "Engine HP from filter for GET /vehicles.",
-  "type": "string"
-}
      • removedInput schema / properties / engine_hp_to
        Removed value: -{
-  "description": "Engine HP to filter for GET /vehicles.",
-  "type": "string"
-}
      • addedInput schema / properties / engine_type
        Added value: +{
+  "description": "Engine type filter for GET /vehicles.",
+  "enum": [
+    "I",
+    "V",
+    "W",
+    "B"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / include_total
        Added value: +{
+  "description": "Include exact total filter for GET /vehicles.",
+  "type": "boolean"
+}
  3. 1 tool update
    • Changedsearch_auction_vehicles2 fields changed
      • changedInput schema / properties / engine_hp_from / type
        Previous value: -"number"New value: +"string"
      • changedInput schema / properties / engine_hp_to / type
        Previous value: -"number"New value: +"string"
  4. 1 tool update
    • Changedget_vehicle1 field changed
      • addedInput schema / properties / include
        Added value: +{
+  "description": "Optional related data to embed in the vehicle detail result.",
+  "items": {
+    "enum": [
+      "history",
+      "vin_lots"
+    ],
+    "type": "string"
+  },
+  "maxItems": 2,
+  "type": "array",
+  "uniqueItems": true
+}
  5. 1 tool update
    • Changedsearch_auction_vehicles1 field changed
      • addedInput schema / properties / series
        Added value: +{
+  "description": "Series / model family filter for GET /vehicles.",
+  "type": "string"
+}
  6. 1 tool update
    • Changedsearch_auction_vehicles2 fields changed
      • addedInput schema / properties / generation
        Added value: +{
+  "description": "Generation filter for GET /vehicles.",
+  "type": "string"
+}
      • addedInput schema / properties / generation_id
        Added value: +{
+  "description": "Generation ID filter for GET /vehicles.",
+  "type": "string"
+}
  7. 8 tool updates
    • Changedcalculate_shipping5 fields changed
      • addedInput schema / properties / lot_number / description
        Added value: +"Auction lot number. Provide this or vin."
      • addedInput schema / properties / port / description
        Added value: +"Optional destination port name supported by the shipping endpoint."
      • addedInput schema / properties / port_id / description
        Added value: +"Optional destination port identifier when known."
      • addedInput schema / properties / vin / description
        Added value: +"Vehicle Identification Number. Provide this or lot_number."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured JSON returned by the canonical Apibara Vehicle Auction Data API. Source-dependent fields may be null or absent.",
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
    • Changedget_api_usage1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured JSON returned by the canonical Apibara Vehicle Auction Data API. Source-dependent fields may be null or absent.",
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
    • Changedget_related_vehicles3 fields changed
      • changedInput schema / properties / identifier / description
        Previous value: -"VIN or slug_vin accepted by the canonical vehicle detail endpoint."New value: +"VIN, lot number or slug_vin accepted by the canonical vehicle detail endpoint."
      • addedInput schema / properties / per_page / description
        Added value: +"Maximum related records to return. Effective limits are plan-dependent."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured JSON returned by the canonical Apibara Vehicle Auction Data API. Source-dependent fields may be null or absent.",
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "meta": {
+      "additionalProperties": true,
+      "description": "Pagination metadata. Treat cursor values as opaque.",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
    • Changedget_vehicle2 fields changed
      • changedInput schema / properties / identifier / description
        Previous value: -"VIN or slug_vin accepted by the canonical vehicle detail endpoint."New value: +"VIN, lot number or slug_vin accepted by the canonical vehicle detail endpoint."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured JSON returned by the canonical Apibara Vehicle Auction Data API. Source-dependent fields may be null or absent.",
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
    • Changedget_vehicle_filters2 fields changed
      • addedInput schema / properties / platform / description
        Added value: +"Optional readable auction-source selector. Omit to retrieve combined supported filter metadata."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured JSON returned by the canonical Apibara Vehicle Auction Data API. Source-dependent fields may be null or absent.",
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
    • Changedget_vehicle_history2 fields changed
      • changedInput schema / properties / identifier / description
        Previous value: -"VIN or slug_vin accepted by the canonical vehicle detail endpoint."New value: +"VIN, lot number or slug_vin accepted by the canonical vehicle detail endpoint."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured JSON returned by the canonical Apibara Vehicle Auction Data API. Source-dependent fields may be null or absent.",
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "meta": {
+      "additionalProperties": true,
+      "description": "Pagination metadata. Treat cursor values as opaque.",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
    • Changedlist_auction_locations5 fields changed
      • addedInput schema / properties / country / description
        Added value: +"Optional country filter supported by the locations endpoint."
      • addedInput schema / properties / platform / description
        Added value: +"Optional source selector: Copart or IAA / IAAI."
      • addedInput schema / properties / s / description
        Added value: +"Free-text location search, such as a facility name, city or supported location term."
      • addedInput schema / properties / state / description
        Added value: +"Optional state or region filter, for example FL."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured JSON returned by the canonical Apibara Vehicle Auction Data API. Source-dependent fields may be null or absent.",
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "meta": {
+      "additionalProperties": true,
+      "description": "Pagination metadata. Treat cursor values as opaque.",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
    • Changedsearch_auction_vehicles45 fields changed
      • addedInput schema / properties / auction_date_from
        Added value: +{
+  "description": "Start auction date in YYYY-MM-DD format.",
+  "format": "date",
+  "type": "string"
+}
      • addedInput schema / properties / auction_date_to
        Added value: +{
+  "description": "End auction date in YYYY-MM-DD format.",
+  "format": "date",
+  "type": "string"
+}
      • addedInput schema / properties / auction_type
        Added value: +{
+  "description": "Numeric compatibility source selector: 0=all, 1=Copart, 2=IAAI. If both auction_type and platform are supplied, auction_type takes precedence; prefer platform for new integrations.",
+  "enum": [
+    0,
+    1,
+    2
+  ],
+  "type": "integer"
+}
      • addedInput schema / properties / color
        Added value: +{
+  "description": "Color filter for GET /vehicles.",
+  "type": "string"
+}
      • addedInput schema / properties / cursor / description
        Added value: +"Opaque pagination cursor returned by the API. Send next_cursor back unchanged; do not decode or synthesize it."
      • addedInput schema / properties / cylinders
        Added value: +{
+  "description": "Cylinders filter for GET /vehicles.",
+  "type": "integer"
+}
      • addedInput schema / properties / damage
        Added value: +{
+  "description": "Primary damage category filter.",
+  "enum": [
+    "Fire",
+    "Hail",
+    "Theft",
+    "Water",
+    "Chemical",
+    "Rollover",
+    "Mechanical",
+    "Vandalized",
+    "Repossession"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / drive_type
        Added value: +{
+  "description": "Drive type filter for GET /vehicles.",
+  "enum": [
+    "AWD",
+    "FWD",
+    "RWD"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / engine_hp_from
        Added value: +{
+  "description": "Engine HP from filter for GET /vehicles.",
+  "type": "number"
+}
      • addedInput schema / properties / engine_hp_to
        Added value: +{
+  "description": "Engine HP to filter for GET /vehicles.",
+  "type": "number"
+}
      • addedInput schema / properties / engine_size_from
        Added value: +{
+  "description": "Engine size from filter for GET /vehicles.",
+  "type": "number"
+}
      • addedInput schema / properties / engine_size_to
        Added value: +{
+  "description": "Engine size to filter for GET /vehicles.",
+  "type": "number"
+}
      • addedInput schema / properties / facility_id / description
        Added value: +"Auction facility identifier used to restrict results to one supported facility."
      • changedInput schema / properties / facility_id / type
        Previous value: -[
-  "integer",
-  "string"
-]New value: +"string"
      • addedInput schema / properties / fuel_type
        Added value: +{
+  "description": "Fuel type filter for GET /vehicles.",
+  "enum": [
+    "Diesel",
+    "Hybrid",
+    "Electric",
+    "Flexible",
+    "Gasoline",
+    "All others"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / has_key
        Added value: +{
+  "description": "Key-availability filter using the documented values No, All or With.",
+  "enum": [
+    "No",
+    "All",
+    "With"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / has_shipping_price / description
        Added value: +"When true, return only vehicles with supported shipping-price data."
      • addedInput schema / properties / loc_state / description
        Added value: +"Auction location state or region, for example FL."
      • addedInput schema / properties / lot_status / description
        Added value: +"Auction mode filter: All, Timed or Buy Now."
      • addedInput schema / properties / lot_sub_status / description
        Added value: +"Normalized auction state: Open for active/open lots, Live for currently live supported lots, Ended for closed/ended lots."
      • addedInput schema / properties / make / description
        Added value: +"Make filter for GET /vehicles."
      • addedInput schema / properties / model / description
        Added value: +"Model filter for GET /vehicles."
      • addedInput schema / properties / odometer_from
        Added value: +{
+  "description": "Odometer from filter for GET /vehicles.",
+  "type": "number"
+}
      • addedInput schema / properties / odometer_to
        Added value: +{
+  "description": "Odometer to filter for GET /vehicles.",
+  "type": "number"
+}
      • addedInput schema / properties / office_name
        Added value: +{
+  "description": "Auction office or branch name filter.",
+  "type": "string"
+}
      • addedInput schema / properties / per_page / description
        Added value: +"Requested page size. Effective maximum is subscription-plan dependent; common public plan limits are 20, 30 or 40 and custom plans may differ."
      • addedInput schema / properties / platform / description
        Added value: +"Readable auction-source selector: copart or iaai. Omit for combined supported sources."
      • addedInput schema / properties / price_max / description
        Added value: +"Price max filter for GET /vehicles."
      • addedInput schema / properties / price_min / description
        Added value: +"Price min filter for GET /vehicles."
      • addedInput schema / properties / radius
        Added value: +{
+  "description": "Search radius around zip, interpreted using the selected units.",
+  "type": "integer"
+}
      • addedInput schema / properties / run_cond
        Added value: +{
+  "description": "Normalized run-condition filter.",
+  "enum": [
+    "STATIONARY",
+    "NO INFORMATION",
+    "RUNS AND DRIVES",
+    "ENGINE START PROGRAM"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / s / description
        Previous value: -"VIN, lot number or title search."New value: +"Search by VIN, lot number or vehicle title/model text."
      • addedInput schema / properties / sale_document_pending
        Added value: +{
+  "description": "When true, restrict results to records with a pending sale document state when supported.",
+  "type": "boolean"
+}
      • addedInput schema / properties / sale_document_type
        Added value: +{
+  "description": "Sale/title document type filter; values are source-backed and can vary.",
+  "type": "string"
+}
      • addedInput schema / properties / seller_type
        Added value: +{
+  "description": "Normalized seller type: dealer, finance, insurance or non_insurance.",
+  "enum": [
+    "dealer",
+    "finance",
+    "insurance",
+    "non_insurance"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / today_only / description
        Added value: +"When true, restrict results to the endpoint current-day auction logic."
      • addedInput schema / properties / transmission
        Added value: +{
+  "description": "Transmission filter for GET /vehicles.",
+  "enum": [
+    "Manual",
+    "Unknown",
+    "Automatic"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / type
        Added value: +{
+  "description": "Vehicle type filter for GET /vehicles.",
+  "type": "string"
+}
      • addedInput schema / properties / units
        Added value: +{
+  "description": "Distance and odometer unit system: mi or km.",
+  "enum": [
+    "mi",
+    "km"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / upcoming / description
        Added value: +"Upcoming selector: all=no upcoming restriction, only=upcoming eligible lots only, without=exclude upcoming lots."
      • addedInput schema / properties / updated_within_minutes / description
        Added value: +"Incremental-sync window. Return records whose updated_at changed within this many minutes; supported range is 1..525600. Use with cursor pagination and an overlap window."
      • addedInput schema / properties / year_from / description
        Added value: +"Year from filter for GET /vehicles."
      • addedInput schema / properties / year_to / description
        Added value: +"Year to filter for GET /vehicles."
      • addedInput schema / properties / zip
        Added value: +{
+  "description": "ZIP/postal code used with radius for supported proximity search.",
+  "type": "string"
+}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured JSON returned by the canonical Apibara Vehicle Auction Data API. Source-dependent fields may be null or absent.",
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "meta": {
+      "additionalProperties": true,
+      "description": "Pagination metadata. Treat cursor values as opaque.",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  8. 8 tool updates
    • First observedcalculate_shipping
    • First observedget_api_usage
    • First observedget_related_vehicles
    • First observedget_vehicle
    • First observedget_vehicle_filters
    • First observedget_vehicle_history
    • First observedlist_auction_locations
    • First observedsearch_auction_vehicles

Related MCP Connectors

Related MCP Servers

  • used-parts-mcp

    neko-no-otoko
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables searching current used car, truck, and motorcycle parts in the US, resolving vehicles via VIN, and retrieving part listings with source attribution, through read-only MCP tools.
    Apache 2.0

  • encarapi-mcp

    ThatMojo
    A
    license
    A
    quality
    B
    maintenance
    Enables MCP clients to search live Korean and Chinese used-car listings and retrieve vehicle details, inspection reports, and accident records through read-only tools.
    11
    325 npm
    MIT

  • DETRAN PE: Veículo

    mcp-dir
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables querying vehicle information from DETRAN PE's official source through a read-only, pay-per-query MCP tool.
    MIT
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