meta_ads_adset_delete
Permanently delete a Meta Ads ad set. Irreversible.
Bulk support: accepts adset_ids for batched execution.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| adset_id | Yes | ||
| adset_ids | No | ||
| auth_account | No |
Permanently delete a Meta Ads ad set. Irreversible.
Bulk support: accepts adset_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| adset_id | Yes | ||
| adset_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?
The annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds 'Permanently delete' and 'Irreversible,' reinforcing the permanence beyond a simple destructive flag. It also mentions bulk support, which is not captured in annotations. No contradictions are present. The description covers key behavioral traits adequately given the 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: two short sentences, front-loaded with the primary purpose. It wastes no words and efficiently conveys the core action, irreversibility, and bulk capability. This is a model of terseness with no filler.
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 tool is a simple delete operation with no output schema. The description covers the essential aspects: permanent deletion, irreversibility, and bulk option. It lacks details on error handling or side effects (e.g., impact on associated ads), but given the simplicity and annotations, this is acceptable. The only notable gap is the lack of parameter usage details, but that is already penalized in parameter semantics.
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. It only mentions 'accepts adset_ids for batched execution,' which partially explains the adset_ids parameter but does not clarify the relationship between adset_id and adset_ids (e.g., whether both can be used, precedence) nor explain auth_account. The description adds minimal semantic value beyond the raw schema, leaving ambiguity about the required adset_id and optional batch usage.
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 states the operation: 'Permanently delete a Meta Ads ad set.' It specifies the resource (ad set) and the action (delete), with the added qualifier 'permanently' and 'irreversible' to emphasize the destructive nature. This distinguishes it from sibling tools like update or create, and also from deletion of other resources (e.g., campaigns, audiences).
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 implies usage for permanently removing an ad set, but does not explicitly contrast with alternatives like pausing or deactivating via update tools. It does not mention when not to use this tool (e.g., if the goal is temporary deactivation). While the name and destructive nature make the primary use case clear, the lack of explicit guidance relative to other operations prevents a higher score.
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.