Skip to main content
Glama

Sats4AI - Bitcoin-Powered AI Tools

send_email

Destructive

Reach anyone with an email address — useful when your task requires formal communication, sending reports, or contacting someone outside chat. No SMTP server, no domain verification needed. Plain text, max 10,000 chars body, 200 chars subject. 200 sats. Pay with Bitcoin Lightning — no API key or signup needed. Requires create_payment with toolName='send_email'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesRecipient email address
bodyYesEmail body text (plain text, max 10,000 characters)
replyToNoOptional reply-to email address
subjectYesEmail subject (max 200 characters)
paymentIdYesValid payment ID (must be paid) No impersonation, scams, threats, harassment, credential theft, unsolicited bulk messages, or contact after an opt-out. Answering a call does not establish consent. We screen requests after payment. Held messages and calls are not sent or placed; payment is retained during review, not refunded immediately. Confirmed violations are not refunded. Unresolved communication holds become eligible for a refund after 24 hours; refund eligibility is processed by scheduled maintenance. Human review costs 1 sat at https://sats4ai.com/appeal. Recent message text and extracts of recording transcripts support recipient-scoped abuse checks for 24 hours. These context records are deleted hourly, so storage can last up to 25 hours. Original uploaded-call transcripts and raw held-request or appeal evidence enter cleanup after 30 days. We also keep a de-identified record of screened communications to measure and improve fraud detection. Identifiers in it — contact addresses, numbers and names that follow a greeting — are replaced with one-way tokens, and it holds no destination number and no account, because the service has none. De-identification is not anonymization: text a sender wrote can still identify someone. Do not submit personal information the service does not need. Providers keep records under their own policies.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / paymentId / description
      Previous value: -"Valid payment ID (must be paid) No impersonation, scams, threats, harassment, credential theft, unsolicited bulk messages, or contact after an opt-out. Answering a call does not establish consent. We screen requests after payment. Held messages and calls are not sent or placed; payment is retained during review, not refunded immediately. Confirmed violations are not refunded. Unresolved communication holds become eligible for a refund after 24 hours; refund eligibility is processed by scheduled maintenance. Human review costs 1 sat at https://sats4ai.com/appeal. Recent message text and extracts of recording transcripts support recipient-scoped abuse checks for 24 hours. These context records are deleted hourly, so storage can last up to 25 hours. Original uploaded-call transcripts and raw held-request or appeal evidence enter cleanup after 30 days. Providers keep records under their own policies."New value: +"Valid payment ID (must be paid) No impersonation, scams, threats, harassment, credential theft, unsolicited bulk messages, or contact after an opt-out. Answering a call does not establish consent. We screen requests after payment. Held messages and calls are not sent or placed; payment is retained during review, not refunded immediately. Confirmed violations are not refunded. Unresolved communication holds become eligible for a refund after 24 hours; refund eligibility is processed by scheduled maintenance. Human review costs 1 sat at https://sats4ai.com/appeal. Recent message text and extracts of recording transcripts support recipient-scoped abuse checks for 24 hours. These context records are deleted hourly, so storage can last up to 25 hours. Original uploaded-call transcripts and raw held-request or appeal evidence enter cleanup after 30 days. We also keep a de-identified record of screened communications to measure and improve fraud detection. Identifiers in it — contact addresses, numbers and names that follow a greeting — are replaced with one-way tokens, and it holds no destination number and no account, because the service has none. De-identification is not anonymization: text a sender wrote can still identify someone. Do not submit personal information the service does not need. Providers keep records under their own policies."
  2. Changed1 schema field changed
    • changedInput schema / properties / paymentId / description
      Previous value: -"Valid payment ID (must be paid)"New value: +"Valid payment ID (must be paid) No impersonation, scams, threats, harassment, credential theft, unsolicited bulk messages, or contact after an opt-out. Answering a call does not establish consent. We screen requests after payment. Held messages and calls are not sent or placed; payment is retained during review, not refunded immediately. Confirmed violations are not refunded. Unresolved communication holds become eligible for a refund after 24 hours; refund eligibility is processed by scheduled maintenance. Human review costs 1 sat at https://sats4ai.com/appeal. Recent message text and extracts of recording transcripts support recipient-scoped abuse checks for 24 hours. These context records are deleted hourly, so storage can last up to 25 hours. Original uploaded-call transcripts and raw held-request or appeal evidence enter cleanup after 30 days. Providers keep records under their own policies."
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

The description adds meaningful operational behavior beyond annotations: no SMTP server, no domain verification, no API key/signup, plain-text-only content, character limits, 200 sats cost, and Lightning payment. Annotations already signal destructive/open-world behavior, and the description enriches that context without contradicting it.

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

Conciseness5/5

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

Every sentence carries operational or usage information: use case, setup requirements, content constraints, cost, payment method, and prerequisite call. The description is dense but not bloated, with no filler or redundant restatement of the tool name.

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 paid external-communication tool, the definition covers recipient, subject, body, payment flow, cost, and setup requirements. The lengthy paymentId schema description supplies the review/hold/refund behavior, so together the tool definition gives an agent everything needed to invoke it correctly.

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 the baseline is 3. The description adds value beyond the schema by stating the cost (200 sats) and the required create_payment workflow with the exact toolName parameter. It also reinforces subject/body limits, though those are already in the schema.

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 description clearly identifies the resource as email ('Reach anyone with an email address') and gives concrete use cases: formal communication, reports, and contacting people outside chat. It doesn't explicitly distinguish from send_sms/send_fax siblings, but the email focus is unmistakable.

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 provides clear context for when to use the tool: formal communication, reports, or external contact. It also explains the prerequisite payment flow via create_payment with toolName='send_email'. It doesn't state exclusions or compare directly with SMS/fax alternatives, so it stops short of a 5.

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.