Skip to main content
Glama

Send your own reply

send_reply
Destructive

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; its status then moves from scheduled to sent in the lead's conversation. 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. API reference: https://www.emailchaser.com/docs/api-reference/replies

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "body": "<body>"
    },
    "name": "send_reply"
  }
}

Input Schema

NameRequiredDescriptionDefault
ccNoCc recipients; only read together with to
idYesThe numeric ID of the inbound reply to answer (from list_replies, or an inbound item of get_lead_conversation)
toNoRecipients. Leave out to Reply All
bccNoBcc recipients, with or without to
bodyYesYour message: plain text, or HTML when contentType is "html"
attachmentsNoAt most 5 files, 10 MB in total
contentTypeNo"text" (default) or "html"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses that the message is scheduled immediately, sends within about a minute, cannot be recalled, and moves from scheduled to sent. It also covers Reply All versus explicit recipient behavior, merge tags and spintax, signature absence, attachment limits, authentication requirements, and specific 409/422/429 failure conditions.

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?

The core action is front-loaded, and nearly every sentence adds operational detail relevant to correct invocation. However, the single dense paragraph mixes usage, parameter behavior, and error handling, making it harder to scan than a sectioned description would be.

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 destructive, non-idempotent send operation with no output schema, the description is unusually complete. It covers timing, irreversibility, recipient semantics, formatting, merge tags, attachment constraints, authentication, and the key error responses an agent may encounter.

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 already 100%, but the description adds substantial meaning: omitting 'to' triggers Reply All semantics, specifying 'to' makes to/cc/bcc exact, cc is only read with to, bcc works either way, and there is a 20-address cap. It also explains contentType defaulting and HTML handling, attachments limits, and that no subject is supplied.

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 states a specific verb and resource: it answers an inbound reply with your own message in the same email thread and from the correct mailbox. It also clarifies scope by noting it works for every inbound reply, including ones without an AI draft, which distinguishes it from draft-oriented siblings.

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?

It gives clear usage context: answer an inbound reply, including wrong_person or uncategorized replies, and use it to send a second message in a quiet conversation. It does not explicitly name an alternative tool such as send_reply_draft or state when not to use this tool, so it stops short of full alternative routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources