listing

beycome_reply_message

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.6/5.0

Behavior5/5

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

No annotations exist, so description carries full burden. It fully discloses that sends are final (live send), queues email notifications, and that the tool automatically corrects the user's draft before sending. Lists all error responses with causes and status codes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but well-structured: starts with purpose, then behavioral caveat, then instruction to improve draft, then parameter hints, then error handling. Every sentence is informative; no fluff. Could be slightly more concise but still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no annotations, and an output schema (not shown but referenced), the description covers all necessary context: input derivation from sibling tool, success response shape, and full error mapping. Complete for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good parameter descriptions. Description adds extra value: clarifies thread usage, advises on subject omission, explains how to derive to_user_id, and specifies access token source. Goes beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool replies to buyer/inquiry messages via POST /messages/reply, distinguishing it from siblings like beycome_messages which list conversations. It specifies the stage (post-publish) and action (sends real message and queues notification).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: use for threaded replies (pass thread verbatim, omit subject), how to find to_user_id via beycome_messages, and always improve the drafted reply. Lacks explicit when-not-to-use, but context from siblings makes it clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All listing tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources

Need Help?