listing

Reply to a buyer/inquiry message

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

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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJul 17, 2026

changedInput schema / properties / access_token / description

Previous value: -"Bearer access token from beycome_signin_verify."New value: +"Bearer access token from beycome_signin_verify, or a previously saved token from your memory for this user."

AddedJul 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare readOnly=false, openWorld=true, destructive=false. The description goes well beyond them: it warns this is a live send with a real email notification queued, that sent text is final, and it enumerates concrete failure modes and their 400 messages plus the 401 re-auth path via `beycome_signin_start`/`beycome_signin_verify`.

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?

Front-loaded with the verb/resource and endpoint, then organized into clear blocks (behavior, instructions, parameters, outcomes). It is longer than strictly necessary — the draft-polishing paragraph runs several sentences — but nearly every sentence carries actionable information.

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

Completeness5/5

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

For a mutation tool with an output schema present, the definition covers everything an agent needs: required params, recipient resolution, threading rules, success status (201 with data.id), and the error branches. Nothing material is left for the agent to guess.

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

Parameters5/5

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

Schema coverage is 100%, yet the description still adds real meaning: how to derive `to_user_id` (the counterparty, not the signed-in owner), why `subject` should be omitted on a thread reply (server prepends "Re: <original subject>"), and what a thread id is sourced from. This is meaning beyond literal field definitions.

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?

States a specific verb and resource ("reply to a buyer/inquiry message") plus the stage ("Post-publish stage") and the underlying endpoint (POST /messages/reply). It is clearly distinguished from the read-oriented sibling `beycome_messages`, which it explicitly names as the lookup tool for the recipient id.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance (replying post-publish), the prerequisite lookup path (open the conversation in `beycome_messages` and take the non-owner participant id), and the threaded-vs-new split ("For a threaded reply pass the original thread verbatim and omit subject"). It also sets a behavioral policy: always polish the user's draft, never send it verbatim.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?