Egonex

Order a listing for your user

request_order

Start an order for one listing on your user's behalf. Returns a confirm_url: your user opens it, checks the listing and price, enters an email address and pays on Egonex (payments are processed by Stripe). Nothing is ordered or charged until they confirm, and no Egonex account is needed. Use note for what the seller needs to know, such as dates, quantity, size, or the area for delivery or pickup. For an item that ships, your user enters the shipping address when they pay on Egonex. Use check_request with the returned id to see whether your user confirmed. A sold-out listing, or one whose seller isn't taking new orders right now, can't be ordered (error listing_unavailable); ask_seller can still ask whether it will be back.

Input Schema

Name	Required	Description
`note`	No	Optional note to the seller, e.g. the date or quantity your user wants.
`deal_id`	No	Optional: deal.id from an ask_seller answer in which Ego agreed a price with you for this listing (use it within 24 hours, once). The order then uses that price.
`offer_id`	Yes	The listing id from search_offers (the 8-character id at the end of a listing page URL also works).
`agent_name`	No	Your name, shown to your user when they confirm.

Output Schema

Name	Required	Description
`id`	Yes	Request id (pass it as request_id).
`deal`	No	The 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.
`kind`	Yes	order (request_order) or message (message_seller).
`next`	No	What to do next (when the request is created).
`order`	No	The 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.
`status`	Yes	Where 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)).
`payment`	No	On a new order request that can be paid directly with a Stripe Shared Payment Token (pay_order).
`offer_id`	Yes	The listing.
`order_id`	No	The order this request led to (same as order.id).
`expires_at`	Yes	When a pending request expires (RFC 3339).
`confirm_url`	Yes	The page your user opens to confirm.
`close_reason`	No	closed_unpaid only: why the order closed (absent for orders closed before 2026-11-01).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no real safety signal beyond destructiveHint=false, the description carries the burden well: nothing is ordered or charged until the user confirms, no Egonex account is required, payment runs through Stripe, shipping address is captured at payment time, and the human-in-the-loop confirm_url flow is spelled out. This is consistent with readOnlyHint=false and idempotentHint=false.

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?

Front-loaded with the action and its key consequence (nothing charged until confirmation), then flows into parameter guidance, follow-up, and the failure case. Dense but nearly every sentence carries operational value; only the Stripe parenthetical feels slightly incidental.

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?

Given an output schema exists, return values would not need explaining, yet the description still flags the critical confirm_url artifact an agent must surface to its user. It also covers the error path and the next tool to call, leaving no operational gap for a mutation tool with a human-confirmation step.

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 genuine meaning for note (dates, quantity, size, delivery/pickup area) beyond the schema's example. It does not elaborate on deal_id or agent_name, leaving those to the schema, so it is short of a 5.

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?

States a specific verb and resource with scope: "Start an order for one listing on your user's behalf." It immediately distinguishes itself from pay_order and check_request by naming them as separate steps (confirming/paying happens on Egonex; status is checked via check_request).

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?

Explicit routing: use note for what the seller must know, use check_request with the returned id to follow up, and use ask_seller when a listing is unavailable. It also names the exclusion condition (sold-out or seller not accepting orders) and its error code listing_unavailable.

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?