Skip to main content
Glama

Create expense

create_expense

Register an expense (gasto) from data. Requires description, subtotal and total. Always pass the supplier (proveedor) as supplier_name/supplier_nif or supplier_id, an expense without a supplier cannot appear in Modelo 347/349. OCR ticket scanning stays in the web app. Returns the new expense's id, description and total. To attach the receipt image or PDF afterwards, use attach_expense_receipt.

Input Schema

NameRequiredDescriptionDefault
notesNo
totalYes
categoryNoexpense category slug (see web app)
subtotalYes
tax_rateNo
tax_linesNoOnly for a receipt carrying MORE THAN ONE VAT rate (e.g. a Correos ticket: 21% on postage, exempt on the stamp). One entry per rate. When given, subtotal/tax_amount/tax_rate/total are derived from it, do not compute them yourself. Leave it out for the normal single-rate receipt.
tax_amountNo
descriptionYes
supplier_idNoexisting supplier id from list_suppliers
invoice_dateNoYYYY-MM-DD, defaults to today
supplier_nifNosupplier NIF/CIF/VAT as printed on the document
is_deductibleNofalse keeps the expense out of the deductible totals entirely
supplier_nameNosupplier (proveedor) name, matched against existing suppliers by NIF or name, created if new
invoice_numberNo
supplier_countryNosupplier country, ISO-2 (ES, FR, DE...). Drives Modelo 349 intra-EU acquisitions
deductible_percentNoporcentaje imputable: share of this expense (0-100) the user allocates to the business, e.g. a shared car or a home office. Enter the FULL receipt amounts in subtotal/tax_amount/total and the percentage here, not pre-reduced amounts; the IVA and income-tax modelos count only that share. Default 100. Use only a percentage the user states, contix never proposes one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, it discloses the critical behavioral rule that a supplier must be supplied or the expense cannot appear in Modelo 347/349. It also explains that OCR is out of scope, defines the return fields, and points to the follow-up tool for receipt attachment.

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 is front-loaded with the core action and required fields, then adds supplier compliance, OCR scope, return values, and the follow-up tool. Every sentence contributes useful information without waste.

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 16 parameters, minimal annotations, and no output schema, it covers the critical requirements, supplier compliance, return values, and receipt-attachment workflow well. Some optional parameter semantics remain reliant on the schema, but the description is largely complete for correct invocation.

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 description adds important meaning for the supplier fields by making them effectively mandatory and explaining why. However, with only 56% schema description coverage, it leaves several parameters such as notes, category, tax_rate, tax_amount, and invoice_number without added semantic guidance.

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: register an expense (gasto) from data. It clearly distinguishes creation from OCR ticket scanning and from attaching a receipt afterward, so an agent can identify the correct operation.

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?

It explicitly says OCR ticket scanning stays in the web app and directs receipt attachment to attach_expense_receipt. It does not explicitly mention update_expense or list_expenses, but the create-vs-attach boundary is clear.

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.

Resources