PixelFlow

Delete blocking rule

delete_blocking_rule

DestructiveIdempotent

Delete the blocking rule for one event on a site, such as Purchase, or the AllEvents rule. Rules for other events stay. After an event's own rule is deleted, the AllEvents rule applies to that event again. After the AllEvents rule is deleted, events without their own rule are no longer blocked. If the event has no rule, the call is refused and nothing changes. Returns the events that still have a rule, including AllEvents. Repeating an idempotency_key deletes once. Use it when the user wants events that a rule blocks to reach ad platforms again.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site_id": "<site_id>",
      "idempotency_key": "<idempotency_key>",
      "target": "<target>"
    },
    "name": "delete_blocking_rule"
  }
}

Input Schema

Name	Required	Description
`target`	Yes	AllEvents, or the event whose rule to delete, such as Purchase. Event names are in list_supported_values's `events`.
`site_id`	Yes	Site to act on, as returned by list_sites.
`idempotency_key`	Yes	Unique string per intended change, such as a UUID. Repeating a key returns the first result instead of writing again.

Output Schema

Name	Required	Description	Default
`rules_left`	Yes	Events that still have a blocking rule after the delete, such as AllEvents or Lead. Empty when the site has no rules left.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 2, 2026

changedInput schema / properties / idempotency_key / description

Previous value: -"Key for this approval line. The same key twice changes one blocking rule"New value: +"Unique string per intended change, such as a UUID. Repeating a key returns the first result instead of writing again."

removedInput schema / properties / site

Removed value: -{
-  "description": "Domain, id, or external id from list_sites",
-  "type": "string"
-}

addedInput schema / properties / site_id

Added value: +{
+  "description": "Site to act on, as returned by list_sites.",
+  "type": "integer"
+}

removedInput schema / properties / suggestion_id

Removed value: -{
-  "description": "Proposal id when this line came from suggest_triggers. Omit otherwise",
-  "type": "string"
-}

changedInput schema / properties / target / description

Previous value: -"AllEvents, or an event name such as Purchase"New value: +"AllEvents, or the event whose rule to delete, such as Purchase. Event names are in list_supported_values's `events`."

changedInput schema / required

Previous value: -[
-  "site",
-  "target",
-  "idempotency_key"
-]New value: +[
+  "site_id",
+  "idempotency_key",
+  "target"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "rules_left": {
+      "description": "Events that still have a blocking rule after the delete, such as AllEvents or Lead. Empty when the site has no rules left.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "rules_left"
+  ],
+  "type": "object"
+}

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint and idempotentHint, but the description adds substantial value beyond them: the AllEvents fallback cascade, the refusal/no-op when no rule exists, what is returned, and the idempotency-key replay behavior. This is exactly the semantic context annotations cannot express.

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?

The action and scope are front-loaded in the first sentence, and each subsequent sentence contributes cascade or idempotency detail. Slightly long, and the idempotency sentence partly restates the schema, but no sentence is wasted.

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 a destructive 3-parameter tool with an output schema and full annotation coverage, the description covers the mutation semantics, edge case (missing rule), cascade effects, and return content. Nothing an agent needs to call it safely is missing.

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?

Schema coverage is 100%, so the baseline is 3. The description additionally explains that target is either AllEvents or a specific event name and that repeating an idempotency_key deletes only once, adding meaning beyond the schema's field docs.

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 (blocking rule) with precise scope: a single event's rule or the AllEvents rule. An agent can distinguish it from save_blocking_rule and delete_trigger without opening any schema.

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

Usage Guidelines4/5

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

The final sentence gives a clear use case: call it when the user wants blocked events to reach ad platforms again. It doesn't explicitly name save_blocking_rule as the alternative or state when not to call it, so it falls short of a full 5.

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

All PixelFlow tools Inspect

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.