Skip to main content
Glama
Sign In

Egonex

by ai.egonex
OverviewDiscussionsAdmin

Pay for an order with a Stripe Shared Payment Token

pay_order
Destructive

Pay for an order made with request_order without the confirm page, using a Stripe Shared Payment Token that your user approved (for example in Stripe Link). request_order returns payment: the amount per unit in USD, max_quantity and payment_handlers with the Stripe network_id to issue the token to; the token must allow at least amount × quantity in USD (plus sales tax where Egonex collects it, calculated from the shipping address for an item that ships and from the card's billing address otherwise; if the token doesn't cover it, nothing is charged and the error gives the total). Egonex creates the order for your user (a guest account on the email you give; receipts and seller replies go to that email). The result has the same status and order as check_request (order has its title, quantity, amount and deadlines), so you can tell your user where the order stands. The seller confirms an order before the buyer pays: when the result has status waiting_for_seller, the order was sent to the seller and nothing was charged; once check_request shows ready_to_pay, call pay_order again with the same request_id and buyer_email and a valid token (or your user pays from the link Egonex emails them). If the seller declines or doesn't respond, the order closes and nothing is charged. When the result has status paid and order.accept_by, the token was charged first and the seller has until then to accept; if they decline or don't respond, your user is refunded minus the payment processing fee. For an item that ships (payment.requires_shipping_address), the pay_order call that charges must have shipping_address and shipping_address_confirmed=true, otherwise nothing is charged (shipping_address_required / shipping_address_not_confirmed): before you pay, ask your user for the full address, read it back to them and pass it only once they say it's right. A call that only sends the order to the seller charges nothing and doesn't keep an address: pass it on the call that pays. An address that fails the format check (the error names the field) or that Stripe can't place for sales tax is refused with shipping_address_invalid, and nothing is charged. The address becomes the order's shipping address only once the payment goes through (if it doesn't, nothing is kept and you can retry with a corrected address); order.ship_to then shows its city, state, ZIP code and country (never the name or street). After payment pay_order can't change it: a different address is refused (shipping_address_locked), and your user tells the seller in the Egonex chat instead. If your user pays on Egonex (the confirm page, or the link in Egonex's email), they enter the address there and no address you passed is used. If the email already has an Egonex account, nothing is charged and your user should pay on the confirm_url page instead. If Stripe declines the token, nothing is charged and check_request shows payment_failed: retry with a new token and the same buyer_email, or give confirm_url to your user. If the payment couldn't be confirmed (payment_error), it may or may not have gone through: don't call pay_order again while check_request shows payment_in_progress (Egonex is checking with Stripe, usually a few minutes; nothing is charged twice meanwhile). When it no longer does: if it shows paid, nothing more is needed; if it shows payment_failed or ready_to_pay, ask your user for a new approval and call pay_order again with the new token (not the same one). If the listing sold out meanwhile, or there aren't that many left, nothing is charged (sold_out / stock_short; stock_short says how many are left when it is 3 or fewer): search again, or call pay_order again with a smaller quantity. If the seller isn't taking new orders right now and hasn't accepted this order yet, nothing is charged (seller_not_taking_orders): choose another listing, or ask the seller with ask_seller. Errors end with their code in parentheses, the same code the REST API returns (for example (shipping_address_required), (invalid_input), (not_found)). After an order is placed, everything about it (confirming delivery, a problem with it, a refund or a cancellation) is handled on Egonex, in your user's chat with the seller (a buyer without an Egonex account opens it from the link in Egonex's email), not through these tools. Only call this after your user agreed to the purchase and to Egonex's terms.

Input Schema

NameRequiredDescriptionDefault
quantityNoHow many units (items, hours, sessions...) at the listed price. Default 1.
buyer_nameNoOptional name shown to the seller.
request_idYesThe id returned by request_order.
buyer_emailYesYour user's email address. Receipts, the order and seller replies go there.
accept_termsYestrue only if your user agreed to Egonex's Terms of Service and Privacy Policy (payment.terms_url).
delivery_daysNoDays the seller has to deliver once the order starts (it starts when it is paid and accepted): shipping time for an item, the day of the lesson or service, 1 for digital goods. Default: the listing's delivery_days when it has one, else 3.
shipping_addressNoFor an item that ships (payment.requires_shipping_address): where to ship it, as your user confirmed it. Required on the call that charges (when the seller accepts first, the call after they accept); a call that only sends the order doesn't keep it, and after payment it can't be changed. US addresses: 2-letter state code and a 5-digit ZIP code or ZIP+4.
shared_payment_tokenYesThe Stripe Shared Payment Token (spt_...) your user approved for this purchase.
shipping_address_confirmedNotrue only if you read shipping_address back to your user and they said it's right. Required with shipping_address on the call that charges.

Output Schema

NameRequiredDescriptionDefault
nextYesWhat happens next.
paidYestrue = the payment went through.
orderYesThe order this request led to: made with pay_order, or placed by your user in the chat after confirming. Times are given only where they matter for the status.
statusYesWhere the order stands, as check_request reports it: pending (waiting for your user to confirm or decline; nothing has happened yet), declined (your user chose not to go ahead), expired (nobody acted within 7 days; the link no longer works), listing_unavailable (the listing isn't for sale anymore (taken down or sold out), so the request can't go ahead), message_sent (messages only: your user confirmed and the message was sent to the seller), awaiting_order (orders only: your user confirmed and the chat is open, but they haven't placed the order yet), payment_in_progress (orders only: a payment is being processed), payment_failed (orders only: a pay_order payment didn't go through; nothing was charged and the order can still be paid), waiting_for_seller (orders only: the order was sent to the seller, who hasn't accepted yet; nothing has been charged), ready_to_pay (orders only: the order is waiting to be paid (pay_order again, or your user pays on Egonex)), paid (orders only: paid; waiting for the seller to deliver), delivered (orders only: the seller marked it delivered; waiting for your user to confirm receipt), refund_requested (orders only: your user asked for a refund; Egonex is handling it), completed (orders only: the order is complete), refund_pending (orders only: canceled after payment; the refund hasn't gone through yet), refunded (orders only: canceled after payment; your user was refunded), closed_unpaid (orders only: the order closed before anything was charged (close_reason says why)).
request_idYesThe request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description is consistent with a real charge. Beyond the annotations it discloses what gets charged (amount × quantity plus sales tax), what is never charged (sold_out, stock_short, seller_not_taking_orders, shipping_address_required, existing account), and the refund-minus-processing-fee outcome if the seller declines after payment.

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

Conciseness3/5

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

The core action and the token/amount requirement are front-loaded, which is good. However, the body is a very dense block of conditional error and retry prose with repeated phrasing ('nothing is charged' recurs many times) and no paragraph breaks, which makes it harder to scan than necessary.

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 payment tool with nine parameters, nested shipping_address, annotations, and an output schema, this is complete: it maps result statuses (waiting_for_seller, ready_to_pay, paid, payment_failed, payment_error) to next actions, names error codes, and explains the shipping-address lifecycle. Nothing material for a correct call is 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 meaning the schema cannot: the token must cover at least amount × quantity in USD plus tax, shipping_address is required only on the charging call and is locked afterward, and shipping_address_confirmed must reflect a read-back to the user. It does not add much on request_id, quantity or delivery_days beyond the schema.

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?

Opening sentence gives a specific verb and resource ('Pay for an order made with request_order without the confirm page') and names the exact mechanism (a Stripe Shared Payment Token the user approved). It explicitly separates this tool from request_order, check_request and the Egonex confirm page, so an agent knows when this is the charging path.

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?

The description states when to call (only after the user agreed to the purchase and terms), the seller-confirms-first sequencing (call again with the same request_id and buyer_email once check_request shows ready_to_pay), and the alternatives (user pays via confirm_url or the emailed link). It also gives explicit do-not-call guidance: don't retry while check_request shows payment_in_progress.

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

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