GoodSender

Send Post Test Email

send_post_test

Destructive

Send a one-off test email of the post to a single inbox. Requires a configured blog sender. Charges the workspace send quota.

The rehearsal for broadcast_post, and the only way to see a post as an email before it reaches the list. Works on a draft, so it belongs before publishing, not after.

The test is meant for the user's own inbox, not an address from the mailing list. With the Subject and Summary intended for the broadcast it rehearses the real thing: the email carries the subject, the post's cover image when one is set (CoverImageURL, which create_post and edit_post set), that summary and a link to the post — never the post body. A post with no public address yet still sends: its link then points at the blog landing page instead of the post.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "PostID": "<PostID>",
      "Recipient": "<Recipient>"
    },
    "name": "send_post_test"
  }
}

Input Schema

Name	Required	Description
`PostID`	Yes	Post id to send as a test. Works on a draft too, so this is the way to see a post rendered as email before publishing it.
`Subject`	No	Optional subject, falling back to the subject saved with the post, else the post title. The subject intended for the broadcast makes the test rehearse the real inbox line; mobile clients truncate after about 40 characters.
`Summary`	No	Optional email body text - the summary the newsletter shows above its Read the full post link. The Summary intended for the broadcast makes the test render the exact email. Omitted, it falls back to the summary saved with the post for the newsletter, else the post's own summary. At most 5000 characters.
`Recipient`	Yes	The single inbox that receives the test copy: one address, normally the user's own, never a recipient from the mailing list.

Output Schema

Name	Required	Description	Default
`Result`	Yes	Result of the operation.
`Recipient`	Yes	Recipient that received the test.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

changedInput schema / properties / Subject / description

Previous value: -"Optional subject, falling back to the subject saved with the post, else the post title. Send the exact subject you intend to broadcast with, so the test rehearses the real inbox line: front-loaded and specific, under about 40 characters before mobile clients truncate."New value: +"Optional subject, falling back to the subject saved with the post, else the post title. The subject intended for the broadcast makes the test rehearse the real inbox line; mobile clients truncate after about 40 characters."

changedInput schema / properties / Summary / description

Previous value: -"Optional email body text - the summary the newsletter shows above its Read the full post link. Send the Summary you intend to broadcast with, so the test renders the exact email. Omit it to use the summary saved with the post for the newsletter, else the post's own summary. At most 5000 characters."New value: +"Optional email body text - the summary the newsletter shows above its Read the full post link. The Summary intended for the broadcast makes the test render the exact email. Omitted, it falls back to the summary saved with the post for the newsletter, else the post's own summary. At most 5000 characters."

First observedNov 2, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the quota charge, the sender configuration prerequisite, and exactly what the generated email contains (subject, cover image when set, summary, link — never the post body). It also covers an edge case the annotations cannot: posts without a public address still send with a link to the blog landing page.

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 purpose, then prerequisites, then routing, then email composition. Every sentence carries information, though the email-contents passage is lengthy and restates schema-level facts about Subject and Summary.

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?

An output schema exists so return values needn't be explained; the description instead supplies everything an agent needs to call correctly — prerequisites, quota cost, draft applicability, recipient restriction, and rendered email contents including the no-permalink fallback.

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 coverage is 100%, so all four parameters are already fully documented, including the Subject/Summary fallback chains. The description reinforces the intent-to-rehearse-broadcast framing but adds little syntax or semantics beyond the schema; baseline 3 applies when the schema does the heavy lifting.

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?

Opens with a specific verb and resource: 'Send a one-off test email of the post to a single inbox.' It explicitly positions itself as 'the rehearsal for broadcast_post,' which separates it from the real broadcast. It does not address the sibling send_template_draft_test_email, so full sibling differentiation is incomplete.

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?

Gives explicit when-to-use ('the only way to see a post as an email before it reaches the list'), sequencing ('belongs before publishing, not after'), and a when-not constraint ('not an address from the mailing list'). Prerequisites ('Requires a configured blog sender') are also stated up front.

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.