Skip to main content
Glama

Preview a refund before asking for it

preview_refund
Read-only

See what a refund request for an order would do before your user decides. Pass the request_id and the amount your user wants back in USD (up to order.amount, which includes shipping; sales tax is refunded in proportion). It only reads: nothing is requested or changed. Returns the path (refund_now: the seller hasn't marked the order delivered, so it is refunded right away and the order is canceled; seller_decides: the seller has 48 hours to agree or disagree, no answer counts as agreeing, and if they disagree, Egonex members vote or Egonex decides), and for each possible outcome what your user gets back and every deduction: your user's share of the payment processing fee (processing_fee_paid_by says who pays it: it depends on the reason, see rules), the review fee when members vote to refund (2% of the order, at least $0.50), shipping that isn't refunded when the seller disagrees, and the sales tax refunded. After the seller marked the order delivered, also pass reason_category as your user says: not_received or damaged_or_not_as_described for any order, changed_mind only for a physical item (services and digital products don't have it; listing_kind says which). It decides who pays the payment processing fee and whether the item goes back, caps a changed_mind refund at the item price (max_refund: the original shipping isn't refunded), and request_refund uses it. For a shipped physical item, return says what the seller can choose (ask for the item back or refund without it), what happens if they don't answer, who pays the return shipping and the deadlines: ship within 7 days, the money comes back when the seller confirms receipt or 3 days after delivery, and nothing is refunded when nothing is shipped in time. Also the deadline for the seller, Egonex's refund rules, Egonex buyer protection, and a preview_id that request_refund can use for 15 minutes. Your user sees these amounts and deductions before deciding. Needs your user's Egonex account connected to you with permission to act for them (egonex.write), and that account must be the order's buyer: without such a connection (none, or a read-only one), nothing is done and the result is an error ending in (connection_required); when the connected account isn't the order's buyer, nothing is done (not_found). Without a connection, this is done on Egonex, in your user's chat with the seller. At most 5 calls a minute per connected account (slow_down). (It needs egonex.write, like request_refund, because only request_refund can use its preview_id.) A refund can be requested once per order, while it is paid and not completed: otherwise the error says why (refund_not_allowed, refund_already_requested; payment_processing right after the payment, for a minute). At most 30 previews an hour per connected account (slow_down). Errors end with their code in parentheses.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "request_id": "<request_id>",
      "amount": "<amount>"
    },
    "name": "preview_refund"
  }
}

Input Schema

NameRequiredDescriptionDefault
amountYesHow much your user wants back, in USD with at most 2 decimals: up to order.amount (items and shipping). Sales tax comes back in proportion on top.
request_idYesThe id returned by request_order (check_request shows the order it led to).
reason_categoryNoWhy your user wants the refund, as they say: required after the seller marked the order delivered (check_request status delivered), ignored before. changed_mind is only for a physical item. It decides who pays the payment processing fee and whether the item goes back; request_refund uses the same one.

Output Schema

NameRequiredDescriptionDefault
nextYesWhat happens next.
pathYesrefund_now (refunded right away, the order is canceled) or seller_decides (the seller answers first).
rulesYesEgonex's refund rules.
amountYesThe amount asked for, USD (items and shipping, before sales tax).
returnNoAfter delivery, for a shipped physical item: whether and how it goes back.
currencyYesusd.
order_idYesThe order.
outcomesYesEach possible outcome: what your user gets back and every deduction.
shippingNoShipping in the order amount, USD; absent when the order has none.
sales_taxYesSales tax paid on the order, USD (refunded in proportion).
expires_atYesrequest_refund can use preview_id until then (RFC 3339).
max_refundNoWith this reason the refund is at most this, USD: the item price, without the original shipping (physical changed_mind).
preview_idYesPass it to request_refund with the same request_id and amount before expires_at.
request_idYesThe request.
listing_kindYesWhat was bought: physical, service or digital (after delivery, changed_mind is only for physical).
order_amountYesThe most that can be asked for, USD: the order amount (items and shipping).
processing_feeYesThe payment processing fee of this payment, USD; who pays it, and how much, is in each outcome.
reason_categoryNoAfter the seller marked the order delivered: the reason used, which decides who pays the payment processing fee.
buyer_protectionYesEgonex buyer protection.
seller_respond_byNoseller_decides: if asked now, the seller answers by then (RFC 3339).
seller_missed_delivery_deadlineNoThe seller is past the delivery deadline and hasn't marked the order delivered: asking now refunds the whole order (whatever amount), and the seller pays the payment processing fee.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this ('It only reads: nothing is requested or changed'). Beyond that it discloses auth requirements (egonex.write, connected account must be the order's buyer), concrete failure codes (connection_required, not_found, refund_not_allowed, refund_already_requested, slow_down, payment_processing), rate limits (5/minute, 30/hour), and preview_id lifetime of 15 minutes — none of which the annotations carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The first sentence is well front-loaded, but the body is a roughly 300-word run-on chain of parenthetical clauses that mixes refund policy, fee arithmetic, return-shipping deadlines, and rate limits into single sentences. Much of that detail is explanatory background rather than call-selection guidance, and the nesting makes it hard to scan.

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 preview tool with three parameters, an output schema, and an auth requirement, the description covers eligibility, permissions, error taxonomy, throttling, and the preview_id handoff. Nothing an agent needs to invoke it correctly or explain results to a user appears to be missing.

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, but the description adds real meaning: amount is capped at order.amount including shipping with tax refunded proportionally, and reason_category changes who pays the processing fee, whether the item goes back, and caps a changed_mind refund at the item price excluding original shipping. That is substantive interpretation beyond the schema text.

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 opening sentence gives a specific verb and resource ('See what a refund request for an order would do') and frames it as a pre-decision preview. It explicitly distinguishes itself from the sibling request_refund by noting that only request_refund can consume its preview_id, so an agent can separate the two 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.

Usage Guidelines4/5

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

It states the use case (before your user decides) and the conditions that change the call: pass reason_category only after the seller marked the order delivered, and skip it before. It also gives a fallback when no account is connected (do it on Egonex in the user's chat with the seller). It stops short of an explicit 'call request_refund to execute' instruction, relying on the preview_id mention.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources