JOY Automart MCP lets AI assistants search Bangladesh car parts and vehicle listings, inspect public details/auctions, compare cars, read buying terms, and prepare human WhatsApp enquiries; with an optional buyer token it can also quote/place orders and manage RFQs/orders.
Search and browse car parts by text, vehicle make/chassis, category, stock availability, RFQ catalogue inclusion, and BDT budget.
Read a part's public price, availability, stock, OEM reference, fitment evidence/constraints, and sellability.
Search vehicle listings by text, make, fuel type, year, verification, and BDT asking price.
Read vehicle details, photos, inspection evidence, and any public auction link/status.
Discover public auction links and read public bid/status snapshots.
Compare 2–4 vehicle listings, including missing listings and unknown-price coverage.
Read Bangladesh buying terms, payment/delivery guidance, and human sales contact.
Prepare vehicle or part enquiry links with pre-filled WhatsApp messages; these do not send messages, reserve stock/vehicles, bid, order, or pay.
With a buyer-issued agent token, use buyer tools for quotes, cash-on-delivery/trade-credit orders, RFQs, order status, and order history.
Generates a pre-filled WhatsApp message link for a human buyer to complete a purchase, including canonical part details and fitment limitations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@JOY Automart MCP Server find brake pads for a Toyota Corolla under 5000 BDT"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official Model Context Protocol server for JOY Automart, Bangladesh's automotive parts and vehicle marketplace. It lets AI assistants (Claude, ChatGPT, Cursor and other MCP clients) search JOY's car-parts catalogue and JOY Auto Exchange vehicle listings, compare cars, discover public auction links, look up a part, and prepare part or vehicle enquiries for a human buyer. Prices are in BDT.
Remote endpoint |
|
Transport | Streamable HTTP (MCP protocol 2025-06-18 and later) |
Auth | None for the public tools. Optional buyer token: |
Docs | |
Server card | https://www.joyautomart.com/.well-known/mcp/server-card.json |
The server is hosted by JOY Automart; you do not need to run anything to use it. This repository contains the public metadata (registry server.json, Smithery config, tool snapshot) and a small stdio proxy for clients that only support local servers.
Ten public, read-only tools (no account needed), verified against hosted version 1.3.0 on October 31, 2026. The live tools/list snapshot in tools.json includes all 35 documented arguments and typed success/error output schemas. * marks a required argument.
Tool | What it does | Arguments |
| Search public parts by text, vehicle identity, category, availability and BDT budget. |
|
| Read one catalogue part's public detail, price, stock and fitment evidence. |
|
| Search public vehicle listings by text, make, year, fuel, verification and BDT asking price. |
|
| Read a vehicle by listing ID or slug, including public photos, inspection evidence and any auction link. |
|
| Read an existing auction's public bid/status snapshot when public access is enabled. |
|
| Discover already-public auction links while paging through vehicle listings; source counts are not auction counts. |
|
| Compare 2–4 listings with explicit missing listings and unknown-price coverage. |
|
| Read Bangladesh buying terms, delivery/payment guidance, human contact and declared fallback status. | — |
| Resolve a public vehicle and prepare its listing link and human-reviewed WhatsApp enquiry. |
|
| Resolve a selected part after search and detail lookup, then prepare its product link and human-reviewed WhatsApp enquiry. |
|
Auction discovery scans public vehicle pages and reports source pagination, not a guaranteed count of active auctions. Public snapshot access retains its existing feature gate. Both handoff tools prepare links only; they send no message, reserve no stock or vehicle, and place no order.
Existing clients can still call get_auction_status and prepare_buyer_handoff as compatibility aliases for get_auction and prepare_part_handoff. Discovery advertises only the canonical names above.
All public tools are annotated readOnlyHint: true. Fitment is guidance only: the server never claims a part fits a vehicle without VIN/chassis evidence; confirm with JOY's sales team before buying.
With a buyer-issued agent token (create one at https://www.joyautomart.com/cars/account?section=ai-agents&portal=retail) an agent can also use quote_order, place_order (cash on delivery or approved trade credit, within the buyer's spending limits), create_rfq, get_order_status and list_my_orders.
Related MCP server: MarketCheck MCP Apps
Settings → Connectors → Add custom connector → URL https://www.joyautomart.com/mcp.
Settings → Connectors (developer mode) → Create → MCP server URL https://www.joyautomart.com/mcp, authentication: none.
~/.cursor/mcp.json:
{
"mcpServers": {
"joy-automart": { "url": "https://www.joyautomart.com/mcp" }
}
}{
"servers": {
"joy-automart": { "type": "http", "url": "https://www.joyautomart.com/mcp" }
}
}claude mcp add --transport http joy-automart https://www.joyautomart.com/mcpcurl -s https://www.joyautomart.com/mcp \
-H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'The npm package @joyautomart/mcp-server is not published yet. Once it is, stdio-only clients can use:
{
"mcpServers": {
"joy-automart": {
"command": "npx",
"args": ["-y", "@joyautomart/mcp-server"],
"env": { "JOY_AGENT_TOKEN": "joyagt_your_token_here" }
}
}
}Until then you can run the proxy from this repo (Node 18+):
git clone https://github.com/www-joyautomart-com/mcp-server && cd mcp-server
npm ci
node bin/joyautomart-mcp.js # or: --url https://www.joyautomart.com/mcpJOY_AGENT_TOKEN is optional; public tools work without it.
Official MCP Registry name: com.joyautomart/mcp (server.json; listing pending domain verification)
Smithery config: smithery.yaml
Questions about parts, orders or fitment: https://www.joyautomart.com. Issues with this repository: GitHub issues.
MIT © 2026 JOY Automart / Ahmed Joyadh
Compare a selected car shortlist; use search_vehicles to discover candidates or get_vehicle for one car.
vehicle_ids chooses the adverts to include, in buyer-selected order; it does not rerun search filters. Resolve ID/slug aliases to distinct listing_id values. Repeating an advert must not create extra price evidence or imply another vehicle.
Keep unknown-price candidates visible when the buyer still wants to consider them. A cheapest result ranks only distinct, known positive prices; inspect price_comparison_complete before describing it as cheapest across the whole shortlist. Asking prices are not valuations.
Anonymous fresh lookups can partially fail. Inspect not_found/unavailable and retry temporary failures before excluding a candidate. Use prepare_vehicle_handoff after choosing; comparison reserves nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| vehicle_ids | Yes | Two to four listing_id values from search_vehicles or public listing slugs, not VINs or URLs. Choose distinct listings; repeated IDs or an ID and its slug do not provide separate price evidence. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already covering the safe-read/idempotent profile, the description adds non-obvious behavior: anonymous fresh lookups can partially fail, not_found/unavailable should be inspected and transient failures retried before excluding, and comparison reserves nothing. It also warns that asking prices are not valuations and that price_comparison_complete must be checked before claiming 'cheapest' — exactly the kind of caveat annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded one-line purpose followed by three tight bullets, each addressing a distinct failure mode (dedupe/ordering, unknown prices, partial failures). No sentence restates the schema or the annotations, and nothing reads as padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values needn't be enumerated, and the description still surfaces the two output fields an agent must reason about (price_comparison_complete, not_found/unavailable). For a single-parameter, read-only comparison tool, nothing needed 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, yet the description still adds meaning: vehicle_ids is in buyer-selected order, aliases must be resolved to distinct listing_id values, and repeats do not create extra price evidence. That ordering and deduplication semantics are not conveyed by the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Compare a selected car shortlist") and immediately distinguishes itself from two siblings: search_vehicles for discovery and get_vehicle for a single car. An agent can route correctly without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly covers when to use (a buyer-selected shortlist), when not (it "does not rerun search filters"), and what to do next ("Use prepare_vehicle_handoff after choosing; comparison reserves nothing"). It also names the alternative tools by name, so no inference about sibling selection is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Observe one car auction's public bid state; search_auctions discovers IDs and get_vehicle supplies the linked car's facts.
Select auction_id from the same discovery/detail record as the car being discussed. It identifies a sale event, not the vehicle advertisement: never substitute listing_id or carry a bid between auction IDs.
A saved event ID does not imply an open auction. Read status/end_at and refresh the snapshot before answering a bid question. minimum_next_bid is optional; an asking price cannot fill a missing bid value.
Anonymous observation only. Feature gating, rate limits or an unknown event can return errors; report them without bypass. Reserves and bidder identities stay private. Bidding requires a verified dealer and human decision outside this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| auction_id | Yes | Copy auction_id from search_auctions or an auction-linked get_vehicle result, or use a known public auction ID supplied by the buyer. Supply the event identifier alone, not a listing_id or URL; never invent one. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world, so the bar is lower, yet the description adds substantial context: anonymous observation only, possible errors from feature gating/rate limits/unknown events, and that reserves and bidder identities are withheld. It also warns that a saved event ID does not imply an open auction, which is a real behavioral trap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose sentence followed by three dense bullets, each carrying distinct guidance (identifier selection, staleness/refresh, privacy and error behavior). Minor redundancy with the schema's auction_id text, but no filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be explained. For a single-parameter read tool, the description covers identifier provenance, staleness handling, error expectations, and privacy boundaries — everything an agent needs to call it and interpret a failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description earns above that by explaining what auction_id semantically identifies ('a sale event, not the vehicle advertisement') and by forbidding substitution of listing_id. Some of this duplicates the schema's own parameter description, which keeps it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Observe one car auction's public bid state') and immediately positions it against two siblings: search_auctions for discovery and get_vehicle for the linked car's facts. An agent can place this tool in the workflow without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: use search_auctions to discover IDs, get_vehicle for vehicle facts, and this tool only for bid state. It also names the wrong-identifier failure mode (never substitute listing_id, never carry a bid across auction IDs) and states the out-of-scope action (bidding requires a verified dealer outside this tool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read published Bangladesh retail-parts payment, delivery and human-contact terms before explaining a purchase.
Call {}. These terms come from the public retail-marketplace configuration, not a product, address or buyer account. Product choice cannot personalize this call: get_part supplies item eligibility and prepare_part_handoff prepares the enquiry.
Apply the returned zones after learning the buyer's area; confirm quantity/fitment separately from get_part. Retail checkout terms do not establish vehicle, auction or trade-credit terms; route car questions through prepare_vehicle_handoff.
Anonymous live read. Money objects separate major BDT from minor paisa; vat_bps uses basis points. If live_terms_unavailable=true, ask the human team rather than invent fees. The result is guidance, not an accepted quote; no payment or message starts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, closed-world read; the description adds genuinely new context: it is an anonymous live read, it is configuration-level rather than account/product personalized, and it names the live_terms_unavailable failure mode with an explicit instruction to escalate rather than invent fees. It also clarifies the result is guidance, not an accepted quote, and that no payment or message is initiated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The leading sentence is well front-loaded and each bullet carries distinct information about scope, sequencing and failure handling. It is somewhat dense and the literal '- Call {}.' placeholder is an unfilled template artifact that adds no meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read with an output schema, the description supplies everything an agent still needs: where the terms come from, what is out of scope, currency/vat encoding, and the escalation path on unavailable live terms. Nothing required 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing parameter-level to document and the schema coverage is trivially 100%. The description instead explains returned value conventions (major BDT vs minor paisa, vat_bps as basis points), which is useful but lives in a different dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read published Bangladesh retail-parts payment, delivery and human-contact terms') and even scopes the timing ('before explaining a purchase'). It is clearly distinguishable from sibling reads such as get_part and prepare_part_handoff, which it names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use routing: call before explaining a purchase, apply returned zones only after learning the buyer's area, confirm quantity/fitment via get_part, and route vehicle/auction/trade-credit questions through prepare_vehicle_handoff. Alternatives and exclusions are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one spare part's public price, availability and fitment restrictions; search_parts supplies its ID.
Copy the selected part_id unchanged. An OEM match can identify several catalogue entries: keep each entry's price, stock and fitment evidence together instead of borrowing facts from another matching entry.
A found item can remain unsellable. Use its minimum quantity and required fitment information when discussing an enquiry through prepare_part_handoff; unknown price or stock is not zero.
Anonymous fresh lookup; no supply is reserved or fitment certified. On a missing-ID error, search again rather than declaring the OEM part unavailable everywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| part_id | Yes | Exact catalogue part_id copied from search_parts, e.g. BRK-AXIO-01. This is JOY's catalogue identifier, not an OEM part number or a product URL. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, but the description adds genuinely new behavior: it is an anonymous fresh lookup with no supply reserved and no fitment certified, unknown price or stock is explicitly not zero, and a found item can still be unsellable. These are exactly the caveats an agent needs before relaying data to a user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The lead sentence front-loads the purpose and the three bullets cover distinct concerns (ID fidelity across multiple OEM matches, unsellable items, error recovery) with no duplication. Some clauses are dense and could be tightened, but every sentence carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present the description needn't explain return shape, and it still covers the ambiguous cases: multiple catalogue entries per OEM match, entries with no price/stock, and missing-ID failure. Nothing an agent needs to call this correctly or interpret its result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already explains that part_id is JOY's catalogue identifier copied from search_parts, not an OEM number or URL. The description's 'copy the selected part_id unchanged' is essentially a restatement of that schema text, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (read one spare part) plus the exact fields returned (public price, availability, fitment restrictions), and distinguishes itself from the sibling search_parts by noting that search supplies the ID. An agent can tell instantly that this is the single-item lookup after a search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly sequences the workflow (search_parts supplies the ID, then get_part reads the entry) and names the downstream alternative for discussion (prepare_part_handoff). It also gives an error-path rule: on a missing-ID error, search again rather than declaring the OEM part unavailable — clear when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a car listing's public specifications, asking price and inspection evidence; search_vehicles discovers candidates and compare_vehicles compares them.
Resolve an ID or slug to the returned canonical listing_id before counting offers. It identifies an advertisement; multiple advertisements do not establish independent inspection evidence.
Pass a non-empty auction_id to get_auction; an absent link means unknown auction status. Use search_auctions for discovery and prepare_vehicle_handoff for a selected car's human enquiry.
Anonymous fresh lookup. Missing facts stay unknown; a not-found listing requires a fresh search. Seller contacts and reserve prices stay private, and nothing is reserved.
| Name | Required | Description | Default |
|---|---|---|---|
| vehicle_id | Yes | listing_id returned by search_vehicles, or slug from a public JOY listing URL. Use only the ID/slug (letters/digits, dots, underscores, hyphens; starts with a letter/digit), not the URL, VIN or registration number. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, idempotent and non-destructive annotations, the description discloses meaningful behavior: it is an anonymous fresh lookup, missing facts stay unknown, seller contacts and reserve prices remain private, and nothing is reserved. It also clarifies that the canonical listing_id identifies an advertisement rather than independent inspection evidence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then uses bullets to separate sibling routing, identifier semantics, auction-link behavior and privacy constraints. It is information-dense but largely earns its space; minor trimming could make it tighter for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existing output schema and annotations, the description supplies the remaining operational context an agent needs: canonical ID handling, privacy constraints, fresh-lookup behavior, not-found handling and auction-link interpretation. Nothing essential appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already defines vehicle_id as a listing_id or slug. The description adds useful semantic nuance by explaining that an ID or slug resolves to the returned canonical listing_id and that the identifier denotes an advertisement, not necessarily independent inspection evidence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: reading a car listing's public specifications, asking price and inspection evidence. It also explicitly distinguishes this tool from search_vehicles (discovery) and compare_vehicles (comparison), so an agent can identify its role without opening sibling schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names multiple alternatives and the exact conditions for using them: search_vehicles for discovery, compare_vehicles for comparison, search_auctions for auction discovery, get_auction when an auction_id is present, and prepare_vehicle_handoff for a human enquiry. It also states that a not-found listing requires a fresh search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare product and pre-filled WhatsApp links for a human parts enquiry; use prepare_vehicle_handoff for whole cars.
First search_parts, then get_part, then copy the selected part_id here. Use get_buying_guide for general terms. Ask the buyer for missing fitment fields identified by get_part; never invent vehicle identity to complete an enquiry.
Keep quantity as the buyer's requested count, even below the published minimum: explain the gap rather than silently raising it. vehicle supplies fitment context; note can request confirmation but cannot override returned restrictions. Unit price times quantity is not an accepted quote.
Anonymous fresh lookup. Text is embedded in the link, so omit unnecessary personal details. Nothing opens, sends, reserves, orders or charges; the human decides whether to send and JOY confirms eligibility, fitment, stock and price.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Buyer-supplied question or preference copied into the prepared enquiry, such as a request to confirm delivery or bulk terms. | |
| part_id | Yes | Exact part_id from search_parts/get_part for the selected item; not an OEM reference or product URL. The tool fetches fresh public part detail before composing the links. | |
| vehicle | No | Buyer-provided make/model/year, chassis or VIN text for JOY's human fitment review. Omit if the buyer has not supplied vehicle information. | |
| quantity | No | Number of units the buyer wants to enquire about, included in the prepared message. This is a request count, not a stock allocation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only, idempotent, non-destructive operation, and the description adds substantial context: anonymous fresh lookup, text embedded in the link, omit unnecessary personal details, and nothing opens, sends, reserves, orders or charges. It also clarifies that the human decides whether to send and JOY confirms eligibility, fitment, stock and price.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and alternative, then uses bullets for workflow and constraints. It is dense but appropriately scoped for a multi-step preparation tool; some clauses could be tightened, but most sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex handoff workflow, annotations, output schema, and 100% schema coverage, the description is complete enough for an agent to call it correctly. It covers prerequisites, alternatives, missing-data handling, privacy, side-effect boundaries, and human confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter descriptions already carry most semantics. The tool description adds useful business rules beyond the schema, especially keeping the buyer's requested quantity even below the published minimum and explaining the gap rather than silently raising it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: preparing product and pre-filled WhatsApp links for a human parts enquiry. It explicitly distinguishes itself from the sibling prepare_vehicle_handoff, which is for whole cars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit workflow: search_parts, then get_part, then copy the selected part_id here. It also names alternatives such as get_buying_guide and prepare_vehicle_handoff, and tells the agent what to do when fitment fields are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare a listing link and pre-filled WhatsApp enquiry for a human considering one car; use prepare_part_handoff for spare parts and compare_vehicles before choosing between cars. Choose vehicle_id from a shortlisted listing, not an auction ID. A slug is resolved to the canonical listing_id before the message is composed. note records the buyer's request; it cannot change the asking price, certify condition or authorize a bid. The link embeds the note, so omit unnecessary personal details. Anonymous fresh lookup. This is the endpoint of the public research workflow: the human decides whether to open and send the enquiry, then JOY confirms availability, inspection and terms. No seller contact, booking, reservation, bid, order or payment is performed.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional human enquiry, e.g. request an inspection or confirm availability. Included in the pre-filled link; not submitted by this tool. | |
| vehicle_id | Yes | A selected listing_id from search_vehicles/compare_vehicles, or a public listing slug. Supply only the ID/slug, not a full URL or VIN. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only, idempotent, non-destructive and closed-world. The description adds important behavioural context beyond that: it is an anonymous fresh lookup, the note cannot change price/certify condition/authorize a bid, the link embeds the note, and no seller contact, booking, reservation, bid, order or payment occurs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded, with purpose, sibling routing, identifier constraints and workflow boundaries all present. It is slightly long in the final paragraph, but every sentence carries relevant operational or safety information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter preparation tool with a full output schema and read-only annotations, the description covers the workflow position, sibling alternatives, identifier requirements, note limitations, anonymity and all excluded downstream actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already explains both parameters. The description adds meaning about how vehicle_id is resolved (slug resolved to canonical listing_id), that auction IDs must not be used, and that the note is embedded in the link and does not submit anything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: prepare a listing link and pre-filled WhatsApp enquiry for one car. It explicitly distinguishes siblings, naming prepare_part_handoff for spare parts and compare_vehicles for choosing between cars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use context (endpoint of the public research workflow, after shortlisting), names alternatives (prepare_part_handoff, compare_vehicles), and states which identifier to use and which not to use (listing_id/slug, not auction ID).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover existing public car-auction IDs for get_auction; use get_vehicle for a known listing's details.
Express the desired car, not an auction title or bid: make='Toyota' scans that manufacturer's listings; add query='Premio' only for a model-specific request. Unpriced cars remain eligible because an auction need not have an asking price.
Pagination scans vehicles before extracting their links. Follow next_page even after an empty items page; claim the scan exhausted only when no next page remains and the source limit was not reached. At the limit, narrow the vehicle filters. Source counts are not auction counts.
Anonymous live read. Check each selected auction's current availability with get_auction; a link may be ended or feature-gated. No private lot is exposed or bid placed.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Case-insensitive manufacturer prefix, e.g. Toyota; intersects the vehicle query. Omit for all makes. | |
| page | No | One-based source vehicle page; use returned next_page with unchanged filters. This is not a page of guaranteed auction matches. | |
| query | No | Make/model/trim phrase for candidate vehicles, e.g. Premio; omit to scan all public listings. Known Bangla/Banglish vocabulary is normalized. | |
| page_size | No | Public vehicle listings inspected per source page. Auction links can be fewer than this value, including zero. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive, and the description still adds non-obvious traits: unpriced cars remain eligible, an empty items page may still have a next_page, source counts are not auction counts, links may be ended or feature-gated, and no private lot is exposed or bid placed. These are exactly the behavioral edges annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then organized into three tight bullets covering filtering, pagination, and safety. Nearly every clause carries operational weight, though the pagination bullet is dense enough to require a second read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained; what an agent still needs — how to filter, how pagination terminates, what the read exposes — is fully covered. Nothing material for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 semantics beyond the schema: make scans a manufacturer's listings while query is reserved for model-specific requests, and the intersection of the two is explained operationally. It stops short of format examples that the schema does not already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+scope: "Discover existing public car-auction IDs for get_auction." It immediately names the sibling it is not (get_vehicle for a known listing) and positions itself as the discovery step in a two-tool flow, so an agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance (express the desired car, not an auction title or bid), when-not-to-add filters (add query only for a model-specific request), and names the follow-up tool (get_auction) plus the narrowing action at the source limit. Alternatives and exclusions are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find spare-part candidates in JOY's Bangladesh catalogue; use search_vehicles for whole cars.
Build filters from the buyer's intent: query names the item or OEM reference; make/chassis identify its vehicle. For example, combine Toyota, NZE141 and 'brake pads'. If nothing matches, clarify item text/category before changing a known vehicle identity.
Ask whether the buyer needs stocked supply or human sourcing before choosing the stock/RFQ flags. A catalogue-only match is an enquiry candidate, not a confirmed offer. Keep the chosen filters fixed while paging.
Anonymous live read. Empty results are valid; an uninterpretable Bangla query returns an error. Read get_part for the selected part_id, then prepare_part_handoff after fitment review. Search does not reserve stock.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Vehicle manufacturer, e.g. Toyota; narrows part candidates alongside the query. Omit if unknown. | |
| page | No | One-based results page, 1 through 500; defaults to 1. Increment to retrieve the next page with the same filters. | |
| query | No | Part name, OEM reference or vehicle words in English, Bangla or Banglish; e.g. 'Axio brake pads' or 'টয়োটা এক্সিও ব্রেক প্যাড'. Omit for filtered browsing; not a part_id lookup. | |
| chassis | No | Vehicle chassis/model code, e.g. NZE141 or G05; not a full VIN. Narrows candidates and does not certify fitment. | |
| category | No | Public category label from a catalogue result, e.g. Brakes. Omit if the category is unknown. | |
| page_size | No | Maximum results requested per page, 1 through 20; defaults to 10. total describes all matches, not this page's item count. | |
| in_stock_only | No | True requests currently in-stock candidates; false (default) permits other public availability states. This does not reserve stock. | |
| max_price_bdt | No | Inclusive maximum retail asking price in Bangladesh taka (BDT), e.g. 5000 means ৳5,000; omit for no budget ceiling. Not lakh units and not a currency conversion. | |
| include_rfq_catalogue | No | True also includes catalogue-only templates requiring a human parts request; false (default) omits them. Inclusion does not make an item directly purchasable. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses that this is an anonymous live read, that empty results are valid, that an uninterpretable Bangla query returns an error, that catalogue-only matches are enquiry candidates rather than confirmed offers, and that search does not reserve stock. These are exactly the non-obvious traits an agent needs before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the one-line purpose and correctly bulleted by concern (filter building, flags, behavior/chain), with no filler. Slightly long and mixes operational imperatives addressed to the agent ('Ask whether the buyer needs...') into what is otherwise crisp reference text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, entirely optional search tool with full schema coverage, an output schema, and annotations, the description covers the remaining gaps: identity of the data source, language handling, error mode, result semantics, and downstream tool chaining. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3; the description adds genuine meaning by explaining how query vs make/chassis compose ('query names the item or OEM reference; make/chassis identify its vehicle') and by giving a decision rule for the stock/RFQ flags plus 'keep the chosen filters fixed while paging'. It stops short of covering every parameter (e.g. max_price_bdt, page_size semantics are left entirely to the schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
'Find spare-part candidates in JOY's Bangladesh catalogue' is a specific verb+resource with scope, and it immediately distinguishes itself from search_vehicles ('use search_vehicles for whole cars'). An agent knows exactly which of the two search tools to pick without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (part vs whole vehicle), how to compose filters from buyer intent (make/chassis/query example: Toyota + NZE141 + 'brake pads'), a fallback rule when nothing matches, a decision point for stock vs RFQ flags, and a follow-on chain (get_part → prepare_part_handoff). Alternatives and exclusions are named rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover cars for sale in JOY Auto Exchange; use get_vehicle for detail, compare_vehicles for a shortlist or search_auctions for auction links.
Separate manufacturer and model: make='Toyota', query='Premio', max_price_bdt=3000000 expresses a Premio within 30 lakh. Filters intersect; a single 'Toyota Premio' phrase can miss a listing whose fields store those words separately.
Choose a priced-budget search or POA discovery deliberately. include_unpriced does not cancel numeric price bounds; omit both bounds when unknown-price cars must remain candidates. Asking prices are neither bids nor valuations.
Anonymous live read. Keep filters/sort fixed while paging; empty results are valid and missing prices remain unknown. Verification is inspection evidence, not a warranty. No seller is contacted or car reserved.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Case-insensitive manufacturer prefix, e.g. Toyota. Combine with query='Premio' for that model; omit to include all makes. | |
| page | No | One-based results page, 1 through 500; defaults to 1. Keep filters and sort unchanged when paging. | |
| sort | No | Result order: latest (default: verified first, then newest), price_asc (lowest stated price first), price_desc (highest first), or year_desc (newest model year first). Stable tie-breaks support paging; no valuation is performed. | latest |
| query | No | Case-insensitive phrase within make, model or trim; use query='Premio' with make='Toyota', not one combined 'Toyota Premio' phrase. Known Bangla/Banglish vocabulary is normalized; unsupported words may be dropped. Use known English model words for precision; omit to browse. | |
| max_year | No | Inclusive latest model year, 1950 through 2100. Omit for no upper-year filter; supply a value no less than min_year. | |
| min_year | No | Inclusive earliest model year, 1950 through 2100. Omit for no lower-year filter; supply a value no greater than max_year. | |
| fuel_type | No | Case-insensitive prefix of a public listing's fuel label, e.g. hybrid. Copy a known label where possible; omit to include all fuel types. | |
| page_size | No | Maximum results requested per page, 1 through 20; defaults to 10. total is the matching population, which may exceed this page's item count. | |
| max_price_bdt | No | Inclusive maximum stated asking price in Bangladesh taka, e.g. 3000000 means ৳30 lakh. Omit for no maximum; no less than min_price_bdt. | |
| min_price_bdt | No | Inclusive minimum stated asking price in Bangladesh taka, e.g. 2000000 means ৳20 lakh. Omit for no minimum; no greater than max_price_bdt. | |
| verified_only | No | True requires the storefront's verified flag, approved inspection status and a non-empty inspection ID; false (default) also permits other public listings. Verification is not a vehicle warranty. | |
| include_unpriced | No | True includes price-on-application or otherwise unpriced listings; false (default) excludes them. A missing asking price is unknown, never zero. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, closed-world read; the description adds substantial context on top: anonymous access, no seller contacted and no car reserved, empty results are valid, missing prices stay unknown, and verification is inspection evidence rather than a warranty. These are exactly the behavioral traits an agent cannot infer from the hint flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and sibling routing are front-loaded, and the three bullets each carry distinct, non-redundant guidance. It is denser than a minimal definition and a few clauses (e.g. the paging reminder) repeat schema text, but nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, and it doesn't. For a 12-parameter search tool it covers the remaining gaps — filter intersection semantics, paging stability, unpriced-listing handling, and the limits of verification — so an agent can call it correctly and interpret results honestly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 an upgrade by explaining cross-parameter interaction that the schema states only per-field — notably that include_unpriced does not cancel numeric price bounds, and that asking prices are neither bids nor valuations. The make/query split is also reinforced, though it largely restates the schema's own wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Discover cars for sale in JOY Auto Exchange') and immediately distinguishes itself from three siblings: get_vehicle for detail, compare_vehicles for shortlists, search_auctions for auction links. An agent can route correctly without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names alternatives and the conditions selecting them, plus tactical guidance on splitting make/query and on choosing a priced-budget search versus POA discovery. It even flags the failure mode (a combined 'Toyota Premio' phrase can miss listings), which is guidance no schema field provides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_auctionget_auction_statusprepare_buyer_handoffprepare_part_handoffv1.0.2compare_vehicles1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ },
+ "inspection": {
+ "additionalProperties": false,
+ "properties": {
+ "battery_health_percent": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "final_grade": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "identity_match": {
+ "type": [
+ "string",
+ "boolean",
+ "null"
+ ]
+ },
+ "overall_score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "qc_approved_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "repair_estimate_bdt": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "final_grade",
+ "overall_score",
+ "repair_estimate_bdt",
+ "battery_health_percent",
+ "identity_match",
+ "qc_approved_at"
+ ],
+ "type": "object"
+ },
+ "vehicle_detail": {
+ "additionalProperties": false,
+ "properties": {
+ "auction_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "body_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "condition": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "currency": {
+ "const": "BDT",
+ "type": "string"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fuel_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "hub": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "images": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 8,
+ "type": "array"
+ },
+ "inspection_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "listing_id": {
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,119}$",
+ "type": "string"
+ },
+ "make": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "mileage_km": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "model": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "price_bdt": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "transmission": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "trim": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "verified": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "verified_inspection": {
+ "$ref": "#/$defs/inspection"
+ },
+ "year": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "listing_id",
+ "make",
+ "model",
+ "trim",
+ "condition",
+ "fuel_type",
+ "transmission",
+ "body_type",
+ "hub",
+ "inspection_status",
+ "status",
+ "year",
+ "price_bdt",
+ "mileage_km",
+ "verified",
+ "description",
+ "auction_id",
+ "images",
+ "url",
+ "currency"
+ ],
+ "type": "object"
+ }
+ },
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "cheapest_listing_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "currency": {
+ "const": "BDT",
+ "type": "string"
+ },
+ "found_listing_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "known_price_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "known_price_listing_ids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "not_found": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "not_found_listing_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "price_comparison_complete": {
+ "type": "boolean"
+ },
+ "price_comparison_notice": {
+ "type": "string"
+ },
+ "requested_listing_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unavailable": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "http_status": {
+ "type": "integer"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "vehicle_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "vehicle_id",
+ "http_status",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "unavailable_listing_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unknown_price_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unknown_price_listing_ids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "vehicles": {
+ "items": {
+ "$ref": "#/$defs/vehicle_detail"
+ },
+ "maxItems": 4,
+ "type": "array"
+ }
+ },
+ "required": [
+ "currency",
+ "vehicles",
+ "not_found",
+ "unavailable",
+ "requested_listing_count",
+ "found_listing_count",
+ "not_found_listing_count",
+ "unavailable_listing_count",
+ "known_price_count",
+ "unknown_price_count",
+ "known_price_listing_ids",
+ "unknown_price_listing_ids",
+ "price_comparison_complete",
+ "cheapest_listing_id",
+ "price_comparison_notice"
+ ],
+ "type": "object"
+ },
+ {
+ "$ref": "#/$defs/error"
+ }
+ ],
+ "type": "object"
+}get_auction_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ },
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "auction_id": {
+ "pattern": "^[A-Za-z0-9_-]{1,64}$",
+ "type": "string"
+ },
+ "bid_count": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "bid_increment": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "currency": {
+ "const": "BDT",
+ "type": "string"
+ },
+ "current_bid": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "end_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "extension_count": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "minimum_next_bid": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ },
+ "start_price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "auction_id",
+ "title",
+ "status",
+ "start_price",
+ "current_bid",
+ "bid_increment",
+ "bid_count",
+ "end_at",
+ "extension_count",
+ "currency",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "$ref": "#/$defs/error"
+ }
+ ],
+ "type": "object"
+}get_buying_guide1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ },
+ "money": {
+ "additionalProperties": false,
+ "properties": {
+ "amount_minor": {
+ "description": "Minor currency units: 100 paisa = 1 BDT.",
+ "type": "integer"
+ },
+ "currency": {
+ "type": "string"
+ },
+ "major": {
+ "description": "Decimal amount in major currency units, formatted as text.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "amount_minor",
+ "currency",
+ "major"
+ ],
+ "type": "object"
+ }
+ },
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "const": "BDT",
+ "type": "string"
+ },
+ "delivery_zones": {
+ "items": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ "fitment_policy": {
+ "type": "string"
+ },
+ "free_delivery_threshold": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/money"
+ },
+ {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ ]
+ },
+ "how_to_buy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "human_sales_contact": {
+ "additionalProperties": false,
+ "properties": {
+ "whatsapp": {
+ "type": "string"
+ },
+ "whatsapp_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "whatsapp",
+ "whatsapp_url"
+ ],
+ "type": "object"
+ },
+ "languages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "live_terms_unavailable": {
+ "type": "boolean"
+ },
+ "market": {
+ "const": "Bangladesh",
+ "type": "string"
+ },
+ "minimum_order": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/money"
+ },
+ {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ ]
+ },
+ "payment_methods": {
+ "items": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ "vat_bps": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "market",
+ "currency",
+ "languages",
+ "human_sales_contact",
+ "how_to_buy",
+ "fitment_policy"
+ ],
+ "type": "object"
+ },
+ {
+ "$ref": "#/$defs/error"
+ }
+ ],
+ "type": "object"
+}get_part1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "classification": {
+ "additionalProperties": false,
+ "properties": {
+ "classification_status": {
+ "type": "string"
+ },
+ "installation_type": {
+ "type": "string"
+ },
+ "product_type": {
+ "type": "string"
+ },
+ "universal_accessory": {
+ "type": "boolean"
+ },
+ "universal_constraints_verified": {
+ "type": "boolean"
+ },
+ "universal_search_eligible": {
+ "type": "boolean"
+ },
+ "vehicle_specific": {
+ "type": "boolean"
+ }
+ },
+ "required": [],
+ "type": "object"
+ },
+ "constraints": {
+ "additionalProperties": false,
+ "properties": {
+ "constraint_type": {
+ "type": "string"
+ },
+ "required_fields": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 16,
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ },
+ "verified": {
+ "type": "boolean"
+ }
+ },
+ "required": [],
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ },
+ "fitment": {
+ "additionalProperties": false,
+ "properties": {
+ "chassis_code": {
+ "type": "string"
+ },
+ "engine": {
+ "type": "string"
+ },
+ "engine_codes": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 16,
+ "type": "array"
+ },
+ "fitment_confidence": {
+ "type": "string"
+ },
+ "jdm_chassis_codes": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 16,
+ "type": "array"
+ },
+ "make": {
+ "type": "string"
+ },
+ "model": {
+ "type": "string"
+ },
+ "year_from": {
+ "type": "integer"
+ },
+ "year_to": {
+ "type": "integer"
+ },
+ "years": {
+ "items": {
+ "type": "integer"
+ },
+ "maxItems": 200,
+ "type": "array"
+ }
+ },
+ "required": [],
+ "type": "object"
+ },
+ "hardware": {
+ "additionalProperties": false,
+ "properties": {
+ "application_note": {
+ "type": "string"
+ },
+ "fitment_policy": {
+ "type": "string"
+ }
+ },
+ "required": [],
+ "type": "object"
+ }
+ },
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "availability": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "bulk_pricing": {
+ "description": "Public storefront bulk-pricing metadata; not an accepted or locked quote.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "compatibility_constraints": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/constraints"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "currency": {
+ "const": "BDT",
+ "type": "string"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fitment_candidates": {
+ "items": {
+ "$ref": "#/$defs/fitment"
+ },
+ "maxItems": 8,
+ "type": "array"
+ },
+ "fitment_notice": {
+ "type": "string"
+ },
+ "hardware_specifications": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/hardware"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "minimum_order_quantity": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "oem_number": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "oem_reference_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "part_id": {
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+ },
+ "price_bdt": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price_label": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "product_characteristics": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/classification"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "sellable": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "stock_on_hand": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "suppression_reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verified_offer_count": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "part_id",
+ "name",
+ "oem_number",
+ "category",
+ "price_bdt",
+ "price_label",
+ "availability",
+ "stock_on_hand",
+ "minimum_order_quantity",
+ "sellable",
+ "fitment_candidates",
+ "url",
+ "oem_reference_status",
+ "suppression_reason",
+ "compatibility_constraints",
+ "hardware_specifications",
+ "product_characteristics",
+ "description",
+ "verified_offer_count",
+ "bulk_pricing",
+ "currency",
+ "fitment_notice"
+ ],
+ "type": "object"
+ },
+ {
+ "$ref": "#/$defs/error"
+ }
+ ],
+ "type": "object"
+}get_vehicle1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ },
+ "inspection": {
+ "additionalProperties": false,
+ "properties": {
+ "battery_health_percent": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "final_grade": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "identity_match": {
+ "type": [
+ "string",
+ "boolean",
+ "null"
+ ]
+ },
+ "overall_score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "qc_approved_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "repair_estimate_bdt": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "final_grade",
+ "overall_score",
+ "repair_estimate_bdt",
+ "battery_health_percent",
+ "identity_match",
+ "qc_approved_at"
+ ],
+ "type": "object"
+ },
+ "vehicle_detail": {
+ "additionalProperties": false,
+ "properties": {
+ "auction_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "body_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "condition": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "currency": {
+ "const": "BDT",
+ "type": "string"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fuel_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "hub": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "images": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 8,
+ "type": "array"
+ },
+ "inspection_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "listing_id": {
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,119}$",
+ "type": "string"
+ },
+ "make": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "mileage_km": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "model": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "price_bdt": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "transmission": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "trim": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "verified": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "verified_inspection": {
+ "$ref": "#/$defs/inspection"
+ },
+ "year": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "listing_id",
+ "make",
+ "model",
+ "trim",
+ "condition",
+ "fuel_type",
+ "transmission",
+ "body_type",
+ "hub",
+ "inspection_status",
+ "status",
+ "year",
+ "price_bdt",
+ "mileage_km",
+ "verified",
+ "description",
+ "auction_id",
+ "images",
+ "url",
+ "currency"
+ ],
+ "type": "object"
+ }
+ },
+ "oneOf": [
+ {
+ "$ref": "#/$defs/vehicle_detail"
+ },
+ {
+ "$ref": "#/$defs/error"
+ }
+ ],
+ "type": "object"
+}prepare_buyer_handoff1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "classification": {
+ "additionalProperties": false,
+ "properties": {
+ "classification_status": {
+ "type": "string"
+ },
+ "installation_type": {
+ "type": "string"
+ },
+ "product_type": {
+ "type": "string"
+ },
+ "universal_accessory": {
+ "type": "boolean"
+ },
+ "universal_constraints_verified": {
+ "type": "boolean"
+ },
+ "universal_search_eligible": {
+ "type": "boolean"
+ },
+ "vehicle_specific": {
+ "type": "boolean"
+ }
+ },
+ "required": [],
+ "type": "object"
+ },
+ "constraints": {
+ "additionalProperties": false,
+ "properties": {
+ "constraint_type": {
+ "type": "string"
+ },
+ "required_fields": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 16,
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ },
+ "verified": {
+ "type": "boolean"
+ }
+ },
+ "required": [],
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ },
+ "hardware": {
+ "additionalProperties": false,
+ "properties": {
+ "application_note": {
+ "type": "string"
+ },
+ "fitment_policy": {
+ "type": "string"
+ }
+ },
+ "required": [],
+ "type": "object"
+ }
+ },
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "availability": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "compatibility_constraints": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/constraints"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "fitment_notice": {
+ "type": "string"
+ },
+ "hardware_specifications": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/hardware"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "next_step": {
+ "type": "string"
+ },
+ "oem_number": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "oem_reference_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "part_id": {
+ "type": "string"
+ },
+ "pricing_notice": {
+ "type": "string"
+ },
+ "product_characteristics": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/classification"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "product_url": {
+ "type": "string"
+ },
+ "quantity": {
+ "maximum": 10000,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "sellable": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "side_effects": {
+ "type": "string"
+ },
+ "suppression_reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "whatsapp_order_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "part_id",
+ "quantity",
+ "name",
+ "oem_number",
+ "oem_reference_status",
+ "suppression_reason",
+ "compatibility_constraints",
+ "hardware_specifications",
+ "product_characteristics",
+ "availability",
+ "sellable",
+ "fitment_notice",
+ "pricing_notice",
+ "product_url",
+ "whatsapp_order_url",
+ "side_effects",
+ "next_step"
+ ],
+ "type": "object"
+ },
+ {
+ "$ref": "#/$defs/error"
+ }
+ ],
+ "type": "object"
+}prepare_vehicle_handoffsearch_auctionssearch_parts1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "classification": {
+ "additionalProperties": false,
+ "properties": {
+ "classification_status": {
+ "type": "string"
+ },
+ "installation_type": {
+ "type": "string"
+ },
+ "product_type": {
+ "type": "string"
+ },
+ "universal_accessory": {
+ "type": "boolean"
+ },
+ "universal_constraints_verified": {
+ "type": "boolean"
+ },
+ "universal_search_eligible": {
+ "type": "boolean"
+ },
+ "vehicle_specific": {
+ "type": "boolean"
+ }
+ },
+ "required": [],
+ "type": "object"
+ },
+ "constraints": {
+ "additionalProperties": false,
+ "properties": {
+ "constraint_type": {
+ "type": "string"
+ },
+ "required_fields": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 16,
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ },
+ "verified": {
+ "type": "boolean"
+ }
+ },
+ "required": [],
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ },
+ "fitment": {
+ "additionalProperties": false,
+ "properties": {
+ "chassis_code": {
+ "type": "string"
+ },
+ "engine": {
+ "type": "string"
+ },
+ "engine_codes": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 16,
+ "type": "array"
+ },
+ "fitment_confidence": {
+ "type": "string"
+ },
+ "jdm_chassis_codes": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 16,
+ "type": "array"
+ },
+ "make": {
+ "type": "string"
+ },
+ "model": {
+ "type": "string"
+ },
+ "year_from": {
+ "type": "integer"
+ },
+ "year_to": {
+ "type": "integer"
+ },
+ "years": {
+ "items": {
+ "type": "integer"
+ },
+ "maxItems": 200,
+ "type": "array"
+ }
+ },
+ "required": [],
+ "type": "object"
+ },
+ "hardware": {
+ "additionalProperties": false,
+ "properties": {
+ "application_note": {
+ "type": "string"
+ },
+ "fitment_policy": {
+ "type": "string"
+ }
+ },
+ "required": [],
+ "type": "object"
+ },
+ "part": {
+ "additionalProperties": false,
+ "properties": {
+ "availability": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "compatibility_constraints": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/constraints"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "fitment_candidates": {
+ "items": {
+ "$ref": "#/$defs/fitment"
+ },
+ "maxItems": 8,
+ "type": "array"
+ },
+ "hardware_specifications": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/hardware"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "minimum_order_quantity": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "oem_number": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "oem_reference_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "part_id": {
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+ },
+ "price_bdt": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price_label": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "product_characteristics": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/classification"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "sellable": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "stock_on_hand": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "suppression_reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "part_id",
+ "name",
+ "oem_number",
+ "category",
+ "price_bdt",
+ "price_label",
+ "availability",
+ "stock_on_hand",
+ "minimum_order_quantity",
+ "sellable",
+ "fitment_candidates",
+ "url",
+ "oem_reference_status",
+ "suppression_reason",
+ "compatibility_constraints",
+ "hardware_specifications",
+ "product_characteristics"
+ ],
+ "type": "object"
+ }
+ },
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "const": "BDT",
+ "type": "string"
+ },
+ "fitment_notice": {
+ "type": "string"
+ },
+ "items": {
+ "items": {
+ "$ref": "#/$defs/part"
+ },
+ "maxItems": 20,
+ "type": "array"
+ },
+ "page": {
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "page_size": {
+ "maximum": 20,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "query_interpreted_as": {
+ "type": "string"
+ },
+ "total": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "page",
+ "page_size",
+ "currency",
+ "items",
+ "fitment_notice"
+ ],
+ "type": "object"
+ },
+ {
+ "$ref": "#/$defs/error"
+ }
+ ],
+ "type": "object"
+}search_vehicles1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ },
+ "vehicle": {
+ "additionalProperties": false,
+ "properties": {
+ "body_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "browse_url": {
+ "type": "string"
+ },
+ "condition": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fuel_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "hub": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "image": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "inspection_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "listing_id": {
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,119}$",
+ "type": "string"
+ },
+ "make": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "mileage_km": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "model": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "price_bdt": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "transmission": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "trim": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verified": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "year": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "listing_id",
+ "make",
+ "model",
+ "trim",
+ "condition",
+ "fuel_type",
+ "transmission",
+ "body_type",
+ "hub",
+ "inspection_status",
+ "status",
+ "year",
+ "price_bdt",
+ "mileage_km",
+ "verified",
+ "image",
+ "browse_url"
+ ],
+ "type": "object"
+ }
+ },
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "const": "BDT",
+ "type": "string"
+ },
+ "items": {
+ "items": {
+ "$ref": "#/$defs/vehicle"
+ },
+ "maxItems": 20,
+ "type": "array"
+ },
+ "page": {
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "page_size": {
+ "maximum": 20,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "total": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "page",
+ "page_size",
+ "currency",
+ "items"
+ ],
+ "type": "object"
+ },
+ {
+ "$ref": "#/$defs/error"
+ }
+ ],
+ "type": "object"
+}v1.0.1compare_vehicles1 field changedInput schema / properties / vehicle_ids / descriptionAdded value: +"Two to four listing_id values from search_vehicles or public listing slugs, not VINs or URLs. Choose distinct listings; repeated IDs or an ID and its slug do not provide separate price evidence."get_auction_status1 field changedInput schema / properties / auction_id / descriptionAdded value: +"Non-empty auction_id returned by get_vehicle for an auction-linked listing, or a known public auction ID provided by the buyer. At most 64 letters/digits/underscores/hyphens; not a vehicle listing_id or URL. Do not fabricate an ID when none is returned."get_part1 field changedInput schema / properties / part_id / descriptionAdded value: +"Exact catalogue part_id copied from search_parts, e.g. BRK-AXIO-01. This is JOY's catalogue identifier, not an OEM part number or a product URL."get_vehicle1 field changedInput schema / properties / vehicle_id / descriptionPrevious value: -"listing_id or slug from search_vehicles."New value: +"listing_id returned by search_vehicles, or slug from a public JOY listing URL. Use only the ID/slug (letters/digits, dots, underscores, hyphens; starts with a letter/digit), not the URL, VIN or registration number."prepare_buyer_handoff4 fields changedInput schema / properties / note / descriptionAdded value: +"Optional buyer request included verbatim as a note in the pre-filled WhatsApp message, up to 300 characters. It is not sent until the human chooses to send the message."Input schema / properties / part_id / descriptionAdded value: +"Exact part_id from search_parts/get_part for the selected item; not an OEM reference or product URL. The tool fetches fresh public part detail before composing the links."Input schema / properties / quantity / descriptionAdded value: +"Requested item count inserted into the WhatsApp message, 1 through 10,000; defaults to 1. Does not reserve quantity, satisfy minimum order rules or multiply/lock a payable quote."Input schema / properties / vehicle / descriptionPrevious value: -"Make, model, year or VIN, to speed up fitment checks."New value: +"Optional make/model/year, chassis or VIN text included in the human message for fitment review; not automatically decoded or proof of compatibility."search_parts10 fields changedInput schema / properties / category / descriptionAdded value: +"Public category label from a catalogue result, e.g. Brakes. Omit if the category is unknown."Input schema / properties / chassis / descriptionPrevious value: -"Chassis code, e.g. NZE141 or G05."New value: +"Vehicle chassis/model code, e.g. NZE141 or G05; not a full VIN. Narrows candidates and does not certify fitment."Input schema / properties / in_stock_only / descriptionAdded value: +"True requests currently in-stock candidates; false (default) permits other public availability states. This does not reserve stock."Input schema / properties / include_rfq_catalogue / descriptionPrevious value: -"Include catalogue-only templates available through a parts request (RFQ)."New value: +"True also includes catalogue-only templates requiring a human parts request; false (default) omits them. Inclusion does not make an item directly purchasable."Input schema / properties / make / descriptionPrevious value: -"Vehicle make, e.g. Toyota."New value: +"Vehicle manufacturer, e.g. Toyota; narrows part candidates alongside the query. Omit if unknown."Input schema / properties / max_price_bdt / descriptionAdded value: +"Inclusive maximum retail asking price in Bangladesh taka (BDT), e.g. 5000 means ৳5,000; omit for no budget ceiling. Not lakh units and not a currency conversion."Input schema / properties / page / descriptionAdded value: +"One-based results page, 1 through 500; defaults to 1. Increment to retrieve the next page with the same filters."Input schema / properties / page / maximumAdded value: +500Input schema / properties / page_size / descriptionAdded value: +"Maximum results requested per page, 1 through 20; defaults to 10. total describes all matches, not this page's item count."Input schema / properties / query / descriptionPrevious value: -"Part name, OEM number or vehicle, in English or Bangla."New value: +"Part name, OEM reference or vehicle words in English, Bangla or Banglish; e.g. 'Axio brake pads' or 'টয়োটা এক্সিও ব্রেক প্যাড'. Omit for filtered browsing; not a part_id lookup."search_vehicles17 fields changedInput schema / properties / fuel_type / descriptionAdded value: +"Case-insensitive prefix of a public listing's fuel label, e.g. hybrid. Copy a known label where possible; omit to include all fuel types."Input schema / properties / include_unpriced / descriptionPrevious value: -"Include vehicles with a pending or undisclosed asking price (POA)."New value: +"True includes price-on-application or otherwise unpriced listings; false (default) excludes them. A missing asking price is unknown, never zero."Input schema / properties / make / descriptionAdded value: +"Case-insensitive manufacturer prefix, e.g. Toyota. Combine with query='Premio' for that model; omit to include all makes."Input schema / properties / max_price_bdt / descriptionAdded value: +"Inclusive maximum stated asking price in Bangladesh taka, e.g. 3000000 means ৳30 lakh. Omit for no maximum; no less than min_price_bdt."Input schema / properties / max_year / descriptionAdded value: +"Inclusive latest model year, 1950 through 2100. Omit for no upper-year filter; supply a value no less than min_year."Input schema / properties / max_year / maximumAdded value: +2100Input schema / properties / max_year / minimumAdded value: +1950Input schema / properties / min_price_bdt / descriptionAdded value: +"Inclusive minimum stated asking price in Bangladesh taka, e.g. 2000000 means ৳20 lakh. Omit for no minimum; no greater than max_price_bdt."Input schema / properties / min_year / descriptionAdded value: +"Inclusive earliest model year, 1950 through 2100. Omit for no lower-year filter; supply a value no greater than max_year."Input schema / properties / min_year / maximumAdded value: +2100Input schema / properties / min_year / minimumAdded value: +1950Input schema / properties / page / descriptionAdded value: +"One-based results page, 1 through 500; defaults to 1. Keep filters and sort unchanged when paging."Input schema / properties / page / maximumAdded value: +500Input schema / properties / page_size / descriptionAdded value: +"Maximum results requested per page, 1 through 20; defaults to 10. total is the matching population, which may exceed this page's item count."Input schema / properties / query / descriptionAdded value: +"Case-insensitive phrase within make, model or trim; use query='Premio' with make='Toyota', not one combined 'Toyota Premio' phrase. Known Bangla/Banglish vocabulary is normalized; unsupported words may be dropped. Use known English model words for precision; omit to browse."Input schema / properties / sort / descriptionAdded value: +"Result order: latest (default: verified first, then newest), price_asc (lowest stated price first), price_desc (highest first), or year_desc (newest model year first). Stable tie-breaks support paging; no valuation is performed."Input schema / properties / verified_only / descriptionAdded value: +"True requires the storefront's verified flag, approved inspection status and a non-empty inspection ID; false (default) also permits other public listings. Verification is not a vehicle warranty."v1.0.0compare_vehiclesget_auction_statusget_buying_guideget_partget_vehicleprepare_buyer_handoffsearch_partssearch_vehiclesScored across 10 tools
Each tool targets a distinct resource+action: search/get pairs for parts, vehicles and auctions, plus compare_vehicles, get_buying_guide and the two prepare_*_handoff tools. The only mild overlap is search_vehicles vs search_auctions (auctions scan vehicle listings), but the descriptions explicitly redirect between them so an agent can distinguish them.
All ten tools follow a consistent snake_case verb_noun pattern (search_*, get_*, compare_vehicles, prepare_*_handoff). The singular/plural distinction (search_parts vs get_part, search_vehicles vs get_vehicle) is a sensible and consistent convention rather than an inconsistency.
Ten tools is well-scoped for a marketplace covering three resource families (parts, vehicles, auctions) plus comparison, terms, and handoffs. Every tool earns its place with no redundancy or filler.
The surface covers the full public research workflow for each domain: discovery, detail, comparison, auction status, terms, and human handoff endpoints for both parts and vehicles. Read-only/anonymous scope is intentional and explicitly noted, with no dead ends within that stated purpose.
Automotive inventory search for AI assistants: vehicles, dealers, deals, and market data.
AI-native used car marketplace. 145K+ vehicles, 4300+ dealers, 13 US states, 20 MCP tools.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
AI marketplace: search, buy, sell across Amazon, eBay, AliExpress. 13 tools.
