listing

Discovery stage — is this state served by beycome MLS? (GET /mls/is-covered).

No account or prop_id needed. Use before listing to confirm beycome operates in the property's state; is_active: true means covered. If not covered, the listing flow does not apply.

Discovery stage — sold comparable listings near a location (GET /comps).

No account or prop_id needed. Supports price / beds / baths / area / lot / type filters. Use during discovery to support pricing alongside beycome_estimate.

Slow endpoint: a cold query can take up to ~1 minute to respond — this is normal, you can always retry the call if it times out. Photo URL and listing-link fields are stripped from the records to keep the response small.

Discovery stage — estimate a property's SALE value (beycome CMA + Zillow Zestimate).

No account or prop_id needed. Returns both estimates plus suggested pricing strategies (fast / balanced / max). Use during discovery to set a list price; pair with beycome_comps. For rental inquiries, use beycome_rental_estimate instead.

Recovery stage — the signed-in user's properties (GET /properties).

Token-scoped RESO list endpoint on the normal api base. Two main uses:

• After the user finishes the submit-property page (beycome_submit_property_link): find the newly created listing (typically the newest entry), CONFIRM the address with the user, then use its id as prop_id for beycome_questionnaire_link.

• As the entry point for a returning user who already has listings (or references "my listing" without an id): locate the listing and read its status to pick the next step — paid but questionnaire pending → beycome_questionnaire_link; already live → the post-publish tools (beycome_messages, beycome_showings, beycome_offers).

Post-publish stage — read the owner's buyer/inquiry messages (GET /messages).

Read-only. Requires access_token. Two modes:

• Omit thread → lists the ~20 most recent conversations, newest first, one row per thread (the latest message in each). Useful fields per row: address, prop_id, prop_status, msg (latest text), subject, requested_by / email (the other party), thread, read_msg ("0" = unread), attachments, and message_type (sender if the owner wrote the latest message, else receiver).

• Pass thread → returns that one conversation in full, oldest-first. Use the thread value from a list row to drill in.

The list is not paginated here on purpose (the upstream page param is overloaded — it sets both page size and page number — so it is not exposed). Soft-deleted messages are dropped after paging, so a page may hold fewer than 20 rows; that is not an error. The payload is a bare array under data.

A 401 means the token is no longer valid (logged out, or very old) — re-authenticate with beycome_signin_start then beycome_signin_verify. To answer a message, use beycome_reply_message.

Post-publish stage — offers received on the owner's listings (GET /offers).

Used once a listing is live. Requires access_token. Returns a paginated list (20 per page; pass page to advance) of every offer across all of the signed-in user's listings — each entry is the full offer record (buyer, price, contingencies, dates, status). Read-only.

There is no server-side prop_id filter; to show offers for one listing, filter client-side on each offer's prop_id. Responding to an offer (accept / reject / counter) is not exposed here.

Questionnaire stage — mint a pre-authorized link to the MLS questionnaire form (POST /api/mls/questionnaire-link).

Requires a PAID listing (premium active, Flat/Yes) — whether the user just paid on the submit-property page (beycome_submit_property_link) or already had a paid listing with the questionnaire still pending. Returns a pre-authorized link (expires in 7 days) — this tool only hands back the URL; everything else happens in the browser, with no login step. Present the URL and tell the user that on the page they will:

1. review the pre-filled MLS questionnaire and complete any fields Beycome couldn't pre-fill,

2. upload property photos and the required documents,

3. review and submit. After they submit, the listing goes live within about 48 hours, provided all the paperwork clears.

Failure modes to relay plainly: 403 — the token is not the owner's; 422 — the listing is not paid yet, or the questionnaire was already submitted; 401 — bad/missing token.

Discovery stage — estimate a property's monthly RENT (POST /gemini-estimate).

No account or prop_id needed. Pairs with beycome_estimate, but this tool is SPECIFICALLY for rental estimates: use it ONLY for rental inquiries or for properties that have a unit number. For sale-price estimates, use beycome_estimate.

Returns rentEstimate (e.g. "$2,600"), rentEstimateRange (e.g. "$2,400 - $2,800"), and the sources the figure was grounded on (source URLs are stripped to keep the response small).

Caveat: an unrecognized address still returns success: true with a generic market-average rent — check that the source titles actually reference the property's address/city before trusting the number; if they don't, treat the result as unavailable and ask the user to verify the address.

Post-publish stage — reply to a buyer/inquiry message (POST /messages/reply).

Sends a real message and queues a real email notification to the recipient, so the text you send is final — treat this as a live send, not a draft.

ALWAYS improve the user's drafted reply before sending: fix grammar, spelling, punctuation, capitalization, and formatting, and tighten wording for a clear, professional tone — while preserving their meaning and intent. Send the corrected version, never the raw draft. When the user says "reply saying X", treat X as a rough draft to polish, not literal text to send verbatim.

Requires to_user_id (the counterparty), message, and access_token. For a threaded reply pass the original thread verbatim and omit subject (the server prefixes "Re: "). To find to_user_id, open the conversation with beycome_messages and take the participant id that is not the signed-in owner.

