meta_ads_creative_delete
Permanently delete a Meta Ads ad. Irreversible.
Bulk support: accepts ad_ids for batched execution.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ad_id | Yes | ||
| ad_ids | No | ||
| auth_account | No |
Permanently delete a Meta Ads ad. Irreversible.
Bulk support: accepts ad_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_id | Yes | ||
| ad_ids | No | ||
| auth_account | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already mark the tool as destructive, the description adds meaningful behavioral context: deletion is permanent and irreversible. It also discloses bulk execution support via ad_ids, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loads the core message, and adds only the high-value detail about bulk support. Every sentence earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the destructive nature, irreversibility, and bulk capability, which is reasonable for a delete tool with strong annotations. However, the lack of parameter semantics and absence of any guidance on batch vs single deletion leaves the description incomplete for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter ambiguity. It only explains ad_ids for batching and does not clarify the relationship between ad_id and ad_ids, nor the purpose of auth_account. This leaves key invocation semantics underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Permanently delete') and the resource ('a Meta Ads ad'), making the tool's purpose unmistakable. It also differentiates from sibling delete tools by naming the 'ad' resource rather than adset, campaign, or audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool over sibling delete tools, nor when not to use it. The bulk-support note hints at one usage scenario, but there is no explicit direction about prerequisites, alternatives, or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools are near-identical variants of the same action, with only a `[Flattened action]` marker distinguishing e.g. the four `meta_ads_campaign_write_*` tools and the three `meta_ads_creative_write_*` tools. The reporting tools also overlap: `meta_ads_ads`, `meta_ads_realtime`, `meta_ads_today`, and `meta_ads_roas` all return spend/performance data, making selection genuinely ambiguous. Unrelated platform tools like `marketplace` and `toolkit_info` are mixed in, further muddying what the server is for.
Most Meta Ads tools follow a readable `meta_ads_<resource>_<action>` snake_case convention, and write actions are reasonably predictable. However, there are inconsistencies: `meta_ads_ads` vs `meta_ads_audience`, `meta_ads_business_list` vs `meta_ads_business_accounts` vs `meta_ads_list_accounts`, and `meta_ads_adset_delete` vs the `meta_ads_adset_write_*` grouping. The unbranded platform tools (`connect`, `report_bug`, `show_version`) also break the pattern.
44 tools is far above the recommended range and pushes the server into unwieldy territory. The count is inflated because flattened actions were expanded into separate tools: the campaign write tool appears four times, audience write twice, adset create/update twice, creative tools three times, media upload three times, and business/pages actions once per variant. A consolidated action-based design could reduce real surface area to roughly 15-20 tools.
The core Meta Ads lifecycle is well covered: campaigns, ad sets, creatives/ads, custom audiences, media upload, business managers, pages, and reporting all have create/read/update/delete or equivalent destinations. The main gaps are no direct `list_ad_sets` tool, no `remove_users` for audiences, and an apparent reference to a nonexistent `meta_ads_media` tool for listing uploaded media. These are noticeable but usually workaroundable.