Skip to main content
Glama

InvoiceParser Pro

Delete an automation rule

delete_automation_rule
DestructiveIdempotent

Apply only the exact change returned by preview_delete_automation_rule, after the user confirms that preview. Accepts its confirmation_token only; changed or expired records require a new preview. Prepare permanently removing an exact automation configuration rule. Already processed invoice records remain. Requires approval-scope confirmation.

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": {
      "input": "<input>"
    },
    "name": "delete_automation_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds real value beyond that: the token is single-use and expires, and already-processed invoice records are left intact, which clarifies blast radius. It also notes approval-scope confirmation is needed, though it does not explain what that scope entails or what an auth failure looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical workflow constraint is front-loaded, which is good, but the passage is repetitive ('after the user confirms that preview' and 'Requires approval-scope confirmation' say overlapping things) and the mid-string 'Prepare permanently removing an exact automation configuration rule' is awkward filler that interrupts the flow.

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?

There is no output schema, so the description must carry the workflow, preconditions, and side effects — and it does: preview-then-confirm discipline, token lifetime, non-destructive impact on processed invoice records, and the approval requirement. For a single-parameter destructive delete, nothing essential 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?

The single confirmation_token parameter already carries an inline schema description, and the tool description reinforces it with the lifecycle rule: the token must come from this operation's preview, is consumed once, and cannot be reused after changes or expiry. That is meaningful semantics beyond what the schema states, though no format/length hints are repeated (min 20 chars).

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?

The opening sentence names the specific action and its required source: applying the exact change from preview_delete_automation_rule. Combined with 'permanently removing an exact automation configuration rule', an agent can distinguish this from preview_delete_automation_rule and update_automation_rule. The second sentence ('Prepare permanently removing...') is grammatically muddled and adds little.

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?

Explicitly states the precondition (only after the preview returned by preview_delete_automation_rule and after the user confirms it), the accepted input (its confirmation_token only), and the exclusion (changed or expired records require a new preview). An agent has no ambiguity about when to call this versus the preview sibling.

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.

Resources