ExpenseBot

omit_expenses

Idempotent

Omit exact recorded expenses from reports, insights and exports, or restore them (leave out, exclude, don't count). First search_expenses for full expenseId values. A grounded preview is automatic with confirm omitted/false: show exact rows (date, merchant, amount), count and skips, ask once, then repeat identical operationId, action and expenseIds with confirm:true. Premature confirmation returns preview. Omit is reversible and keeps the spreadsheet row; never deletes. Rows on a submitted report are skipped and stay on it. Act only on rows the user chose; never decide rows are duplicates or personal. Recategorize: correct_expenses. Result gives applied/skipped/conflicted/failed counts and Undo. Over 100 rows: https://www.expensebot.ai/review-expenses?source=mcp.

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": {
      "operationId": "<operationId>"
    },
    "name": "omit_expenses"
  }
}

Input Schema

Name	Required	Description
`undo`	No	Undo within the Undo window.
`action`	No	omit hides rows from reports, insights and exports; restore puts omitted rows back.
`reason`	No	The user's own short reason, shown in the Omitted view. Never invent one.
`status`	No	Read status by operationId.
`confirm`	No	Omit/false previews only; true only after the user approves the preview.
`expenseIds`	No	Full expenseId (Column Q Receipt ID) values from search_expenses; never dates, rows or merchants.
`operationId`	Yes	Idempotency key; generate once and reuse unchanged to confirm.

Output Schema

Name	Required	Description
`undo`	No
`counts`	No
`status`	Yes
`preview`	No
`skipped`	No	By reason: ALREADY_OMITTED, ALREADY_ACTIVE, ON_REPORT, NOT_FOUND, SPLIT_OR_SHARED_ID, ENTITLEMENT.
`success`	Yes
`finalAnswer`	No
`operationId`	No
`reviewExpensesUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare non-destructive, idempotent and open-world traits, but the description adds substantive context beyond them: the preview/confirm protocol, that rows on a submitted report are skipped and remain on that report, that the spreadsheet row is kept and nothing is deleted, and the applied/skipped/conflicted/failed result shape with an Undo path. The only gap is that it does not state permission or authentication requirements for the operation.

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

Conciseness4/5

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

The confirmation protocol and the reversibility guarantee are front-loaded, and nearly every sentence carries operative information. The parenthetical synonyms '(leave out, exclude, don't count)' are padding aimed at retrieval rather than comprehension, and the appended review URL reads as a slight add-on.

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?

An output schema exists, so the description need not enumerate return fields, yet it still summarizes the applied/skipped/conflicted/failed counts and the Undo affordance. Together with the batching limit and the escalation path for larger sets, an agent has everything needed to invoke this tool correctly in one 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?

Coverage is 100%, so the schema already documents each field, and the description correctly does not restate them. It adds genuine procedural meaning by tying operationId, action and expenseIds together into the 'repeat identical values with confirm:true' contract, which the schema alone does not convey. It adds little on 'reason' or 'undo' beyond what the schema says, so a 4 rather than a 5.

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 the specific verb and resource ('Omit exact recorded expenses ... or restore them') and immediately bounds the scope to reports, insights and exports. It also names the sibling it should not be confused with ('Recategorize: correct_expenses'), so an agent can distinguish it from update_expense or correct_expenses without opening either schema.

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?

It prescribes the prerequisite ('First search_expenses for full expenseId values'), the exact two-step confirmation sequence, the behavior on premature confirmation, and the external alternative for volumes over 100 rows. It also states an explicit prohibition ('never decide rows are duplicates or personal'), which is the when-not guidance most tools omit.

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

All ExpenseBot tools Inspect

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.