Skip to main content
Glama

Send a reply email

reply_to_thread
Destructive

Send a real email in an inbound reply's existing thread from the mailbox that received it. An unconfirmed request returns a preview, confirmation_token, and approval_url. After a person approves, Layrcake runs it itself when the result's approval block says execution: server (a launch starts at its first-send time); otherwise, repeat the call with that token and a stable idempotency_key. Repeating is always safe and never runs it twice. Calling again without a token while the same request is still waiting for a decision returns that approval and sends no second email; after it was declined, expired or cancelled, calling again without a token asks again with a new confirmation_token. Requires reply:send, which is not granted by default. Refuses while any reply from this sender is pending or unavailable; wait until get_reply shows its interpreted_intent. Only one reply is allowed per inbound message; suppressed contacts are refused, and sender and subject are derived. operation_unknown_state includes an operation_id whose status is available from get_operation. dry_run: true returns an advisory estimate as of evaluated_at, reserves nothing, and may differ from a later execution plan.

Input Schema

NameRequiredDescriptionDefault
dry_runNo
reply_idYes
body_textYes
supersedesNoThe confirmation_token of the approval this request replaces. Needed only when that approval was already approved and hasn't started yet; one still waiting for a decision is replaced automatically. Only where Layrcake runs approved actions itself (the result's approval block says execution: server); anywhere else it is refused. A dry run doesn't check it, so it refuses it: send it on the call itself.
idempotency_keyNoA payment_required refusal means services are stopped for unpaid billing; direct the owner to the billing link in the error. Campaigns stay paused after payment until restarted. Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that.
confirmation_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."New value: +"A payment_required refusal means services are stopped for unpaid billing; direct the owner to the billing link in the error. Campaigns stay paused after payment until restarted. Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."
  2. Changed1 schema field changed
    • changedInput schema / properties / supersedes / description
      Previous value: -"The confirmation_token of the approval this request replaces. Needed only when that approval was already approved and hasn't started yet; one still waiting for a decision is replaced automatically. Only where Layrcake runs approved actions itself (the result's approval block says execution: server); anywhere else it is refused."New value: +"The confirmation_token of the approval this request replaces. Needed only when that approval was already approved and hasn't started yet; one still waiting for a decision is replaced automatically. Only where Layrcake runs approved actions itself (the result's approval block says execution: server); anywhere else it is refused. A dry run doesn't check it, so it refuses it: send it on the call itself."
  3. Changed1 schema field changed
    • addedInput schema / properties / supersedes
      Added value: +{
      +  "description": "The confirmation_token of the approval this request replaces. Needed only when that approval was already approved and hasn't started yet; one still waiting for a decision is replaced automatically. Only where Layrcake runs approved actions itself (the result's approval block says execution: server); anywhere else it is refused.",
      +  "format": "uuid",
      +  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional for search and enrichment tools: supply one to make a retry replay the original result. Required for tools that create an external side effect; reuse the same value after a timeout or an approval."New value: +"Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."
  5. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Stable retry key; the same value identifies retries of the same request after timeout or approval."New value: +"Optional for search and enrichment tools: supply one to make a retry replay the original result. Required for tools that create an external side effect; reuse the same value after a timeout or an approval."
  6. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, openWorldHint=true) it discloses the approval flow and its return (preview, confirmation_token, approval_url), who executes it (server vs. client repeat), that permission reply:send is not granted by default, and the exact refusal conditions. The idempotency claim is explicitly conditioned ("with that token"), so it does not contradict idempotentHint=false for raw repeats.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is a dense run of long, nested sentences ("After a person approves, Layrcake runs it itself when...") and includes tangential detail such as launches starting at their first-send time and operation_unknown_state handling. Most content is non-redundant, but the parsing cost is high for a tool an agent must call correctly.

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?

This is a complex asynchronous, approval-gated, side-effecting tool with no output schema, and the description covers return values, execution ownership, permissions, refusals, retry/idempotency behavior and dry-run semantics. Nothing material an agent needs to invoke it safely is missing.

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?

With only 33% schema description coverage, the description compensates for the important unknowns: dry_run semantics (advisory estimate as of evaluated_at, reserves nothing, may differ), what confirmation_token does across retries, and that idempotency_key must be stable across a retry. reply_id and body_text are self-evident and left to the schema, which is acceptable.

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 opening sentence gives a specific verb, resource and scope: send a real email into an inbound reply's existing thread, from the receiving mailbox. It also implicitly distinguishes the real send from the preview/dry-run path, so an agent can tell it apart from sibling read tools like get_reply or get_replies.

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?

It states when-not as well as when: refuses while any reply from this sender is pending or unavailable, one reply per inbound message, suppressed contacts refused. It names the alternatives for the adjacent needs — repeat with confirmation_token plus idempotency_key after approval, get_reply to wait for interpreted_intent, get_operation to resolve operation_unknown_state.

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