Skip to main content
Glama
www-joyautomart-com

JOY Automart MCP Server

Official
by www-joyautomart-com
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Prepare purchase handoff

prepare_buyer_handoff
Read-onlyIdempotent

Builds a product link and pre-filled WhatsApp message for a selected part, letting a human buyer review details and choose whether to send it.

Instructions

Compose a product link and pre-filled WhatsApp message for a human buyer's selected part. Use part_id from search_parts/get_part; use get_buying_guide for general terms, not this tool. Quantity is a requested item count, not a purchase commitment; vehicle and note are inserted into the message alongside canonical part details, fitment limitations and pricing/eligibility notices. Returns product_url, whatsapp_order_url, quantity, part evidence, fitment_notice, pricing_notice and next_step. Creating the links does not open WhatsApp, send anything, create an RFQ, reserve stock, charge money or order; the human chooses whether to open and send the message. Links carry no reservation or price lock. Unsellable/fitment-restricted parts retain their restrictions; handoff never clears them. Unknown part IDs or unavailable detail return isError=true with structuredContent.error.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional 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.
part_idYesExact 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.
vehicleNoOptional make/model/year, chassis or VIN text included in the human message for fitment review; not automatically decoded or proof of compatibility.
quantityNoRequested 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.1
    • addedInput schema / properties / note / description
      Added 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."
    • addedInput schema / properties / part_id / description
      Added 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."
    • addedInput schema / properties / quantity / description
      Added 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."
    • changedInput schema / properties / vehicle / description
      Previous 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."
  2. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint/idempotentHint, and the description reinforces this with concrete, non-obvious detail: no WhatsApp opening, no send, no RFQ, no stock reservation, no charge, no price lock, and restrictions preserved on unsellable parts. It also documents the failure mode (isError=true with structuredContent.error for unknown IDs), which 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.

Conciseness4/5

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

Front-loaded with purpose and sibling routing, then side-effect disclaimers, so the most decision-relevant content comes first. It is dense and runs long as one block, but nearly every sentence carries distinct information about side effects or semantics.

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?

Although no output schema exists, the description enumerates the return fields (product_url, whatsapp_order_url, quantity, part evidence, fitment_notice, pricing_notice, next_step) and the error shape. Combined with the read-only annotations and full schema coverage, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds real interpretation by clarifying that quantity is a requested count rather than a purchase commitment or reservation, and that vehicle/note are inserted into the message. The remaining gap is minor — no added syntax detail beyond the schema's verbatim-insertion notes.

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 opens with a specific verb+resource: composing a product link and pre-filled WhatsApp message for a human buyer's selected part. It explicitly distinguishes itself from the adjacent tool get_buying_guide, so an agent can route correctly without inspecting schemas.

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 states precisely when to use this tool ('Use part_id from search_parts/get_part') and when not to ('use get_buying_guide for general terms, not this tool'), naming the exact alternative and the condition selecting it. It also defines the terminal handoff point where the human decides to send.

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

Deploy Server

Other Tools