Skip to main content
Glama
Sign In
facebook-mcp

facebook-mcp

by IvanBBaev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Delete Post

facebook_delete_post
DestructiveIdempotent

Permanently delete an app-created Facebook Page post, including scheduled ones to cancel them; no undo.

Instructions

Permanently delete a Page post the app itself created — including a scheduled one, which is the only way to cancel it. There is no undo and no trash: the text, comments, reactions and shares are gone. Irreversible tier, so applying ALWAYS needs both apply:true and the plan_id of a preceding dry run, whatever FB_WRITE_MODE says. Reels: whether a Reel can be deleted here by its video ID is UNVERIFIED against the live API — Reels are invisible on post endpoints, so assume neither outcome and re-read the Page afterwards.

Input Schema

NameRequiredDescriptionDefault
applyNoSet true to actually perform the write. Omitted or false ⇒ the server decides from its configured write mode: usually a dry run that returns a plan preview and changes nothing, but a server (or package) configured apply-first performs the write. To be certain nothing happens, read the result: a dry run always reports the plan and says the write was NOT performed.
plan_idNoThe `planId` returned by a preceding dry-run preview of this same tool. Required for irreversible and spend-tier writes; plans expire a few minutes after they are created.
post_idYesThe post ID, normally "{page-id}_{post-id}". Only posts this same app created can be edited or deleted — a post made in the Facebook UI or by another app is not addressable here.
profileNoPage profile key (e.g. "brand-a") or a raw Page ID. Omitted ⇒ the default Page (FB_PAGE_ID).
confirm_tokenNoOut-of-band operator token (FB_CONFIRM_TOKEN) authorizing this one irreversible or spend-tier apply. Needed only when the MCP client cannot show a confirmation prompt. Ask the human operator for it; it is not stored between calls and is never echoed back.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • addedInput schema / properties / post_id / pattern
      Added value: +"^(?=.*\\w)[\\w.-]+$"
  2. First observedv0.7.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds real context beyond them: what is destroyed (text, comments, reactions, shares), that there is no trash or undo, the irreversible-tier confirmation dance, the confirm_token fallback, and an honest UNVERIFIED caveat about Reels. It also warns the agent to re-read the Page afterwards rather than trusting the result.

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?

Front-loaded with the action, then consequences, then the apply protocol, then the API caveat — each sentence adds a distinct operational fact and none repeat the schema verbatim. Dense but no filler.

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 5-parameter destructive tool with no output schema, everything an agent needs is present: scope limits, irreversibility, the two-step apply protocol, token fallback, and post-call verification advice.

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 adds a cross-parameter constraint the schema states only piecemeal: apply plus plan_id are jointly mandatory for this operation and override the server's write mode. It also flags that the plan expires, which shapes call sequencing.

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 and resource ("Permanently delete a Page post") plus a hard scope restriction ("the app itself created"), which separates it cleanly from facebook_delete_comment and facebook_update_post. The scheduled-post case is called out explicitly, so an agent knows this is also the cancel path.

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?

Gives a clear precondition (always requires apply:true plus a plan_id from a preceding dry run, regardless of FB_WRITE_MODE) and the scenario that selects this tool over alternatives (canceling a scheduled post). It does not name sibling tools such as update_post as the non-destructive alternative, which keeps it short of a 5.

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

Deploy Server

Other Tools