listing
Server Details
List on MLS, sell, show, compare and close your real estate property on beycome.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 13 of 14 tools scored. Lowest: 4/5.
Each tool targets a distinct stage or action in the listing workflow: discovery, account, creation, questionnaire, and post-publish. There is no functional overlap—even pricing-adjacent tools like comps and estimate are clearly differentiated by their outputs.
All tools share the 'beycome_' prefix and lowercase underscores, but some are verbs (submit_property_link) while others are nouns (comps, offers). This minor inconsistency does not impair readability or agent selection.
14 tools cover the full lifecycle of a real estate listing without feeling bloated or sparse. Each tool has a clear role, making the set well-scoped for the domain.
Core CRUD and lifecycle operations are present, including discovery, sign-up, listing creation, and post-publish communication. Missing are tools for updating or deleting a live listing, but the main workflow is supported.
Available Tools
14 toolsbeycome_check_coverageAInspect
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 | Required | Description | Default |
|---|---|---|---|
| state | Yes | State short code (e.g. FL) or full name (e.g. Florida). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses it's a GET request, requires no account or prop_id, and describes the response indicator. Does not mention read-only nature explicitly or potential errors, but these are implied by the simple nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two short paragraphs, front-loaded with purpose, endpoint, and usage context. Every sentence serves a purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple coverage check with one parameter and an output schema available, the description adequately covers the discovery stage, the check's meaning, and the next steps. It is complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context beyond the schema by noting that no account or prop_id is needed, and that the state parameter can be short code or full name. This adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a 'discovery stage' tool to check if a state is served by beycome MLS. It mentions the HTTP endpoint and the meaning of the response ('is_active: true'). It distinguishes from siblings by indicating it's a pre-listing check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before listing to confirm beycome operates in the property's state' and explains the implication: if not covered, listing flow does not apply. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_compsAInspect
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 | Required | Description | Default |
|---|---|---|---|
| pages | No | Number of result pages to fetch. | |
| beds_max | No | Maximum beds. | |
| beds_min | No | Minimum beds. | |
| location | Yes | Location string (city, state, ZIP, etc.). | |
| baths_max | No | Maximum baths. | |
| baths_min | No | Minimum baths. | |
| price_max | No | Maximum price. | |
| price_min | No | Minimum price. | |
| lot_size_max | No | Maximum lot size sqft. | |
| lot_size_min | No | Minimum lot size sqft. | |
| property_type | No | Comma-separated types (singlefamily, condo, townhouse, multifamily, manufactured, land, apartment). | |
| living_area_max | No | Maximum living area sqft. | |
| living_area_min | No | Minimum living area sqft. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It correctly indicates a safe read operation (GET, no account needed) and lists supported filters. However, it omits behavioral details such as pagination behavior (despite the `pages` parameter), result limits, data freshness, or any rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a bullet-style list of filters. It front-loads the core purpose and follows with essential context. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and high schema coverage, the description adequately covers the tool's role (discovery, pricing support) and filter capabilities. It could be slightly more complete by addressing pagination or result size, but it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description groups parameters into categories (price, beds, etc.) but does not add significant meaning beyond the parameter-level descriptions already present in the schema. The `pages` parameter is mentioned in the description but without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving sold comparable listings near a location during the discovery stage. It identifies the HTTP method (GET /comps) and distinguishes itself from the sibling `beycome_estimate` by noting it is used alongside for pricing support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use during discovery to support pricing, and explicitly states that no account or prop_id is needed. It implicitly differentiates from `beycome_estimate` but does not enumerate alternative tools or explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_estimateAInspect
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 | Required | Description | Default |
|---|---|---|---|
| unit | No | Optional unit number (for example 101). Prefer embedding the unit in the address string as 'Apt 101' instead of using this field. | |
| address | 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 designator, e.g. 'Apt 107' or 'Unit 107' — never '#107'. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that no account or prop_id needed, and mentions both estimates plus pricing strategies. Could add more about external API dependencies or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the main purpose and add necessary context without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has simple parameters, output schema present, and description covers usage, return values, and alternatives, making it complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema documents both parameters adequately. Description does not add significant meaning beyond what is already in the schema for address and unit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it estimates property value using beycome CMA and Zillow Zestimate, clearly indicating the tool's function and distinguishes from siblings by specifying discovery stage usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (discovery to set list price), suggests pairing with `beycome_comps`, and directs to `beycome_sell_timing` for alternate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_get_my_listingsAInspect
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 asprop_idforbeycome_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 | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. States it is token-scoped and a GET endpoint. Does not mention pagination, error handling, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose ('Recovery stage') and structured with bullet points. Each sentence adds value, though could be slightly trimmed. Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values need not be described. Covers integration with sibling tools and two main workflows. Lacks mention of pagination or error states, but acceptable given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter is access_token. Schema coverage 100%, but description adds context: token comes from beycome_signin_verify or saved memory. This clarifies the source beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'the signed-in user's properties' and provides specific use cases (after submit, returning user). It distinguishes from siblings by linking to subsequent steps like questionnaire and post-publish tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: after submitting a property or for returning users. Provides decision flow based on listing status. Lacks explicit 'do not use' conditions but guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_messagesAInspect
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, andmessage_type(senderif the owner wrote the latest message, elsereceiver).Pass
thread→ returns that one conversation in full, oldest-first. Use thethreadvalue 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 | Required | Description | Default |
|---|---|---|---|
| thread | No | Thread id to open one full conversation (the ``thread`` value from a list row). Omit to list the user's recent conversations. | |
| access_token | Yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully covers behavior: read-only, non-paginated (with reason), soft-delete messages, 401 meaning, and payload structure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded with main purpose. Every sentence adds value, though slightly verbose given the detail. Could be trimmed slightly, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be fully described, but description still covers key fields and payload structure. Includes authentication, error handling, and usage context with sibling tools. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds significant context: explains 'thread' param usage (omit for list, pass for conversation) and 'access_token' origin. Lists useful fields in list mode, going well beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool reads owner's buyer/inquiry messages via GET /messages. Distinguishes from sibling tools like beycome_reply_message for answering messages. Specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes two usage modes (list vs thread), when to use each, and when not to use pagination. Provides authentication context and links to signin tools. Directs to use reply_message for answering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_offersAInspect
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 | Required | Description | Default |
|---|---|---|---|
| page | No | Page number of the paginated offers list (defaults to page 1). | |
| access_token | Yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, pagination behavior, client-side filtering requirement, and explicitly states what is not exposed (responding to offers). No annotations exist, so description fully carries behavioral transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: first sentence states purpose and endpoint, followed by context and details. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (read, paginated list) and presence of output schema, the description covers all essential aspects: when to use, pagination, authentication, filtering limitations, and exclusions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters (100% coverage). Description adds value by explaining token source (from beycome_signin_verify) and pagination defaults, going beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves offers on listings after publishing, identifies the endpoint (GET /offers), and distinguishes it from siblings by noting it's read-only and post-publish stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context (post-publish stage), required authentication (access_token), pagination details (20 per page, page parameter), and clarifies limitations (no server-side prop_id filter, no offer response).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_questionnaire_linkAInspect
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:
review the pre-filled MLS questionnaire and complete any fields Beycome couldn't pre-fill,
upload property photos and the required documents,
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 | Required | Description | Default |
|---|---|---|---|
| prop_id | Yes | Property id in beycome. | |
| access_token | Yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns a pre-authorized link (expires in 7 days), only hands back the URL, and describes the browser flow. Failure modes are listed with explanations, providing good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the purpose and then explaining requirements and failure modes. While slightly lengthy, each sentence adds value, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no nested objects), the description covers behavior, prerequisites, failure modes, and outcome. It does not detail the exact output format, but the behavioral information is sufficient for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in schema). The description does not add additional semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'mint', the resource 'pre-authorized link to the MLS questionnaire form', and distinguishes it from siblings by noting it requires a paid listing and relates to the questionnaire. It also differentiates from beycome_submit_property_link by mentioning the paid listing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite (PAID listing) and provides failure modes with status codes (403, 422, 401) that help the agent decide when to use the tool. However, it does not explicitly mention alternatives beyond the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_rental_estimateInspect
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 | Required | Description | Default |
|---|---|---|---|
| unit | No | Optional unit number (for example 304). | |
| address | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
beycome_reply_messageAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| thread | No | Thread id from the original conversation (a `beycome_messages` row's ``thread``). Pass it verbatim to keep the reply stitched to the thread. | |
| message | Yes | The reply text to send (max 5000 chars). | |
| subject | No | Optional subject (max 255). Omit on a thread reply — the server derives "Re: <original subject>". | |
| to_user_id | 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. | |
| access_token | Yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses that the message is a live send (not a draft), queues a real email notification, and that the text sent is final. It also describes success and failure responses with specific HTTP status codes and messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured with clear sections (purpose, behavior, usage, parameters, errors). Every sentence adds value, though it could be slightly more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description does not need to detail return values. It covers parameters, behavior, error codes, prerequisites, and usage flow, making it fully complete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have descriptions in the schema (100% coverage). The description adds value by explaining the meaning of to_user_id (counterparty, not sender), that thread should be passed verbatim, and that subject is omitted for thread replies. It also provides guidance on obtaining to_user_id from beycome_messages.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for replying to buyer/inquiry messages, with a specific verb ('reply') and resource ('message'), and references the API endpoint (POST /messages/reply). It distinguishes from siblings like beycome_messages (conversation listing) by focusing on the reply action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (post-publish stage), how to find to_user_id via beycome_messages, when to pass thread vs omit subject, and error handling details. Also includes a behavioral rule to always improve the drafted reply before sending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_showingsAInspect
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 | Required | Description | Default |
|---|---|---|---|
| prop_id | No | Optional — filter events to one property id; omit for all listings. | |
| to_date | No | End of the calendar range (YYYY-MM-DD). Defaults to 90 days from today. | |
| from_date | No | Start of the calendar range (YYYY-MM-DD). Defaults to today. | |
| access_token | Yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It reveals that the API always returns all event kinds mixed together and that no server-side type filter exists, requiring client-side filtering. It also explains default date ranges and parameter formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with key information front-loaded. Every sentence adds necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers usage context, parameter behavior, default values, and important behavioral notes. It is complete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining default behavior for from_date/to_date, the YYYY-MM-DD format, and that prop_id can be omitted. It also clarifies the access_token source, enhancing the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a calendar of showings, open houses, and offer deadlines for listings in the post-publish stage. It specifies the HTTP method and endpoint, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes this tool is used once a listing is live, and explains default behavior for date range and property filtering. It does not explicitly state when not to use it or compare to alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_signin_startAInspect
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: falsewith "Email not found." (HTTP 200,ok: true) — no account for this email; runbeycome_signupinstead (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 | Required | Description | Default |
|---|---|---|---|
| Yes | User email address. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully details behavior: response handling (check data.success), different cases (success, email not found, secondary address), code validity (30 min), rate limits (5/min, 100/day), and that re-running sends new code invalidating old one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but slightly verbose. Every sentence adds value, though some redundancy exists (e.g., 'beycome is passwordless'). Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers all necessary context: errors, rate limits, code validity, response handling, and alternative tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter email is described in schema as 'User email address.' The description doesn't add extra constraints or format but uses it in context. Schema coverage 100% gives baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a one-time sign-in code for account stage. It references the endpoint and distinguishes from siblings like signin_verify and signup by explaining when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to never ask for password, to use signin_verify after getting code, and signup if email not found. Also mentions rate limits and warns against looping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_signin_verifyAInspect
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_linkto create one.Has a listing already (or unsure) →
beycome_get_my_listingsto find it; if it is paid but the MLS questionnaire is not submitted, follow withbeycome_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 | Required | Description | Default |
|---|---|---|---|
| code | Yes | 6-digit one-time code the user received by email or SMS. | |
| Yes | User email address. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the token location, lifetime, persistence requirements, error behavior (HTTP 200 with success: false for invalid codes), and expiration details. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose. While it is lengthy, every sentence adds value. Minor redundancy could be trimmed, but overall it is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects: authentication flow, token management, error handling, next steps, and persistence. Given the tool's role as a gateway, it provides comprehensive guidance even without an output schema in view.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds context beyond the schema, such as using email for disambiguation and token matching, which aids in correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'exchange the one-time code for the access_token (POST /auth/validate-code)', which is a specific verb+resource. It clearly distinguishes from sibling tools like `beycome_signin_start` and `beycome_signup`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call (after `beycome_signin_start` or `beycome_signup`), what to do with the result (persist token, reuse), and provides next steps based on user state. It also mentions when not to retry (expired code, rate limits) and suggests alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_signupAInspect
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 | Required | Description | Default |
|---|---|---|---|
| Yes | User email address. | ||
| phone | Yes | User phone number. | |
| is_owner | No | 1 if the user is a landlord/owner, 0 otherwise. | |
| lastname | No | User last name. | |
| firstname | Yes | User first name. | |
| company_name | No | Company name. | |
| sms_unsubscribe | No | SMS opt-in flag: 0 = opt-in, 1 = opt-out. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: passwordless registration, automatic email with 6-digit code, dual signup/signin functionality, required parameters (firstname and phone), and validation error format. With no annotations provided, this covers most behavioral aspects, though it omits details on rate limits or account creation side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5 sentences, front-loaded with the core purpose and key guidance. Every sentence adds value, with no unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately covers usage context, behavior, and error handling. It could mention the creation of a user record, but overall it is nearly complete for a registration tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds minimal value, only reiterating that firstname and phone are required. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers a new beycome user via POST /auth/register. It distinguishes from siblings by explicitly stating 'do NOT call beycome_signin_start' and that the next step is beycome_signin_verify, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the owner has no account yet' and provides clear guidance on not calling beycome_signin_start after signup, while directing to beycome_signin_verify. It also explains the edge case where signup doubles as signin-start for existing emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_submit_property_linkAInspect
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:
fill out their property's information,
set a price,
choose a package and any add-ons,
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 | Required | Description | Default |
|---|---|---|---|
| package | No | Page preset index 1-4: 1=Basic $99, 2=Enhanced $399, 3=Concierge $999, 4=Basic+Title $199. NOT a payPremiumOpt reference. | |
| access_token | Yes | Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user. | |
| list_address | No | Full property address to prefill the page (the address discussed in chat). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: link expires in 7 days, user-scoped, no prop_id exists yet, URL-only output, and that the page handles creation/payment. Clearly states the tool does not create the listing directly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear sections, but slightly lengthy. Every sentence adds value; however, could be tightened slightly without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completes the workflow by instructing what to do after the user returns from the page (call beycome_get_my_listings). Covers all parameters, failure modes, and prefill behavior. Fits well within the sibling tool ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% (baseline 3), the description adds significant context: explains package index vs. payPremiumOpt, warns against misuse, mandates passing list_address, and clarifies access_token origin (from beycome_signin_verify or saved memory).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'mint a pre-authorized link to the submit-property page' for listing creation. It clearly distinguishes from sibling tools by outlining the specific stage and output (URL, not listing creation itself).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to call ('AFTER signing in'), mentions prerequisites, failure modes (401), and post-usage steps (call beycome_get_my_listings). Also advises when to omit the optional 'package' parameter ('Only pass if the user has clearly chosen a tier in chat').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!