GoodSender

by io.github.good-sender

Overview Discussions Admin

Send Consentless Email

send_consentless_email

Destructive

Send a consentless template-based email.

The email is sent immediately, without waiting for recipient's consent.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "To": {
        "Address": "user@example.com"
      },
      "From": {
        "Name": "Acme Security",
        "Address": "security@acme.com"
      },
      "Subject": "Your login code",
      "Template": {
        "otp_code": {
          "purpose": "login",
          "app_name": "Acme",
          "otp_code": "482913",
          "expiry_minutes": "10",
          "anti_phishing_notice": "Acme will never ask you for this code"
        }
      }
    },
    "name": "send_consentless_email"
  }
}

Input Schema

Name	Required	Description
`To`	Yes	Recipient address.
`From`	No	Sender address: an existing sender identity on a verified domain. When omitted or invalid, nothing is sent and the result names how to fix it, with up to three valid sender identities.
`Subject`	Yes	Subject of the email.
`Template`	Yes	Consentless template: exactly one key (mfa_enrollment, new_device_login, order_completed, order_receipt, otp_code, password_changed, email_changed) with its parameters.

Output Schema

Name	Required	Description	Default
`Result`	Yes	Result of the operation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 2, 2026
- addedInput schema / properties / From / properties / Address / description
```
Added value: +"Email address, e.g. ada@example.com."
```
- addedInput schema / properties / From / properties / Name / description
```
Added value: +"Optional display name shown with the address, e.g. Ada Lovelace."
```
- addedInput schema / properties / To / properties / Address / description
```
Added value: +"Email address, e.g. ada@example.com."
```
- addedInput schema / properties / To / properties / Name / description
```
Added value: +"Optional display name shown with the address, e.g. Ada Lovelace."
```
First observedNov 2, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, so the agent knows this is an irreversible external write. The description adds one genuinely useful trait beyond that: no consent gate, delivery is immediate. It does not warn about duplicate-send risk (idempotent=false), rate limits, or what the result looks like on failure, which the schema's From note only partially covers.

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?

Two sentences, zero filler, with the key behavioral trait front-loaded after the action statement. Nothing repeats the name or the schema.

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?

An output schema exists, so return values need not be described, and the schema is rich. But for a destructive, open-world send tool with a seven-way template union, the description omits the most decision-relevant context: how to pick a template, that a verified sender identity is required, and that sends cannot be undone or deduplicated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the Template union constraint (exactly one key) and the From sender-identity failure behavior, so the schema carries the parameter burden. The description adds no parameter meaning of its own — it never mentions the seven template variants, Subject limits, or that From is optional.

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 names a specific verb and resource ('Send a consentless template-based email') and adds a scope qualifier — sent immediately, without recipient consent — that meaningfully separates it from the enqueue/send_pending siblings. It stops short of naming any sibling explicitly, so the differentiation is inferential rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Immediate delivery versus consent-gated delivery is implied by 'sent immediately, without waiting for recipient's consent,' which nudges the agent away from enqueue_template_email. However, there is no explicit when-to-use/when-not guidance, no mention of send_pending_emails or the draft-test tools, and no prerequisites (verified sender domain, template choice) are stated.

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

All GoodSender 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.