Skip to main content
Glama

Egonex

Check an order or message request

check_request
Read-only

Check a request made with request_order or message_seller: the confirm link and, once there is one, the order it led to (order has its title, quantity, amount and deadlines). Returns the confirm_url again. status is one of:

  • pending: Your user hasn't confirmed or declined yet. Nothing has happened: no order, no charge, no message sent. Give your user the confirm_url.

  • declined: Your user chose not to go ahead on the confirm page. Nothing was ordered, charged or sent. Don't make a new request unless your user asks.

  • expired: Nobody acted on the link within 7 days, so it no longer works. Nothing was ordered, charged or sent. Make a new request if your user still wants it.

  • listing_unavailable: This listing isn't for sale anymore (it was taken down, or it sold out), so the request can't go ahead. Nothing was ordered, charged or sent. Search again for something else, or ask the seller with ask_seller whether it will be back.

  • message_sent (messages only): Your user confirmed and the message was sent to the seller as your user. The seller replies in the Egonex chat (a buyer without an Egonex account gets the reply by email); you don't see the reply here.

  • awaiting_order (orders only): Your user confirmed: a chat with the seller is open with the order filled in, but they haven't placed the order yet. They place it and pay on Egonex; once they do, this status follows that order. 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.

  • payment_in_progress (orders only): A payment for this order is being processed: usually a few seconds when you paid with pay_order; a few minutes after pay_order returned payment_error, while Egonex checks with Stripe whether it went through; and up to a few business days for a bank payment your user made on Egonex. Don't call pay_order while it shows this; check back later. After a payment_error, once it no longer shows this: paid means nothing more is needed; payment_failed or ready_to_pay means the payment didn't go through, so ask your user for a new approval and call pay_order again with the new token (not the same one).

  • payment_failed (orders only): The payment you made with pay_order didn't go through, and nothing was charged. If the card was declined or the bank needs your user to verify it, ask your user for a new approval and call pay_order again with the same buyer_email, or give your user the confirm_url to pay on Egonex. After pay_order returned payment_error, this status means Egonex checked with Stripe and the payment didn't go through: ask your user for a new approval and call pay_order again with the new token (not the same one) and the same buyer_email.

  • waiting_for_seller (orders only): The order was sent to the seller, who hasn't accepted it yet (they have until order.accept_by). Nothing has been charged: on Egonex the buyer pays only after the seller accepts. Check back later; if the seller declines or doesn't respond in time, the order closes and nothing is charged.

  • ready_to_pay (orders only): The order is waiting to be paid by order.pay_by (if the seller had to accept it first, they accepted). If you made it with pay_order, call pay_order again with the same request_id and buyer_email and a valid token (ask your user for a new approval if yours has expired, or if pay_order returned payment_error before: then use the new token, not the same one); for an item that ships, this call charges, so it needs shipping_address and shipping_address_confirmed=true (ask your user for the address and read it back to them first). Otherwise your user pays on Egonex, in their chat with the seller, and enters the address there. If nobody pays in time, the order closes and nothing is charged.

  • paid (orders only): Your user paid and the seller now delivers (by order.deliver_by when it is set). If order.accept_by is set, the seller hasn't accepted yet and has until then; if they don't, your user is refunded minus the payment processing fee. 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.

  • delivered (orders only): The seller marked the order delivered. Confirming receipt, or raising a problem or a refund, happens on Egonex before order.auto_confirm_at; after that the order completes on its own and the seller is paid. 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.

  • refund_requested (orders only): Your user asked for a refund and Egonex is handling it: the seller responds first, and if they don't agree, a review decides. Nothing is needed from you; this status changes to refunded or completed when it's decided. 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.

  • completed (orders only): The order is complete and the seller was paid. If part of it was refunded, order.refunded_amount says how much.

  • refund_pending (orders only): The order was canceled after payment and Egonex is returning the money, but the refund hasn't gone through yet (if it failed, Egonex is following it up). Nothing is needed from you; this changes to refunded once the money is back.

  • refunded (orders only): The order was canceled after payment and your user was refunded order.refunded_amount (the payment processing fee isn't returned). A payment that was only held on the card was released instead.

  • closed_unpaid (orders only): The order closed before anything was charged; close_reason says why: seller_declined, seller_acceptance_timed_out (the seller didn't accept in time), seller_canceled_before_payment, buyer_withdrew (your user withdrew it) or payment_deadline_passed (nobody paid in time). Search again, or make a new request if your user still wants it.

Input Schema

NameRequiredDescriptionDefault
request_idYesThe id returned by request_order or message_seller.

Output Schema

NameRequiredDescriptionDefault
idYesRequest id (pass it as request_id).
dealNoThe price Ego agreed with you (only when it agreed one). Pass deal.id as deal_id to request_order within 24 hours; that request then keeps this price for pay_order and for the order your user pays on Egonex.
kindYesorder (request_order) or message (message_seller).
nextNoWhat to do next (when the request is created).
orderNoThe 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 this request and its order stand: 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)).
paymentNoOn a new order request that can be paid directly with a Stripe Shared Payment Token (pay_order).
offer_idYesThe listing.
order_idNoThe order this request led to (same as order.id).
expires_atYesWhen a pending request expires (RFC 3339).
confirm_urlYesThe page your user opens to confirm.
close_reasonNoclosed_unpaid only: why the order closed (absent for orders closed before 2026-11-01).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/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, but the description goes far beyond that: for every status it discloses whether anything was charged, ordered or sent, whether a token must be re-obtained, whether to reuse the same token or a new one, and which sibling tool to call next. That is precisely the behavioral context an agent needs to avoid double-charging or re-requesting.

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 purpose is front-loaded in one sentence, but the status list is extremely long and repeats the identical boilerplate sentence about post-placement handling on Egonex four times across statuses. Much of the per-status detail earns its place, yet the duplication and sheer length reduce scannability for an agent that mainly needs the status meaning and next action.

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?

With an output schema present, return-value structure needn't be explained, and the description instead supplies the semantic meaning of every status plus the next action for each. For a one-parameter read tool with rich annotations, nothing an agent needs in order to call or interpret it is missing.

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

Parameters3/5

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

Schema coverage is 100% and the single parameter's schema description already says 'The id returned by request_order or message_seller.' The prose adds no syntax, format, or provenance detail beyond that, so the baseline 3 for a fully documented schema is appropriate.

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 names the specific verb (check), the resource (a request made with request_order or message_seller), and what is returned (the confirm link and the resulting order with title, quantity, amount and deadlines). An agent can distinguish this from search_offers, pay_order, and ask_seller without opening any schema.

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 exactly when to call it (after request_order or message_seller) and, per status, what to do next and what not to do — e.g. 'Don't call pay_order while it shows this; check back later' and repeated instructions that post-placement order handling happens on Egonex, not through these tools. Exclusions and alternatives are explicit rather than implied.

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