Skip to main content
Glama

receipt-scanner

Add an expense

expense_add

Record one expense and return its id, its net/VAT split and its billable flag. The response states every default that was applied, so the caller can see what was assumed rather than having to guess.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vatNoAlias for vat_rate
dateNoISO date YYYY-MM-DD, default today
noteNo
amountYesGross amount on the receipt, in major units, e.g. 12.34. It is stored as integer minor units in the expense's own currency, so nothing is lost to floating point.
projectNoProject or client this belongs to
billableNoRebillable to the client. Default: true when project is given (a receipt booked to a client project is normally rebilled), false otherwise. Pass it explicitly to override.
categoryNoCategory, e.g. software, travel, office. Omit and the stored category rules are matched against the merchant to fill it in
currencyNoISO code. Defaults to your expense_settings default_currency, else the shared business profile's default_currency, else EUR
merchantNoWho was paid, e.g. Adobe
tax_rateNoAlias for vat_rate
vat_rateNoVAT percent already included in amount; it splits the gross into net and VAT. Omit to use the expense_settings default, or get no split at all when none is set
receipt_pathNoAbsolute path to the receipt file; it is checked and hashed

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations are minimal (readOnlyHint false, idempotentHint false, etc.), so the description adds useful behavioral context by saying a new expense is recorded and that the response reports every applied default. This helps the caller understand the operation's side effects, though it does not cover reversibility, permissions, or duplicate handling.

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?

Two sentences, front-loaded with the primary action, and every sentence earns its place. The description is compact while still conveying the outcome and the transparency guarantee about applied defaults.

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?

Given a rich 12-parameter schema and the absence of an output schema, the description adequately covers the return value and the key caveat that defaults will be reported. It does not address when to choose this over sibling tools, but the schema covers parameter-level detail and the core create behavior is clear.

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?

The schema already provides detailed descriptions for 92% of parameters, including defaults and aliases. The description adds only a broad hint about the net/VAT split and billable flag, which maps to vat_rate and billable but does not materially extend the parameter semantics covered by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Record one expense') and the resource, with useful result details (id, net/VAT split, billable flag). It is distinct from siblings like expense_update or expense_list, but it does not explicitly name or contrast itself with them, so it falls short of full differentiation.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives such as expense_update or mileage_add. The description states what the tool does but does not mention prerequisites, exclusions, or conditions for choosing a different sibling tool.

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.