Emailchaser

Send your own reply

send_reply

Answers an inbound reply with your own message, in the same email thread and from the mailbox the conversation runs through (in a conversation the prospect started, your mailbox they wrote to). It works for every inbound reply, including the ones Emailchaser writes no AI draft for (wrong_person, uncategorized), and it is how you send a second message in a conversation that went quiet: answer the prospect's latest reply again. The message is scheduled at once, goes out within about a minute and cannot be recalled; get_lead_conversation then shows its status move from scheduled to sent. Only id and body are required. Leave to out to Reply All: the person who wrote goes in To and everyone else they addressed in Cc, never one of your own mailboxes. Set to to choose the recipients yourself: then to, cc and bcc are used exactly as given (cc is only read together with to; bcc works either way), at most 20 addresses in all. There is no subject: the answer keeps the thread's subject with "Re: " in front, so the thread never breaks. contentType is "text" by default; use "html" only when body is HTML (paragraphs, line breaks, bold, italics, links, lists and headings are kept; images, tables and inline styles are removed). Merge tags such as {first_name} and spintax such as {Hi|Hello} are filled in when it sends. No signature is added: put yours in body. attachments takes at most 5 files, 10 MB in total. Refused with 409 when the id is not an inbound reply or an identical body went to it less than 60 seconds ago (so a retry after a timeout never sends twice), 422 when there is no connected sender mailbox or recipient, the lead has unsubscribed or an earlier email to the recipient hard-bounced, and 429 after 20 answers to one reply in an hour. Needs a read & write key.

Input Schema

TableJSON Schema

Name	Required	Description
`cc`	No	Cc recipients; only read together with to
`id`	Yes	The numeric ID of the inbound reply to answer (from list_replies, or an inbound item of get_lead_conversation)
`to`	No	Recipients. Leave out to Reply All
`bcc`	No	Bcc recipients, with or without to
`body`	Yes	Your message: plain text, or HTML when contentType is "html"
`attachments`	No	At most 5 files, 10 MB in total
`contentType`	No	"text" (default) or "html"

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond annotations: immediate scheduling, delivery within ~a minute, irreversibility, the scheduled→sent status transition via get_lead_conversation, signature/merge-tag/spintax handling, and specific 409/422/429 failure conditions plus the read & write key requirement. This is a model of behavioral disclosure.

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 core action and scoping, then layers scheduling/error/parameter details, so structure is sound. It is a dense single block, however, and could be broken into discrete points for faster scanning.

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?

With no output schema, the description still tells the agent how to verify the result (status via get_lead_conversation), how retries and duplicate bodies behave, what gets rejected and why, and what auth is needed. Nothing essential for correct invocation is missing.

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?

Although schema coverage is 100%, the description adds semantics the schema cannot express: leaving 'to' out triggers Reply All with the writer in To and others in Cc (never your own mailboxes), setting 'to' uses to/cc/bcc verbatim, cc is only read with to while bcc works either way, and at most 20 addresses total. These are genuine behavioral rules beyond field types.

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 (answer an inbound reply with your own message), and pins the scope: same thread, from the mailbox the conversation runs through. It also clarifies it covers replies no AI draft is written for, which implicitly separates it from the draft-oriented siblings like send_reply_draft.

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?

Gives clear usage context: works for every inbound reply including wrong_person/uncategorized, and is the way to send a second message in a quiet conversation by answering the latest reply again. It does not explicitly state when to prefer it over send_reply_draft, but the surrounding conditions are unusually concrete.

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

All Emailchaser 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?