Skip to main content
Glama
loldwyer

Red MCP Server

by loldwyer

brc_send_email_statement

Sends a customer statement email for a given period and minimum balance, requiring confirmation after review.

Instructions

Sends a customer statement email. Supported document type only. Red email sending is available for sales invoices, quotes, and customer statements — not for cash receipts, purchases, payments, bank accounts, customers, suppliers, products, reports, or other document types. If the user asks to email an unsupported document type, say Red cannot email it through the current MCP tools, list the supported types, and stop without preparing a draft or attempting a workaround. Do not call this tool with confirmSend=true until the user has reviewed a plain-English email draft and explicitly confirmed they want to send it. The email draft must show the recipient email address clearly before asking for send confirmation. If there is no customer email on file and no recipient override, stop and ask for a recipient email address — do not send. Create/post confirmation and email send confirmation are separate steps. If the user provides multiple recipient addresses, ask whether to send one email using BCC or separate individual emails. Only use sendMode='separate' when the user explicitly chooses separate emails. Do not ask about BCC unless the user provides multiple recipients or asks to copy another address.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sendModeNoHow to handle multiple recipients. Use separate only when the user explicitly asks to send separate individual emails.
toPeriodNoStatement period end (ISO date-time, e.g. 2026-05-31T00:00:00).
toAddressNoOptional single recipient override. If omitted or empty, BRC uses the customer's email address.
customerIdYesBRC field: customerId.
fromPeriodNoStatement period start (ISO date-time, e.g. 2026-01-01T00:00:00).
minBalanceNoMinimum balance threshold for transactions included on the statement.
companyNameYesCompany context name, for example YOUR-COMPANY-NAME.
confirmSendNoMust be true only after the user has reviewed the email draft and explicitly confirmed sending.
fromAddressNoOptional sender address override.
messageBodyNoOptional custom email message body.
toAddressesNoOptional list of recipients. If more than one is provided, ask the user whether to send one email with BCC or separate individual emails.
bccAddressesNoOptional BCC email addresses. Only use if the user explicitly provides BCC addresses or chooses one email with BCC.
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the sending action, need for user confirmation, requirement to show recipient email, and handling of multiple recipients. Could be more explicit about side effects or error handling, but covers key behavioral traits.

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 description is thorough but not overly verbose given the complexity. It is front-loaded with the core purpose. Some redundancy in listing unsupported types could be compressed, but overall each sentence serves a purpose.

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

Completeness3/5

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

Given 12 parameters, no output schema, and complex workflow, the description covers the sending process well but lacks detail on what the tool returns (e.g., success/failure, sent confirmation). It also doesn't address error scenarios like invalid email format.

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 meaningful context for sendMode (only use 'separate' when user explicitly chooses) and confirmSend (must be true only after review). It also clarifies the behavior of toAddresses (ask about BCC when multiple).

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 clearly identifies it sends customer statement emails for supported document types only, explicitly listing unsupported types. It distinguishes from sibling tools like brc_send_sales_invoice_email and brc_send_quote_email by focusing on statements.

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?

Provides explicit when-to-use and when-not-to-use guidance, including instructions for unsupported document types (stop and list supported types). Also details workflow steps like requiring user confirmation before sending, handling multiple recipients, and asking for recipient email if missing.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/loldwyer/Red'

If you have feedback or need assistance with the MCP directory API, please join our Discord server