GoodSender

Create Recipients

create_recipients

Destructive

Every listed recipient is submitted, whether or not it already exists locally (for example as a member of a group made with create_group); the server decides who gets a consent email: pending recipients and ones asked more than the cooldown ago are (re-)asked, granted recipients are re-asked only once inactive (120+ days without opens or clicks), denied ones never. A non-empty name replaces the stored one and an empty name keeps it; edit_recipient changes only the name. Consent emails are queued by the server. DomainResults reports the request outcome; list_recipients reports the last-known consent state. Neither guarantees delivery.

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": {
      "Recipients": {
        "ada@example.com": "Ada Lovelace",
        "bob@example.com": "Bob"
      },
      "SenderDomains": [
        "acme.com"
      ]
    },
    "name": "create_recipients"
  }
}

Input Schema

Name	Required	Description	Default
`Recipients`	Yes	Recipients to register; object keys are email addresses, values are display names (use empty string if none). Every listed recipient is registered on the server for each sender domain — including recipients this server already knows locally, e.g. from create_group — and the server decides who gets a consent request (see DomainResults).
`SenderDomains`	Yes	Sender domains to create recipients for. Each must exist and be verified already: verification requires all five of its DNS records — both DKIM CNAMEs, the return-path CNAME, the click-tracking CNAME and the DMARC TXT — to be in place; the Domain page of the GoodSender Console (https://goodsender.com/dashboard) lists which records are still missing. Domains come from the workspace (the Console import form offers the same list). list_sender_identities lists sender addresses only, so a verified domain without a sender identity is missing there; list_recipients shows every verified domain under ConsentsPerDomain.

Output Schema

Name	Required	Description	Default
`Result`	Yes	OK when the server acknowledged every submitted recipient for every sender domain; otherwise a description of the shortfall.
`DomainResults`	Yes	What the server reported for each sender domain.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover safety (destructive, openWorld, non-idempotent), and the description goes well beyond them: it discloses the server-side cooldown logic for re-asking consent, the 120-day inactive re-ask rule, that denied recipients are never re-asked, and that emails are queued without delivery guarantees. That is precisely the behavioral context annotations cannot express.

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?

Front-loaded with the core action, then the re-ask policy, then the name semantics. Dense but well organized; one sentence ('Neither guarantees delivery') is doing double duty and the density of conditional rules costs a bit of readability.

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 destructive two-parameter tool with a full output schema, the definition covers prerequisites (all five DNS records verified, with a pointer to the Console), domain sourcing, and the reference to DomainResults/ConsentsPerDomain for outcomes. Nothing an agent needs to invoke it correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics not in the schema: a non-empty name replaces the stored display name while an empty name preserves it. It does not mention the 1000-recipient / 100-domain caps, which the schema already carries.

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?

Opens with a specific verb+resource ('Register recipients on the server') scoped to verified sender domains and consent requests. It clearly distinguishes itself from edit_recipient (name-only) and list_recipients (state reporting) by name, so an agent can route correctly without opening schemas.

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 states that every listed recipient is submitted even if it already exists locally (e.g. from create_group), which resolves the ambiguity an agent would otherwise have about calling this vs. create_group. It also names edit_recipient for the name-only case and list_recipients for state, giving concrete alternatives and conditions.

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.