Skip to main content
Glama
henfrydls

actual-budget-mcp

by henfrydls
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

delete_category

Destructive

Delete a budget category irreversibly. First call previews; confirm with exact category name to proceed, optionally transferring transactions to another category.

Instructions

Delete a budget category. Destructive and irreversible: the first call only previews, and deleting requires confirm: true plus confirm_name set to the category's exact name. Deleting a category also destroys its budget and rollover history; pass transfer_to to keep its transactions categorised.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoMust be true to delete. Without it, the tool only previews.
categoryYesCategory name or ID to delete
transfer_toNoCategory name or ID to transfer existing transactions to
confirm_nameNoThe category's exact name, echoed back as a safeguard.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.3
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Must be true to delete. Without it, the tool only previews.",
+  "type": "boolean"
+}
    • addedInput schema / properties / confirm_name
      Added value: +{
+  "description": "The category's exact name, echoed back as a safeguard.",
+  "type": "string"
+}
  2. First observedv0.6.1

TDQS

A4.7/5.0
Behavior5/5

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

Even though the annotations already flag destructiveHint=true, the description adds rich operational detail: irreversible deletion, preview-first flow, exact-name confirmation, destruction of budget and rollover history, and the transfer_to safety valve. This goes well beyond the annotation's simple flag.

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 text is three concise sentences: the first states the core action, the second details the confirmation requirement and preview-versus-delete behavior, and the third states side effects and the transfer option. Every sentence delivers essential information with no filler.

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 high-stakes destructive tool with no output schema, the description fully covers the invocation flow, required confirmation inputs, irreversible side effects, and optional transfer behavior. It leaves no ambiguity about how to call it safely and what to pass.

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 schema covers 100% of parameters with individual descriptions, but the tool description adds important relationships beyond the schema, explaining that confirm and confirm_name gate the actual deletion and that transfer_to preserves transactions. This adds behavioral meaning not obvious from isolated parameter descriptions.

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 opens with 'Delete a budget category,' clearly identifying the action, resource, and scope. This distinguishes it from sibling tools like delete_category_group, update_category, and delete_transaction.

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 description provides clear context for use: it previews first, then requires confirm and confirm_name, and offers transfer_to as an option. It indirectly covers alternatives by clarifying what transfer_to is for, but it doesn't explicitly point to sibling tools or state when not to use it.

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

Deploy Server

Other Tools