Skip to main content
Glama
facebook-mcp

facebook-mcp

by IvanBBaev

Delete label

facebook_delete_label
DestructiveIdempotent

Permanently delete a custom Page label and clear it from every person it was assigned to. The action is irreversible; use label assignment removal to take it off one person instead.

Instructions

PERMANENTLY delete a custom label from the Page. It disappears from EVERY person it was on, and the assignments cannot be restored — to take it off one person, use facebook_assign_label with remove:true. Always requires apply:true together with the plan_id from a dry run.

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.
profileNoPage profile key (e.g. "brand-a") or a raw Page ID. Omitted ⇒ the default Page (FB_PAGE_ID).
label_idYesLabel id from facebook_list_labels.
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. Addedv0.8.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare destructiveHint=true, but the description goes further by spelling out the blast radius ('disappears from EVERY person it was on') and the irreversibility ('cannot be restored'), plus the apply/plan_id workflow. This is concrete behavioral context beyond the structured hints.

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-loads 'PERMANENTLY' for maximum warning impact, then delivers blast radius, the alternative, and the invocation requirement in tight clauses. Every sentence earns its place with zero waste.

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 an irreversible mutation with no output schema, the description covers what is destroyed, irreversibility, the alternative tool, and the required apply/plan_id flow. Nothing an agent needs to call it correctly 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 coverage is 100%, so each parameter is already well documented. The description reinforces the apply+plan_id conjunction requirement, but that is largely a restatement of what the schema already explains; 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 (delete) and resource (custom label from the Page), with scope clarified ('from the Page'). It explicitly contrasts itself with facebook_assign_label remove:true, so an agent can distinguish it from the closest sibling without opening schemas.

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?

Names the exact alternative (facebook_assign_label with remove:true) and the condition that selects it ('to take it off one person'). It also states the invocation prerequisite: apply:true together with a plan_id from a dry run. Nothing is left to inference.

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