Skip to main content
Glama

Chirpie

by io.github.Firefloco
OverviewDiscussionsAdmin

Delete a post

chirpie_delete_post
DestructiveIdempotent

Delete a post. If it was already published, the platform is told first, and the post is reported deleted only once the platform confirms it is gone; if the platform refuses or is unavailable the call fails with upstream_error and nothing changes, so the same request can simply be retried. If it has not gone out yet, nothing reaches a platform at all: a queued post is cancelled and its quota returned (cancelled_ids), while a draft is simply marked deleted (deleted_ids) and nothing is returned, because a draft never counted against any quota. Deleting a draft returns no quota. A Facebook Page story and any published post on an Instagram account connected by signing in with Instagram rather than through a Facebook Page cannot be deleted through the platform's API, so each is refused with delete_unsupported rather than reported deleted and stays published; it can be deleted in the platform's own app, and chirpie_hide_post keeps it out of the Chirpie listings. THE POST IS NEVER REMOVED FROM CHIRPIE: it keeps its id and its history with status 'deleted', so chirpie_get_post still returns it. Deleting any post of a scheduled thread cancels the whole thread: a thread is published as a unit, so it is cancelled as one. Deleting a published post reaches the platform and cannot be undone; chirpie_hide_post is the reversible alternative, which changes only what Chirpie shows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesPost ID to delete

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes far beyond the annotations (destructiveHint/idempotentHint/openWorldHint): it explains upstream_error retry semantics, quota-return behavior via cancelled_ids/deleted_ids, delete_unsupported platform cases, thread-wide cancellation, and that the post persists in Chirpie with status 'deleted'. This is rich, non-redundant behavioral disclosure.

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?

Long and dense, but every sentence carries a distinct behavioral fact rather than filler, and the core operation is front-loaded. It is justified by the tool's complexity, though the multi-clause sentences could be trimmed slightly.

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 mutation tool with no output schema, the description supplies everything an agent needs: return signals (cancelled_ids, deleted_ids), error cases (upstream_error, delete_unsupported), reversibility, and post-deletion state. Nothing material 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?

Only one parameter with 100% schema coverage, so the schema already documents 'Post ID to delete'. The description alludes to post identity (kept id, history, status 'deleted') but adds no syntax or format meaning for the parameter itself; baseline 3 is appropriate.

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+resource ('Delete a post') and immediately distinguishes itself from chirpie_hide_post by naming it as the reversible alternative. The description makes the tool's distinct behavior (platform-reaching, irreversible) unmistakable versus any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names alternatives explicitly: chirpie_hide_post is called out as the reversible alternative for published posts and for unsupported cases, and the platform's own app is noted. However, it never states a clean prescriptive 'use this when/not when' rule, leaving the routing inference partly to the reader.

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

All Chirpie toolsInspect
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