Success is 201 with data.id set to the new message id. Failures come back as 400 with a plain message: "User not found." (bad to_user_id), "You cannot send a message to yourself." (to_user_id is the sender), or "Invalid parameters" (e.g. empty/over-long message). A 401 means the token is no longer valid — re-authenticate with beycome_signin_start then beycome_signin_verify.

Post-publish stage — calendar of showings, open houses, and offer deadlines (GET /calendar/events).

Used once a listing is live. The API requires the date range, so it defaults to today → +90 days when omitted (from_date / to_date are YYYY-MM-DD, with to_date on or after from_date). prop_id filters to one listing; omit it for every listing the user owns.

The response always mixes ALL event kinds — each event carries a type field (showing / open_house / offer). There is no server-side type filter; when the user asks for one kind, filter on that field yourself.

Account stage — send a one-time sign-in code (POST /auth/check-email).

beycome is passwordless — never ask the user for a password. This emails the user a 6-digit code (a second, different code also goes out by SMS; either one works). Ask the user for the code they received, then exchange it for the access_token with beycome_signin_verify.

Read the response body, not the HTTP status — the envelope's ok mirrors the HTTP status, and auth failures here still return 2xx. Always check data.success:

• success: true (201, "Email sent") — code sent; ask the user for it.

• success: false with "Email not found." (HTTP 200, ok: true) — no account for this email; run beycome_signup instead (signup also sends a code).

• HTTP 422 (ok: false) — the email matched a secondary address; the body still matters: it hints the masked primary login email to use instead.

Codes stay valid for 30 minutes. Re-running this tool sends a fresh code and invalidates the old one. Rate-limited (5/min and 100/day per email) — never call it in a loop or as an automatic retry.

Account stage — exchange the one-time code for the access_token (POST /auth/validate-code).

The gateway to the listing flow. Call after beycome_signin_start or beycome_signup (both send the code) with the 6-digit code the user received. On success the Bearer token is at data.data.access_token (expires_in gives its lifetime in seconds — tokens are long-lived, so mid-session expiry is rare). Pass it as access_token to every authenticated tool: beycome_submit_property_link, beycome_get_my_listings, beycome_questionnaire_link, beycome_offers, beycome_showings, beycome_messages, and beycome_reply_message.

IMPORTANT — persist the token: save the access_token to your long-term memory/context (and tell the user you have done so). Save it together with the account email, which disambiguates multi-account users and lets you match the right token to the right person. In future sessions, scheduled tasks, and crons, reuse the saved token instead of asking the user to sign in again — that is what makes autonomous workflows (e.g. "check my messages every morning") possible. Before signing a user in, check your memory for an existing token for that email and try it first; only restart the sign-in flow on a 401.

The next step depends on where the user is:

• No listing yet → beycome_submit_property_link to create one.

• Has a listing already (or unsure) → beycome_get_my_listings to find it; if it is paid but the MLS questionnaire is not submitted, follow with beycome_questionnaire_link.

• Listing already live → skip straight to the post-publish tools (beycome_messages, beycome_showings, beycome_offers).

A wrong or expired code returns HTTP 200 with success: false and "Invalid code." — check data.success, not the envelope's ok. Codes expire after 30 minutes; if expired, request a fresh one with beycome_signin_start (don't retry blindly — sends are rate-limited).

Account stage — register a new beycome user (POST /auth/register).

Use when the owner has no account yet. beycome is passwordless: registering automatically emails the user a 6-digit sign-in code, so the next step is beycome_signin_verify with that code — do NOT call beycome_signin_start after signup, the code is already on its way. If the email is already registered, this still just sends a sign-in code (signup doubles as signin-start). Requires firstname and phone; validation errors come back as HTTP 400 with an errors array. No prop_id needed.

Listing-creation stage — mint a pre-authorized link to the submit-property page (POST /api/mls/submit-property-link).

Call AFTER signing in (beycome_signin_verify). User-scoped — no prop_id exists yet. Returns a pre-authorized link (expires in 7 days) — this tool only hands back the URL; the listing is created in the browser, with no login step. Present the URL and tell the user that on the page they will:

1. fill out their property's information,

2. set a price,

3. choose a package and any add-ons,

4. pay. Tell them to return to the chat once payment is complete.

Prefill: the page accepts prefill params baked into the signed URL.

• list_address: the full property address. By this stage the user has already told Claude their address (discovery ran on it), so ALWAYS pass list_address so the page opens pre-filled.

• package: the page PRESET INDEX (1-4), not a payment reference — 1 = Basic $99 2 = Enhanced $399 3 = Concierge $999 4 = Basic + Title $199 WARNING: this is the page preset index, NOT an internal payPremiumOpt reference number. Passing a payPremiumOpt reference here is wrong. Only pass package if the user has clearly chosen a tier in chat; otherwise omit it and let them pick on the page.

Failure modes to relay plainly: 401 — bad/unverified token.

This page is THE way to create a listing — the property is created, priced, and paid for there; there is no in-chat alternative. After the user returns, call beycome_get_my_listings to recover the new prop_id, then beycome_questionnaire_link.