Gemalli B2B Trade

Request a quote

request_quote

Send a request for prices, samples or terms to a manufacturer on the person's behalf. Requires the person's own name and email — ask them and pass exactly what they give you, never invent an address. The manufacturer receives the request; the person receives an email with a sign-in link where the reply and the supplier's contacts appear. No account is needed beforehand. Use it once they have chosen a supplier.

Input Schema

TableJSON Schema

Name	Required	Description
`locale`	No
`message`	Yes	What they need: specs, volumes, target price, delivery terms.
`quantity`	No	Desired quantity.
`agent_name`	No	Name of the agent or platform sending this, e.g. "Claude" — recorded as the source.
`buyer_name`	Yes	The person's name, as they gave it.
`product_id`	No	Product the request is about, if one was chosen.
`buyer_email`	Yes	The person's real email — the reply and the sign-in link go there.
`variant_key`	No	Version of that product the person chose, when get_product lists `variants` (e.g. "400v"). Requires product_id. The manufacturer sees the version and its model code in the request.
`operation_id`	No	Optional idempotency key for this attempt. Retrying with the SAME operation_id returns the original result instead of creating a second RFQ — send one if your transport can retry. No token needed: an anonymous person is scoped by the buyer_email you pass.
`buyer_company`	No	Their company name, if known.
`buyer_country`	No	ISO 3166-1 alpha-2 country of the buyer.
`manufacturer_slug`	Yes	Target manufacturer slug, from search_products or list_manufacturers.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 13, 2026
- addedInput schema / properties / variant_key / maxLength
```
Added value: +40
```
- addedInput schema / properties / variant_key / pattern
```
Added value: +"^[a-z0-9][a-z0-9-]{0,39}$"
```

Changed1 schema field changedSep 13, 2026

addedInput schema / properties / variant_key

Added value: +{
+  "description": "Version of that product the person chose, when get_product lists `variants` (e.g. \"400v\"). Requires product_id. The manufacturer sees the version and its model code in the request.",
+  "type": "string"
+}

Changed3 schema fields changedSep 12, 2026

changedInput schema / properties / buyer_email / description

Previous value: -"Your principal's real email — the reply and the sign-in link go there."New value: +"The person's real email — the reply and the sign-in link go there."

changedInput schema / properties / buyer_name / description

Previous value: -"Your principal's name, as they gave it."New value: +"The person's name, as they gave it."

changedInput schema / properties / operation_id / description

Previous value: -"Optional idempotency key for this attempt. Retrying with the SAME operation_id returns the original result instead of creating a second RFQ — send one if your transport can retry. No token needed: an anonymous caller is scoped by the buyer_email you pass."New value: +"Optional idempotency key for this attempt. Retrying with the SAME operation_id returns the original result instead of creating a second RFQ — send one if your transport can retry. No token needed: an anonymous person is scoped by the buyer_email you pass."

Changed1 schema field changedSep 8, 2026

addedInput schema / properties / operation_id

Added value: +{
+  "description": "Optional idempotency key for this attempt. Retrying with the SAME operation_id returns the original result instead of creating a second RFQ — send one if your transport can retry. No token needed: an anonymous caller is scoped by the buyer_email you pass.",
+  "type": "string"
+}

AddedSep 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only say readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the description usefully fills in what actually happens: the manufacturer receives the request, the person receives an email with a sign-in link, and no account is required first. It also warns against inventing an email address, which is a real behavioral constraint. It doesn't cover retry/rate-limit behavior in the description, though idempotency is covered in the schema.

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?

Five sentences, each carrying distinct information (purpose, contact-input constraint, recipient behavior, no-account prerequisite, usage trigger), with the core action front-loaded. Dense but not padded.

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

Completeness4/5

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

For a 12-parameter mutation tool with no output schema, the description covers the essential context: what is sent, who receives what, and the no-account prerequisite. Idempotency and field-level semantics live in the schema, so nothing critical is missing, though a note on the response the caller sees would round it out.

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 already 92%, so the baseline is 3. The description adds meaningful value on top: 'ask them and pass exactly what they give you, never invent an address' constrains how buyer_name and buyer_email should be populated, which the schema alone does not convey.

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 ('Send a request for prices, samples or terms to a manufacturer') and clarifies the on-behalf-of framing. This clearly separates it from sibling write tools like partnership_inquiry or submit_join_request, which have different targets and purposes.

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

Usage Guidelines4/5

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

It gives a clear trigger ('Use it once they have chosen a supplier') and notes 'No account is needed beforehand.' It stops short of explicitly naming alternative tools or when NOT to use this one, but the preconditions are clear enough for correct selection.

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

All Gemalli B2B Trade tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?