GoodSender

Broadcast Post

broadcast_post

Destructive

Email a published post's newsletter to consented recipients on the blog sending domain. At most once per post — and not at all if a publish already sent the newsletter selected in the post's distribution. Requires a configured blog sender and a public address for the post.

This is irreversible and unrepeatable — the one moment this post reaches the list. send_post_test sends a test copy of the same email to a single inbox beforehand.

The email carries the Subject, the post's cover image when one is set (CoverImageURL), the Summary (else the saved newsletter summary, else the post's summary) and a "Read the full post" link button to the post's public address — never the post body. edit_post changes the cover; an edit after broadcasting cannot reach the inboxes already sent. Without a Subject the email falls back to the saved subject, else the post title; a title and a subject are different jobs.

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>"
    },
    "name": "broadcast_post"
  }
}

Input Schema

Name	Required	Description
`PostID`	Yes	Published post id to broadcast. Two preconditions, both rejected with a 400: the post must already be published (publish_post publishes it), and its body must not be empty.
`Subject`	No	The email subject line. Omitting it falls back to the subject saved with the post, else the post title. This send cannot be repeated or taken back.
`Summary`	No	The email's body text. Markdown is rendered (raw HTML is not); the Read the full post button carries the post's link. Omit it to use the summary saved with the post for the newsletter, else the post's own summary. At most 5000 characters.

Output Schema

Name	Required	Description
`Plan`	Yes	Who receives the email and exactly what it says, with WARNING lines for what stops it.
`Slug`	Yes	URL slug.
`Tags`	Yes	Tags.
`Title`	Yes	Visible post headline; also the search/social title fallback when SEO Title is empty.
`Author`	Yes	Author display name if set.
`PostID`	Yes	Post id.
`Status`	Yes	draft or published.
`Summary`	Yes	Human-facing lede; also the word-aware metadata-description fallback when Description is empty.
`Markdown`	Yes	Markdown body.
`SEOTitle`	Yes	Stored optional search/social title override, or empty when Title supplies the fallback.
`AuthorURL`	Yes	Author URL if set.
`CreatedAt`	Yes	ISO-8601 created time.
`UpdatedAt`	Yes	ISO-8601 updated time.
`Categories`	Yes	Categories.
`Provenance`	Yes	Agent attribution, absent on a human-authored post.
`Description`	Yes	Stored optional search/social description override, or empty when the word-aware Summary fallback supplies metadata.
`PublishedAt`	Yes	ISO-8601 publish time if set.
`CoverImageAlt`	Yes	Cover image alt text, or empty when unset. (FR-020)
`CoverImageURL`	Yes	Cover image URL, or empty when unset. Rendered on the post page, card, social metadata, and in the newsletter email - distinct from any image inside Markdown. CoverImageAlt describes it.
`AuthorAvatarURL`	Yes	Author photo URL if set — shown beside the byline and as the author's image in structured data.
`LastBroadcastAt`	Yes	ISO-8601 broadcast time if set.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

changedInput schema / properties / Subject / description

Previous value: -"The inbox line. Omitting it falls back to the subject saved with the post, else the post title - usually the weaker choice: a title is written for a page and for search, a subject is written for a crowded inbox. Front-load the specific thing that happened, since mobile clients truncate around 40 characters. No positional labels like Newsletter #4, no clickbait, and do not restate the blog name - the sender already carries it. This send cannot be repeated or taken back."New value: +"The email subject line. Omitting it falls back to the subject saved with the post, else the post title. This send cannot be repeated or taken back."

changedInput schema / properties / Summary / description

Previous value: -"The email's body text: a few short paragraphs, written to make a subscriber open the post - not the post itself. Markdown is rendered (raw HTML is not); leave the post's link out, the Read the full post button carries it. 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: +"The email's body text. Markdown is rendered (raw HTML is not); the Read the full post button carries the post's link. Omit it to use 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.8/5.0

Behavior5/5

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

Annotations already declare destructive=true, idempotent=false, openWorld=true, but the description adds what they cannot: the irreversibility is temporal and unrepeatable ('the one moment this post reaches the list'), the two 400 preconditions, the fallback chains, and the fact that an edit_post after broadcasting cannot reach delivered inboxes. It also discloses exactly what the email contains and what it deliberately excludes (never the post body).

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?

Well front-loaded: purpose, frequency constraint, and preconditions come before the email-content detail. The irreversibility warning is restated in the Subject parameter schema and the third paragraph, and 'This is irreversible and unrepeatable — the one moment this post reaches the list' is a slightly rhetorical restatement, but no sentence is wholly wasted.

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, non-idempotent, open-world send with an output schema present, the description covers everything an agent needs before calling: preconditions, frequency limits, fallback behavior, and the irreversibility model. Return values are handled by the output schema, so nothing material 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; the description earns above that by adding semantics not in the schema — the Subject/Summary resolution fallback ordering, the cover image ('CoverImageURL') and 'Read the full post' button composition, and the note that 'a title and a subject are different jobs.' It does not add format/syntax detail for PostID beyond what 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: 'Email a published post's newsletter to consented recipients on the blog sending domain.' It also scopes the operation against siblings by naming send_post_test, edit_post, and publish_post, so an agent can pick it out of a 50-tool list without opening a schema.

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 and when-not-to-use rules: 'At most once per post — and not at all if a publish already sent the newsletter selected in the post's distribution', plus preconditions (configured blog sender, public address). It routes to the correct alternative explicitly: 'send_post_test sends a test copy of the same email to a single inbox beforehand.'

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.