Skip to main content
Glama
Sign In

Variafy

by com.variafy
OverviewDiscussionsAdmin

Archive or delete Meta ads objects

meta_ads_delete
Destructive

Archives or deletes objects in a Meta ad account. Delivery stops for good: Meta does not bring an archived or deleted object back, and an archived one accepts only DELETED afterwards. Call meta_ads_delete with {"action":"execute","tool_name":"archive_object","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:

  • archive_object: Archive or delete a campaign, an ad set or an ad. It stops delivery for good: Meta cannot bring an archived or deleted object back. Only reduces spend, and counts toward the monthly change limit.

  • delete_monitor: Delete a monitor: it stops being checked and stops sending email. Changes only this server’s own monitor, nothing in Meta, and never counts toward the monthly change limit.

  • delete_scheduled_task: Delete a scheduled brief or a monitor: it stops for good. Changes only this server’s own monitor, nothing in Meta, and never counts toward the monthly change limit.

  • delete_audience: Delete a custom audience that no running ad uses.

  • delete_product: Delete one product from a catalog. Ads stop showing it; product sets simply no longer include it.

  • delete_product_set: Delete a product set that no catalog ad set of this ad account promotes. The products themselves stay in the catalog. Only reduces spend, and counts toward the monthly change limit.

  • delete_product_feed: Delete a product feed and its schedule. Products that came only from it are removed, and ads stop showing them. Only reduces spend, and counts toward the monthly change limit.

  • disconnect_catalog_event_source: Disconnect a pixel from a product catalog: its events stop being matched to the catalog's products. Only reduces spend, and counts toward the monthly change limit. Every operation takes two calls with the same tool_name and arguments; the first makes no change in Meta and returns a preview. If the operation cannot increase spend, the preview includes confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. An operation that can increase spend is never executed from chat: its preview has no token, only an approve_url for a signed-in person. Executed changes count toward the monthly change limit; the preview is refused once the limit is reached. This is not the pause lane: when Meta rate limits the ad account the request may be held, so check the result with a read. If the same change was already executed or its outcome is unknown, the preview has no confirm_token; check with a read first. If a proposal for the same change is still pending after its confirm_token expired, the call returns awaiting_human and only a person can apply it via approve_url. Input schemas: get_tool_schema for named operations; meta_ads_read {"action":"list_tools"} lists every operation with its field names.

Input Schema

NameRequiredDescriptionDefault
actionYesAlways "execute".
argumentsYesThe fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call.
tool_nameYesThe operation name, e.g. archive_object.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true and idempotentHint=false; the description goes far beyond them, disclosing the two-call preview/execute flow, the 10-minute confirm_token lifetime, approve_url for spend-increasing operations, the monthly change limit, awaiting_human behavior, and that archived objects accept only DELETED afterwards. It also states that delete_monitor and delete_scheduled_task affect only the server and never touch Meta.

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?

Front-loaded with the operation list and the two-call mechanics, and nearly every sentence carries an actionable rule. It loses a point for redundancy: the 'stops delivery for good / cannot bring it back' warning appears twice, and the 'only reduces spend, counts toward the monthly change limit' boilerplate is repeated in most bullets where a single statement would do.

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?

No output schema exists, so the description carries the return burden and does so: it describes what a preview returns (confirm_token or approve_url, or neither when the change was already executed) and what awaiting_human means. All prerequisite states an agent needs before calling are covered.

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?

With 100% schema coverage the baseline is 3, but the description adds real meaning: 'arguments' carries the operation's fields plus 'connection' when multiple ad accounts are connected, and confirm_token only on the second call. It also routes the agent to get_tool_schema and meta_ads_read list_tools for per-operation field names, which the schema itself does not convey.

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 and resource ('Archives or deletes objects in a Meta ad account') and then enumerates all nine operations with what each one destroys. It also implicitly separates itself from meta_ads_update by naming 'This is not the pause lane' and from meta_ads_read by directing status checks there.

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 explicit when-to-use guidance per operation, plus decision rules for the hard cases: use a read when the change was already executed, when the outcome is unknown, or when rate limited; only a signed-in person can apply spend-increasing changes via approve_url. Alternatives and exclusions are spelled out rather than implied.

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

All Variafy 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