Skip to main content
Glama

Delete Inbox Automation

aidelly_delete_inbox_automation
DestructiveIdempotent

Delete an inbox automatic reply rule by id. Removes its configuration so the rule no longer handles future triggers; returns the deletion result. Retry-safe: a repeat call with the same idempotency_key returns the original result.

Input Schema

NameRequiredDescriptionDefault
idYes
queryNoOptional query overrides for endpoints with sparse parameter schemas.
brand_idNo
workspace_idNoWorkspace to operate in: the `id` of a workspace returned by aidelly_list_workspaces. Optional for read operations; required when creating content.
idempotency_keyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / idempotency_key / example
      Added value: +"order-123:create-post:v1"
    • addedInput schema / properties / idempotency_key / maxLength
      Added value: +255
    • addedInput schema / properties / idempotency_key / minLength
      Added value: +1
    • addedInput schema / properties / idempotency_key / pattern
      Added value: +"^[\\x21-\\x7E]{1,255}$"
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description goes further by explaining what destruction means concretely (the rule stops firing on future triggers) and by spelling out the retry contract ('a repeat call with the same idempotency_key returns the original result'), which the idempotentHint flag alone does not convey. It stops short of noting permission requirements or behavior when the id does not exist.

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

Conciseness5/5

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

Three short sentences, front-loaded with the action and identifier, then effect, then retry contract. Each sentence earns its place, and the idempotency detail is valuable given there is no output schema.

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

Completeness4/5

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

For a destructive, 5-parameter tool with no output schema, the description covers the action, the effect of deletion, and the idempotent retry behavior. Remaining gaps are minor: no mention of required scopes/permissions or what happens on an unknown id, and brand_id remains undocumented.

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

Parameters3/5

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

Schema description coverage is only 40%: id, brand_id, and idempotency_key have no descriptive text, while workspace_id and query do. The description adds real meaning for idempotency_key (retry-safe semantics) and confirms id is the rule selector, but leaves brand_id and the sparse query override object unexplained, so it only partially compensates for the coverage gap.

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 and resource ('Delete an inbox automatic reply rule') plus the selector ('by id'), which cleanly separates it from create_inbox_automation, update_inbox_automation, and get_inbox_automations. The second sentence clarifies the effect on behavior ('no longer handles future triggers'), removing any ambiguity about what 'delete' means here.

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

Usage Guidelines3/5

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

The description implies its use case (removing a rule by its id) but never states when to delete versus disabling or updating via aidelly_update_inbox_automation, nor any preconditions. Usage is inferable rather than instructed.

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.