Egonex

Message the seller for your user

message_seller

Send a message to the seller of a listing as your user: a question Ego couldn't answer, a custom request, or whether a sold-out listing will be back. Returns a confirm_url for your user: nothing is sent until they open it and confirm. They need only an email address, no Egonex account. The message then goes to the seller's Egonex chat as your user, and the seller replies there (a buyer without an Egonex account gets the reply by email); you don't see the reply. Use check_request with the returned id to see whether it was sent (message_sent). To get an answer from the seller's assistant (Ego) right away instead, use ask_seller.

Input Schema

Name	Required	Description
`message`	Yes	What the seller gets from your user, up to 1000 characters.
`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.6/5.0

Behavior4/5

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

Beyond the annotations (which only say it is a non-destructive mutation), the description discloses the confirm_url gate, that nothing is delivered until the user opens it, that no Egonex account is needed on either side, where the message lands, how the reply reaches a non-account buyer, and that the agent never sees the reply. That is unusually rich behavioral context; it only stops short of stating rate limits or delivery latency.

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 action and its scope are front-loaded, and most sentences carry distinct information (confirmation gate, account-free path, reply routing, follow-up tool). It is dense but a couple of clauses, such as the parenthetical reply-by-email note, could be tightened without losing meaning.

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 mutation tool with an output schema present, the description covers the confirmation prerequisite, the account requirements, the delivery path, and the follow-up verification step via check_request. An agent has everything needed to call it correctly and to explain the outcome to its user.

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 for `message` by enumerating the acceptable intents (unanswered question, custom request, restock inquiry) and clarifies the 'as your user' framing that gives `agent_name` its purpose.

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 a specific verb and resource ('Send a message to the seller of a listing as your user') and immediately scopes what kind of message. It is clearly distinguishable from ask_seller and check_request, which are named explicitly later.

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 gives the three triggering cases (a question Ego couldn't answer, a custom request, a sold-out listing) and then names both alternatives with their selection conditions: ask_seller for an immediate answer from the seller's assistant, and check_request to confirm sending.

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?