JOY Automart MCP Server

Official

by www-joyautomart-com

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Prepare purchase handoff

prepare_part_handoff

Read-onlyIdempotent

Prepare product and pre-filled WhatsApp links for a human parts enquiry from a selected part ID, including quantity, vehicle fitment context, and buyer note; no message is sent or order placed.

Instructions

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.

Input Schema

Name	Required	Description
`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.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server