Skip to main content
Glama
PhononX

Carbon Voice

by PhononX

delete_action_item

Destructive

Permanently remove a mistakenly created action item so it no longer exists in Carbon Voice. Use when an item is spurious and should be deleted, not completed.

Instructions

Permanently delete an action item. USE WHEN: The item was created in error and should not exist at all. USE INSTEAD: set_action_item_status with done to complete an item — that keeps the record. Deleting cannot be undone, so prefer it only when the item is genuinely spurious. FIRST: id comes from list_my_action_items (field results[].id) — call it first if you don't have one. EXAMPLE: {"id":"ai-abc"} RETURNS: Deletion confirmation for the removed item.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.10.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark destructiveHint: true, and the description adds meaningful context beyond that: deletions are permanent ('cannot be undone') and the tool returns a deletion confirmation. This gives the agent a fuller behavioral model than the annotation alone.

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?

The description uses a labeled structure (USE WHEN, USE INSTEAD, FIRST, EXAMPLE, RETURNS) that front-loads the key decision and keeps each section purposeful. Every sentence earns its place without excess.

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 simple one-parameter destructive tool with annotations already covering the danger profile, the description covers the usage context, filter condition, id origin, example, and return value. Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is 0% (the id parameter has no description), but the description fully compensates by explaining where the id comes from (list_my_action_items, field results[].id), instructing to call that first if needed, and providing a concrete example. No gap remains for the single parameter.

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?

The description states a specific verb and resource ('Permanently delete an action item') and immediately clarifies scope ('should not exist at all'), distinguishing it from the related set_action_item_status sibling. An agent can tell exactly what this tool does and how it differs from completing an item.

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?

Contains explicit 'USE WHEN' and 'USE INSTEAD' guidance, naming the alternative tool (set_action_item_status with `done`) and the condition that selects it. It also warns to prefer deletion only for spurious items, leaving no inference required.

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