Postemi: Social Media Scheduler

delete_post

DestructiveIdempotent

Delete or cancel a scheduled or draft social media post in the user's Postemi calendar, before it goes out: the undo for create_post. Take the postId from list_posts or from create_post's own result.

REFUSES A POST THAT HAS ALREADY BEEN PUBLISHED. Postemi cannot remove a post from the platform; deleting the Postemi record would leave it live with nothing pointing at it. Check "state" in list_posts first — only QUEUE, DRAFT and ERROR posts can be deleted.

By default this deletes ONE post: the postId's channel only, with its thread or comment entries. Other channels of the same group (posts with the same "group" in list_posts) stay scheduled. Set allChannels to true to delete the whole group from every channel at once; then, if any channel of the group has already published, nothing is deleted at all. The result names every channel it removed, with the @handle, so you can tell the user exactly what is gone.

Ask the user before calling this, and ask whether they mean one channel or all channels when the post has several. It cannot be undone.

Magyarul: ütemezett poszt törlése, visszavonása.

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

Input Schema

Name	Required	Description	Default
`postId`	Yes	The post to delete, as returned by list_posts (postId) or by create_post (postId).
`allChannels`	No	false or omitted: delete only this one post (one channel). true: delete the whole group, every channel this post went to.

Output Schema

Name	Required	Description	Default
`errors`	No
`output`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds genuine context beyond them: the published-post refusal and why (orphaned live post), the default single-channel scope with threads/comments, the group expansion via allChannels, the all-or-nothing failure when any channel already published, and confirmation that the result enumerates removed channels by @handle. It also states irreversibility in plain terms.

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?

Strongly front-loaded: the action and the hard constraint (refuses published posts) come before the group/allChannels mechanics. Every paragraph carries operational weight, but the trailing 'Magyarul' translation line and the a-tag-style restatement of the outcome add length without adding decision-relevant information.

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 need no explanation beyond the useful behavioral note that the result names removed channels. Combined with the destructive annotations, the refusal rules, and the group semantics, an agent has everything needed to decide whether to call it and how to call it safely.

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, but the description earns more by adding meaning the schema lacks: where postId comes from, and crucially the conditional semantics of allChannels (whole group across every channel, atomic abort if any channel published). It does not add format/syntax detail beyond that, so it stops short of 5.

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 pair ('Delete or cancel a scheduled or draft social media post') and pins the scope ('before it goes out'). It explicitly distances itself from siblings by framing itself as 'the undo for create_post' and naming list_posts as the source of postId.

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 an explicit refusal rule ('REFUSES A POST THAT HAS ALREADY BEEN PUBLISHED'), the precondition to check state in list_posts with the exact allowed values (QUEUE, DRAFT, ERROR), and the alternative path (Postemi cannot remove it from the platform). It also instructs the agent to ask the user first and to clarify one-channel vs all-channels, which is usage guidance an agent cannot infer.

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

All Postemi: Social Media Scheduler 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.