Skip to main content
Glama

Delete a ROAS pause rule

automate_delete_automation_rule
DestructiveIdempotent

Delete an automation rule. Admin only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
scopeNo
titleNo
actionNo
metricNo
reasonNo
confirmNo
date_toNo
dry_runNo
rule_idNo
user_idNo
operatorNo
platformNo
action_idNo
client_idNo
conditionNo
date_fromNo
is_activeNo
min_spendNo
thresholdNo
to_amountNo
user_emailNo
campaign_idNo
report_typeNo
confirm_liveNo
range_presetNo
lookback_daysNo
cooldown_hoursNo
roas_thresholdNo
consecutive_daysNo
google_customer_idNo
meta_ad_account_idNo
max_actions_per_dayNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already cover the destructive/idempotent/read-only profile, and the description adds the useful 'Admin only' auth constraint. But for a destructive operation whose schema exposes confirm, confirm_live, and dry_run, the description says nothing about dry-run previewing, confirmation requirements, or irreversibility of the deletion.

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?

Two short sentences, front-loaded with the action, with no filler. It is terse to the point of under-specification, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 33-parameter destructive tool with zero required fields and no schema documentation, the description leaves out the identifying parameter, the meaning of confirm/dry_run, and the target rule type. An output schema exists so return values need not be explained, but the invocation-relevant gaps are severe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 33 parameters with 0% description coverage and no enums, and the description mentions none of them. An agent cannot tell from the description that rule_id is the likely identifier or what confirm/dry_run do, so the description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Delete) and resource (automation rule), which separates it from the upsert/list siblings. However, it does not differentiate itself from the adjacent delete siblings (delete_alert_rule, delete_seo_alert_rule) or explain what an 'automation rule' is, leaving the title to carry that specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Admin only' is the sole usage constraint and functions as a permission prerequisite rather than a when-to-use guide. Nothing says when to delete versus deactivate a rule, nor when to prefer the sibling delete tools, and no alternatives are named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.