Egonex

Get the full price before ordering

quote_order

Read-only

Get the full price before your user orders: the items (price × quantity, at the agreed price with deal_id), shipping, sales tax and the total in USD, when the charge happens, and Egonex buyer protection (returns and refunds follow it). It only reads: nothing is ordered, reserved or charged. Pass offer_id for a new order, or request_id for an order already sent to the seller (when the seller accepts first: quote it once check_request shows ready_to_pay, right before the pay_order that charges). For an item that ships pass shipping_address; for other items, where Egonex adds sales tax, pass buyer_location. Egonex uses them only to calculate shipping and sales tax and doesn't store them. Returns a quote_id that lasts 15 minutes: pass it to request_order and pay_order, and get a payment token for exactly total. pay_order then charges exactly that total, or nothing when something changed or the quote expired (quote_changed / quote_expired): call quote_order again. Quotes that calculate sales tax are limited to 15 a minute for the same listing from the same client (slow_down). Errors end with their code in parentheses.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "quote_order"
  }
}

Input Schema

Name	Required	Description
`deal_id`	No	With offer_id, optional: deal.id from an ask_seller answer in which Ego agreed a price with you for this listing.
`offer_id`	No	For a new order: the listing id from search_offers (the 8-character id at the end of a listing page URL also works).
`quantity`	No	With offer_id: how many units (items, hours, sessions...). Default 1.
`request_id`	No	Instead of offer_id, for an order already sent to the seller: the id from request_order. The quote is for that order as it was sent (its quantity and price).
`variant_id`	No	With offer_id, required for a listing with options (its variants): the id of the variant your user chose; the quote uses that variant's price.
`buyer_location`	No	For an item that doesn't ship, where Egonex adds sales tax: the billing address of the card your user will pay with. pay_order calculates the tax from that card's billing address, so give the full address (street, city, state, ZIP code) when you can.
`shipping_address`	No	For an item that ships: where your user wants it shipped, the same object you will pass to pay_order (the recipient's name isn't needed here).

Output Schema

Name	Required	Description
`next`	Yes	What to do next.
`unit`	Yes	What one unit is (as in the listing's price).
`items`	Yes	unit_price × quantity, USD.
`title`	Yes	The listing's title.
`total`	Yes	items + shipping + sales_tax, USD.
`charge`	Yes	When the money is taken (charge_note says how).
`deal_id`	No	The agreed price the quote uses (from ask_seller); absent without one.
`variant`	No	For a listing with options: the variant's values, e.g. Black / M.
`currency`	Yes	usd.
`offer_id`	Yes	The listing.
`quantity`	Yes	Units quoted.
`quote_id`	Yes	Pass it to request_order and pay_order before expires_at.
`shipping`	Yes	Shipping in USD, once per order (0 when it doesn't ship or ships free).
`sales_tax`	Yes	Sales tax in USD (0 when sales_tax_collected is false).
`expires_at`	Yes	The quote works until then (RFC 3339).
`request_id`	No	With request_id: the request whose order the quote is for (use it only with that request's pay_order).
`unit_price`	Yes	USD per unit (the agreed price when the quote has deal_id).
`variant_id`	No	For a listing with options: the variant quoted; absent otherwise.
`charge_note`	Yes	When the charge happens and what happens if the seller declines.
`buyer_protection`	Yes	Egonex buyer protection (returns and refunds always follow it).
`sales_tax_collected`	Yes	false = Egonex doesn't add sales tax to this order.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 10, 2026

addedInput schema / properties / variant_id

Added value: +{
+  "description": "With offer_id, required for a listing with options (its variants): the id of the variant your user chose; the quote uses that variant's price.",
+  "type": "string"
+}

addedOutput schema / properties / variant

Added value: +{
+  "description": "For a listing with options: the variant's values, e.g. Black / M.",
+  "type": "string"
+}

addedOutput schema / properties / variant_id

Added value: +{
+  "description": "For a listing with options: the variant quoted; absent otherwise.",
+  "type": "string"
+}

Changed2 schema fields changedNov 8, 2026

changedOutput schema / properties / buyer_protection / description

Previous value: -"Egonex buyer protection."New value: +"Egonex buyer protection (returns and refunds always follow it)."

removedOutput schema / properties / shop_rules

Removed value: -{
-  "description": "The shop's own return rules, when the seller wrote them.",
-  "items": {
-    "properties": {
-      "label": {
-        "description": "Returns or Not returnable.",
-        "type": "string"
-      },
-      "value": {
-        "description": "What the shop says.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "label",
-      "value"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}

AddedNov 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description adds substantial context beyond them: nothing is ordered, reserved or charged; the returned quote_id expires in 15 minutes; pay_order charges exactly the quoted total or nothing on quote_changed/quote_expired; sales-tax quotes are rate limited to 15/minute per listing per client with a slow_down code; and the address inputs are not stored. This is unusually rich behavioral disclosure for a read-only tool.

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 value proposition is front-loaded and every clause carries operational information (expiry, error codes, rate limit). It is a single dense paragraph with some redundancy, e.g. the charging behavior of pay_order is restated, and the flow narrative could be split for scanning, but little is genuinely wasted.

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

Completeness5/5

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

For a 7-parameter, nested-object tool with an output schema, the description supplies the full lifecycle: when to call it, which id to pass, what the quote_id is used for downstream, expiry handling, retry guidance, and error-code conventions. An agent has everything needed to invoke it correctly on the first attempt.

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

Parameters5/5

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

With 100% schema coverage the baseline is 3, but the description adds value the schema cannot: the conditional pairing of offer_id versus request_id as mutually exclusive modes, the meaning of a deal-negotiated price via deal_id, and the rule that shipping_address applies to shipped items while buyer_location applies to non-shipping items where tax is calculated from the card's billing address.

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 and resource: it returns the full price breakdown (items at the agreed price, shipping, sales tax, USD total) for an order before charging. It explicitly separates this from the write siblings by naming pay_order and request_order and their role in the flow, so an agent can distinguish quote_order from them 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 exactly which identifier selects which mode: offer_id for a new order, request_id for an order already sent to the seller. It goes further and names the trigger condition ('once check_request shows ready_to_pay, right before the pay_order that charges') and the alternative path when the seller accepts first, leaving nothing to inference.

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

All Egonex 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?