freedom-mcp

Send email

send_email

Destructive

Send an outbound email via the company's Resend connection. Resolves the per-company Resend API key + from identity, then sends to a single recipient. Honors the do_not_contact suppression list (crm_leads): if the recipient is marked do_not_contact, the send is refused. RECIPIENT RULE: when emailing a CRM LEAD, do NOT type their address yourself — draft with draft_outreach and deliver with send_lead_draft, which reads the lead's real email from the database. Only pass to directly for a non-lead recipient whose exact address the operator literally provided in this conversation. NEVER guess, infer, or fabricate an email address — a wrong guess sends a real email to a stranger. Use when the operator gives you an exact non-lead recipient address to email; for CRM leads use send_lead_draft instead.

Routing: Send an outbound email to an operator-given address → use this; for CRM leads use send_lead_draft (DB-derived recipient, respects do_not_contact)

[outbound-tier — EVERY call needs a manager's approval (per-send human rail): each request queues its own approval card and sends exactly once on approve. There is no standing grant for this tool. Call it on the first clear ask; the card is the yes — do not re-ask in chat.]

Input Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Recipient email address (single recipient).
`from`	No	Optional explicit from address (e.g. "Jane <jane@acme.com>"). If omitted, defaults to no-reply@<resolved from_domain>.
`html`	No	HTML body of the email. Provide html and/or text (at least one is required).
`text`	No	Plain-text body of the email. Provide text and/or html (at least one is required).
`lead_id`	No	Optional UUID of the crm_leads row this email targets. Used for telemetry/linking; the do_not_contact check is keyed on (company_id, to) regardless.
`subject`	Yes	Email subject line.
`draft_id`	No	Optional UUID of the lead_drafts row being sent. If provided, the Resend email id returned by the send is recorded onto that draft (resend_email_id) so engagement webhook events (opens/clicks/replies via /resend-events) correlate back to it.
`reply_to`	No	Optional Reply-To address.
`companyId`	Yes	FreedomOS company id to act within (you must be a member). Required for company-scoped tools.
`company_id`	No	Company UUID. Optional — defaults to the caller's company context. Used to resolve the Resend key and scope the do_not_contact check.
`references`	No	Optional RFC References header. Honored ONLY on executionSource=inbound_info. Ignored otherwise.
`in_reply_to`	No	Optional RFC In-Reply-To header. Honored ONLY on executionSource=inbound_info (company-mail threaded reply). Ignored on every other path so callers cannot inject headers.
`sequence_id`	No	Optional UUID of the outreach_sequences row backing an autonomous warm send. Required ONLY on the outreach-autosend path (executionSource=autonomous_warm); the warm-send gate verifies the sequence is ACTIVE and the lead is enrolled, and authorizes when the sequence is live (send_mode=auto) OR the enrollment is verifiably human-made (enrollment_source=manual — the human-enrolled lane, 2026-07-22). Ignored on the human path.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 23, 2026

addedInput schema / properties / in_reply_to

Added value: +{
+  "description": "Optional RFC In-Reply-To header. Honored ONLY on executionSource=inbound_info (company-mail threaded reply). Ignored on every other path so callers cannot inject headers.",
+  "type": "string"
+}

addedInput schema / properties / references

Added value: +{
+  "description": "Optional RFC References header. Honored ONLY on executionSource=inbound_info. Ignored otherwise.",
+  "type": "string"
+}

Changed1 schema field changedJul 22, 2026

changedInput schema / properties / sequence_id / description

Previous value: -"Optional UUID of the outreach_sequences row backing an autonomous warm send. Required ONLY on the outreach-autosend path (executionSource=autonomous_warm); the warm-send gate verifies this sequence is live (send_mode=auto) and the lead is enrolled. Ignored on the human path."New value: +"Optional UUID of the outreach_sequences row backing an autonomous warm send. Required ONLY on the outreach-autosend path (executionSource=autonomous_warm); the warm-send gate verifies the sequence is ACTIVE and the lead is enrolled, and authorizes when the sequence is live (send_mode=auto) OR the enrollment is verifiably human-made (enrollment_source=manual — the human-enrolled lane, 2026-07-22). Ignored on the human path."

First observedJul 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (destructive, non-idempotent, non-read-only), the description discloses the per-company key resolution, single-recipient enforcement, do_not_contact suppression refusal, per-send approval requirement, and exactly-once send behavior. No contradiction with annotations.

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?

All major content is front-loaded, but the description is long and repeats the lead-vs-direct routing instruction in both the 'RECIPIENT RULE' and 'Routing' paragraphs. The extra length is mostly high-value, but the duplication prevents a higher score.

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?

For a complex 13-parameter, no-output-schema, destructive tool, the description covers when to use, recipient restrictions, suppression, and the human-approval rail. It omits an explicit statement of the return value, but the critical safety and routing context is present.

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 100%, so baseline is 3; the description adds decisive extra meaning for the `to` parameter by prohibiting lead addresses and fabricated/inferred addresses. It does not materially clarify the other parameters, but the schema already describes them well.

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 ('Send'), resource ('outbound email via the company's Resend connection'), and constraints (single recipient, do_not_contact refusal). It also distinguishes itself from send_lead_draft, so an agent can tell sibling tools apart without opening the schema.

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?

Explicitly tells the agent when to call this tool (operator-provided exact non-lead address) and when not to (CRM leads), names the alternatives (draft_outreach, send_lead_draft), and warns never to guess addresses. It also describes the approval workflow for this outbound tier.

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

All freedom-mcp 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?