MCP Agent Mail

reply_message

Respond to an existing message within its thread, defaulting recipients to the original sender and preserving conversation context.

Instructions

Reply to an existing message, preserving or establishing a thread.

Behavior

Inherits original importance and ack_required flags
thread_id is taken from the original message if present; otherwise, the original id is used
Subject is prefixed with subject_prefix if not already present
Defaults to to the original sender if not explicitly provided

Parameters

project_key : str Project identifier. message_id : int The id of the message you are replying to. sender_name : str Your agent name (must be registered in the project). body_md : str Reply body in Markdown. to, cc, bcc : Optional[list[str]] Recipients by agent name. If omitted, to defaults to original sender. subject_prefix : str Prefix to apply (default "Re:"). Case-insensitive idempotent.

Do / Don't

Do:

Keep the subject focused; avoid topic drift within a thread.
Reply to the original sender unless new stakeholders are strictly required.
Preserve importance/ack flags from the original unless there is a clear reason to change.
Use CC for FYI only; BCC sparingly and with intention.

Don't:

Change thread_id when continuing the same discussion.
Escalate to many recipients; prefer targeted replies and start a new thread for new topics.
Attach large binaries in replies unless essential; reference prior attachments where possible.

Returns

dict Message payload including thread_id and reply_to.

Examples

Minimal reply to original sender: If the caller has not already authenticated as sender_name in this MCP session, include sender_token.

{"jsonrpc":"2.0","id":"6","method":"tools/call","params":{"name":"reply_message","arguments":{
  "project_key":"/abs/path/backend","message_id":1234,"sender_name":"BlueLake",
  "body_md":"Questions about the migration plan...","sender_token":"<registration_token>"
}}}

Reply with explicit recipients and CC:

{"jsonrpc":"2.0","id":"6c","method":"tools/call","params":{"name":"reply_message","arguments":{
  "project_key":"/abs/path/backend","message_id":1234,"sender_name":"BlueLake",
  "body_md":"Looping ops.","to":["GreenCastle"],"cc":["RedCat"],"subject_prefix":"RE:",
  "sender_token":"<registration_token>"
}}}

Input Schema

TableJSON Schema

Name	Required	Default
`cc`	No
`to`	No
`bcc`	No
`format`	No
`body_md`	Yes
`message_id`	Yes
`project_key`	Yes
`sender_name`	Yes
`sender_token`	No
`subject_prefix`	No	Re:

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.4Sep 30, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and largely meets it: it discloses inherited importance/ack flags, thread_id derivation, subject prefixing, default recipient, and (via the example) the sender_token requirement. It doesn't state whether the original message is mutated, permission requirements, or rate limits, so a small gap remains.

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 purpose is front-loaded and sectioned clearly (Behavior, Parameters, Do/Don't, Returns, Examples), so it is easy to scan. It is on the long side and the two full JSON-RPC examples are verbose relative to what they convey.

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

Completeness4/5

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

An output schema exists, so the return-value section is surplus, but behavior, auth, and recipient defaults are all covered for a mutation tool with no annotations. The undocumented 'format' parameter is the main completeness gap.

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 0%, so the description must compensate, and it documents 8 of 10 parameters (project_key, message_id, sender_name, body_md, to/cc/bcc, subject_prefix) with useful semantics like the case-insensitive idempotent prefix. The 'format' parameter is never explained and sender_token is only shown in examples, leaving two gaps.

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

Purpose4/5

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

The opening sentence gives a specific verb and resource (reply to an existing message) and adds scope ('preserving or establishing a thread') that separates it from a plain send. It never names the sibling send_message, so the distinction from that tool is left implicit rather than explicit.

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?

The Do/Don't block is genuine routing guidance: reply to the original sender, prefer a new thread for new topics, don't change thread_id, don't escalate recipients. It tells the agent both when to reply and when to choose an alternative (start a new thread), which is exactly what a usage section should do.

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