com.beycome/listing
REMOTE · MCP.BEYCOME.COM · SCANNED AUG 3
List on MLS, sell, show, compare and close your real estate property on beycome.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score →
Endpoint Security57
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 14 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability58
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4481 tokens (~320/item across 14 items; 14 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management27
- Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · mcp.beycome.com
claude mcp add --transport http com-beycome-listing https://mcp.beycome.com/mcp
[mcp_servers.com-beycome-listing] url = "https://mcp.beycome.com/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-beycome-listing": {
"type": "remote",
"url": "https://mcp.beycome.com/mcp",
"enabled": true
}
}
} openclaw mcp add com-beycome-listing --url https://mcp.beycome.com/mcp --transport streamable-http
mcp_servers:
com-beycome-listing:
url: "https://mcp.beycome.com/mcp" {
"mcpServers": {
"com-beycome-listing": {
"type": "http",
"url": "https://mcp.beycome.com/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 2 Aug 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.
- 31 Jul 26 +1
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 29 Jul 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.
- 28 Jul 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.
- 27 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 59
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Aug 2026 · Probed https://mcp.beycome.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mcp.beycome.com | CN=WR3,O=Google Trust Services,C=US | 3 Jul 2026 | 1 Oct 2026 | RSA 2048 | SHA256-RSA | 390c2e2c452ab38809c4cb67c7a709d8 |
| SANs: mcp.beycome.com | ||||||
| CN=WR3,O=Google Trust Services,C=US (CA) | CN=GTS Root R1,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | RSA 2048 | SHA256-RSA | 7ff005a91568d63abc22861684aa4b5a |
| CN=GTS Root R1,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 19 Jun 2020 | 28 Jan 2028 | RSA 4096 | SHA256-RSA | 77bd0d6cdb36f91aea210fc4f058d30d |
DNSSEC insecure
Validation of mcp.beycome.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| beycome.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.beycome.com/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.beycome.com/mcp | HTTPS enforced | 302 | https://mcp.beycome.com/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
beycome_check_coverage ~96
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.
| Name | Type | Req | Description |
|---|---|---|---|
| state | string | yes | State short code (e.g. FL) or full name (e.g. Florida). |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_comps ~258
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.
| Name | Type | Req | Description |
|---|---|---|---|
| baths_max | — | — | Maximum baths. |
| baths_min | — | — | Minimum baths. |
| beds_max | — | — | Maximum beds. |
| beds_min | — | — | Minimum beds. |
| living_area_max | — | — | Maximum living area sqft. |
| living_area_min | — | — | Minimum living area sqft. |
| location | string | yes | Location string (city, state, ZIP, etc.). |
| lot_size_max | — | — | Maximum lot size sqft. |
| lot_size_min | — | — | Minimum lot size sqft. |
| pages | — | — | Number of result pages to fetch. |
| price_max | — | — | Maximum price. |
| price_min | — | — | Minimum price. |
| property_type | — | — | Comma-separated types (singlefamily, condo, townhouse, multifamily, manufactured, land, apartment). |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_estimate ~197
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.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | Full property address in the form 'Street, City, ST ZIP' (e.g. '6104 Timberly Rd S, Mobile, AL 36609'). ZIP is required for reliable results. Include any unit inside the address with a spelled-out de… |
| unit | — | — | Optional unit number (for example 101). Prefer embedding the unit in the address string as 'Apt 101' instead of using this field. |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_get_my_listings ~221
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`).
| Name | Type | Req | Description |
|---|---|---|---|
| access_token | string | yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_messages ~376
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`.
| Name | Type | Req | Description |
|---|---|---|---|
| access_token | string | yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
| thread | — | — | Thread id to open one full conversation (the ``thread`` value from a list row). Omit to list the user's recent conversations. |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_offers ~189
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.
| Name | Type | Req | Description |
|---|---|---|---|
| access_token | string | yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
| page | — | — | Page number of the paginated offers list (defaults to page 1). |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_questionnaire_link ~277
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.
| Name | Type | Req | Description |
|---|---|---|---|
| access_token | string | yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
| prop_id | integer | yes | Property id in beycome. |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_rental_estimate ~262
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.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | Full property address in the form 'Street, City, ST ZIP' (e.g. '501 SW 1st St, Miami, FL 33130'). ZIP is required for reliable results. |
| unit | — | — | Optional unit number (for example 304). |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_reply_message ~511
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: <original subject>"). 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`.
| Name | Type | Req | Description |
|---|---|---|---|
| access_token | string | yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
| message | string | yes | The reply text to send (max 5000 chars). |
| subject | — | — | Optional subject (max 255). Omit on a thread reply — the server derives "Re: <original subject>". |
| thread | — | — | Thread id from the original conversation (a `beycome_messages` row's ``thread``). Pass it verbatim to keep the reply stitched to the thread. |
| to_user_id | integer | yes | Recipient's beycome user id — the counterparty in the thread (the ``fromuser``/``touser`` from a `beycome_messages` row that is NOT the signed-in owner). Cannot be the sender's own id. |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_showings ~254
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.
| Name | Type | Req | Description |
|---|---|---|---|
| access_token | string | yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
| from_date | — | — | Start of the calendar range (YYYY-MM-DD). Defaults to today. |
| prop_id | — | — | Optional — filter events to one property id; omit for all listings. |
| to_date | — | — | End of the calendar range (YYYY-MM-DD). Defaults to 90 days from today. |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_signin_start ~309
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.
| Name | Type | Req | Description |
|---|---|---|---|
| string | yes | User email address. |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_signin_verify ~531
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).
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | 6-digit one-time code the user received by email or SMS. |
| string | yes | User email address. |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_signup ~237
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.
| Name | Type | Req | Description |
|---|---|---|---|
| company_name | — | — | Company name. |
| string | yes | User email address. | |
| firstname | string | yes | User first name. |
| is_owner | — | — | 1 if the user is a landlord/owner, 0 otherwise. |
| lastname | — | — | User last name. |
| phone | string | yes | User phone number. |
| sms_unsubscribe | — | — | SMS opt-in flag: 0 = opt-in, 1 = opt-out. |
Structured output declared, but exposes no named fields.
No examples provided.
beycome_submit_property_link ~507
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`.
| Name | Type | Req | Description |
|---|---|---|---|
| access_token | string | yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
| list_address | — | — | Full property address to prefill the page (the address discussed in chat). |
| package | — | — | Page preset index 1-4: 1=Basic $99, 2=Enhanced $399, 3=Concierge $999, 4=Basic+Title $199. NOT a payPremiumOpt reference. |
Structured output declared, but exposes no named fields.
No examples provided.