Skip to main content
Glama

Set Post Distribution

set_post_distribution
DestructiveIdempotent

Change where a post goes when it is published: select or deselect each destination, set or clear each Announce destination's reviewed text, and select the newsletter with its subject and summary. Only what you pass changes; omitted fields stay as they are.

The GoodSender API enforces the dashboard's rules: a destination can be turned on only while it is connected and syndication is available, and an Announce text can be saved only while syndication is available and must fit its destination's limit (turning one off or clearing a text is always allowed). A request the API refuses changes nothing. Nothing is published or sent here — publish_post acts on this selection.

get_post_distribution reports the current selection. Changes lists exactly what this call changes; the selection decides what later goes out in the user's name.

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": "set_post_distribution"
  }
}

Input Schema

NameRequiredDescriptionDefault
XNoX (Announce). Omit to leave it unchanged.
DevtoNodev.to (Republish). Omit to leave it unchanged.
PostIDYesPost id, from create_post or list_posts.
BlueskyNoBluesky (Announce). Omit to leave it unchanged.
LinkedInNoLinkedIn (Announce). Omit to leave it unchanged.
MastodonNoMastodon (Announce). Omit to leave it unchanged.
NewsletterNoThe built-in newsletter. Omit to leave it unchanged.

Output Schema

NameRequiredDescriptionDefault
ResultYesOK once applied, or why nothing was changed. On a local server with action guards on, the pending-confirmation notice while the change awaits approval.
ChangesYesExactly what the change does, one line per change, with warnings for what the API will refuse.
DistributionYesThe distribution: the current one while awaiting confirmation, the updated one once applied.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) by disclosing partial-update semantics, the API's enforcement rules (destination must be connected, syndication must be available, copy must fit the destination limit), the refusal behavior ('A request the API refuses changes nothing'), and that deactivation/clearing is always permitted. That atomicity and validation detail is exactly what an agent cannot infer from annotations.

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?

Three short paragraphs, front-loaded with the action and then the constraints, with no filler sentences. Dense but every clause carries information; the only cost is a slight repetition of the read/write sibling relationship that also appears in the last line.

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 7-parameter mutation tool with rich annotations, a 100%-covered schema, and an output schema, the description fills the remaining gaps: partial-update semantics, server-side validation and atomic refusal, and the handoff to publish_post. Nothing an agent needs to invoke this 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 schema already documents every nested field including Budget via get_post_distribution and the Clear* flags. The description still adds orientation by grouping parameters into three behavioral tiers — Announce destinations, the republish destination, and the newsletter — which helps an agent map intent to the right nested object.

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?

States a specific verb and resource ('Change where a post goes when it is published') and then enumerates the three concrete operations: destination selection, Announce copy set/clear, newsletter selection with subject and summary. It explicitly separates itself from publish_post ('acts on this selection') and get_post_distribution ('reports the current selection'), so an agent can place it among siblings without opening any 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 usage context: call it to change the selection, call get_post_distribution to read it, call publish_post to act on it, and 'Nothing is published or sent here.' It also states the key operational rule 'Only what you pass changes; omitted fields stay as they are,' which tells the agent exactly how to call it for partial updates.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.