Skip to main content
Glama
Sign In

stub

by africa.stub.api
OverviewDiscussionsAdmin

Delete expense

delete_expense
DestructiveIdempotent

Delete one expense or many to the bin (soft-delete, restorable). Send id for one expense, which returns {error}. Or send ids (up to 250) to delete many in one call, which returns {error, deleted: [id ...], errors: [{id, message} ...]}. That is partial success: ids this business does not own, already deleted, or unknown are skipped and listed in errors, and error is true only when nothing was deleted. The ledger recomputes, so linked bills and transactions stay consistent. Confirm with the user before deleting.

Input Schema

NameRequiredDescriptionDefault
idNoOne expense id to delete.
idsNoUp to 250 expense ids to delete in one call. Partial success: ids this business does not own, already deleted, or unknown are skipped and listed in errors.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / id / description
      Added value: +"One expense id to delete."
    • addedInput schema / properties / ids
      Added value: +{
+  "description": "Up to 250 expense ids to delete in one call. Partial success: ids this business does not own, already deleted, or unknown are skipped and listed in errors.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 250,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "id"
-]New value: +[]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag destructive=true and idempotent=true, and the description adds context annotations cannot carry: deletions are soft and restorable, the ledger recomputes so linked bills and transactions stay consistent, and partial-success semantics are spelled out precisely ('error is true only when nothing was deleted').

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?

Front-loaded with the delete semantics, then mode selection, then result interpretation, then a safety prompt. Dense but every sentence carries decision-relevant information; 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?

There is no output schema, and the description compensates by documenting both return shapes and how to read partial failure. Confirmation guidance and ledger-consistency behavior round out what an agent needs for a destructive, restorable mutation.

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 still adds value by pairing each parameter with its distinct return shape ({error} for id vs {error, deleted, errors} for ids) and clarifying the skip conditions for ids.

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 the specific verb and resource ('Delete one expense or many') plus the crucial scope qualifier that this is a soft-delete to the bin and restorable, which distinguishes it from any hard-delete interpretation and from save_expense/list_expenses.

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?

Explicitly routes between the two call modes ('Send `id` for one expense... Or send `ids` (up to 250)') and adds a procedural guardrail ('Confirm with the user before deleting'). It does not name restore_deleted as the undo path, only implies it with 'restorable', so a sibling pointer is the one missing piece.

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

All stub toolsInspect
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.

Resources