Ravenpost

Publish a post you confirmed

confirm_publish

Destructive

Release a publish the user has just confirmed on the post card. The card calls this when the person presses its Publish button; it is hidden from models and is not for one to call — confirmation is a code only the card is given, and any other value is refused. The code is tied to the request the card shows: an edit, a newer request, or a day without an answer makes it lapse, and the card then sends the person to Ravenpost. Released, the post publishes now — or at the time that was asked for, while that is still ahead — on every target account, where it is public. That cannot be undone from here: delete_post removes only Ravenpost's copy, and a post on Instagram, TikTok, Threads and YouTube cannot be taken down through Ravenpost at all.

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

Input Schema

Name	Required	Description	Default
`postId`	Yes	The post the card shows
`confirmation`	Yes	The code the card was given with the post — never one made up

Output Schema

Name	Required	Description	Default
`ok`	No
`post`	No
`preview`	No
`awaitingConfirmation`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, it discloses the authorization model (a card-issued confirmation code; other values refused), expiry conditions (edit, newer request, or a day without an answer), timing behavior (publishes now or at the requested future time), scope (every target account, publicly visible), and irreversibility. It also clarifies that delete_post only removes Ravenpost's copy and external platforms cannot be taken down through Ravenpost.

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?

The purpose is front-loaded in the first sentence, and the remaining sentences carry risk and authorization details rather than filler. It is dense and slightly long for two parameters, but almost every clause adds information an agent needs to avoid misuse.

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, externally visible publish action, the description covers the critical gaps: who may call it, what the confirmation code means, when it expires, what publishing does across targets, and why the action cannot be undone from here. An output schema exists, so return values need not be explained.

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 both parameters. The description adds meaningful semantics beyond the schema: the confirmation code is tied to the request shown on the card, any other value is refused, and the code lapses under specific conditions.

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?

The description states a specific action and resource: it releases a publish the user has confirmed on the post card. It also distinguishes this tool from ordinary publishing by explaining that the card calls it and that it is hidden from models, so an agent can tell it is not the normal publish path.

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?

It gives an explicit exclusion: 'hidden from models and is not for one to call.' It also explains the card-driven context and the fallback when the confirmation lapses, which is exactly the when/when-not guidance an agent needs.

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

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