Rizamo

Publish a post now

publish_post

Destructive

Use this only when the person asked to publish now, or to send again what failed: every target that is not live goes out now. Not for a later time: create_post or update_post schedule it. Follow each target with get_post until it is published or failed; list_events with the post's id says why one failed. A target that is unknown may have gone out: check the account before you publish again.

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": {
      "id": "<id>"
    },
    "name": "publish_post"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	The post's id (`post_`).
`idempotencyKey`	No	Optional. A new unique string for each new action, such as a UUID. When a call timed out or failed and you send it again, send the same key: for 24 hours the same call gets the first one's answer instead of doing it twice.

Output Schema

Name	Required	Description	Default
`id`	No
`text`	No
`chain`	No
`media`	No
`fields`	No
`queued`	No
`status`	No
`metrics`	No
`targets`	No
`createdAt`	No
`createdBy`	No
`deletedAt`	No
`profileId`	No
`updatedAt`	No
`publishedAt`	No
`scheduledAt`	No
`sharedUntil`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description adds real value on top: it discloses that every non-live target goes out simultaneously (partial-publish semantics), that outcomes must be verified per target, and that an ambiguous result may mean the post already went live. It does not explain rate limits, auth scope, or what an already-live target does when re-published, so it stops short of a 5.

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?

Four tight sentences, each doing distinct work: permission gate, exclusion with alternative, verification workflow, retry hazard. The usage constraint is front-loaded and there is no filler or restatement of the title.

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, open-world publish action with only one required parameter and an existing output schema, the description covers selection, exclusion, failure diagnosis, and the dangerous retry case. Nothing an agent needs in order to call it safely is missing.

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%, so both id and idempotencyKey are fully documented in the schema, including the 24-hour replay behavior. The description only gestures at the retry case ('send again what failed') and adds no syntax or format detail beyond the schema, which is the correct baseline here.

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 ('publish a post') and immediately scopes it with 'now', which separates it from create_post/update_post that only schedule. An agent can distinguish this from the scheduling siblings without inspecting either 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?

Explicit when-to-use ('only when the person asked to publish now, or to send again what failed'), explicit when-not ('Not for a later time'), and named alternatives (create_post, update_post). It even prescribes the post-call verification loop (get_post polling, list_events for failure reasons) and a caution before retrying an unknown target.

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

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

Resources

Need Help?