Receipts you've read to Excel, CSV, Xero or QuickBooks files, VAT split per rate. Free.
Scored across 3 tools
Each tool targets a different stage: building an export file, fetching an exchange rate, and redirecting to an external scanner. The scanner and spreadsheet builder both involve receipts, so a user might briefly wonder whether building handles unread photos, but the descriptions clarify the distinction.
All names use snake_case and begin with a clear verb (build, convert, scan). The only minor deviation is the longer 'scan_receipts_on_website' structure, but it remains readable and consistent in style.
Three tools is a tight, focused set for a receipt-export utility. It is slightly thin because one tool is just a link to an external scanner rather than a native operation, but the scope is clear and no tool feels redundant.
The surface covers currency conversion and export generation but lacks a native receipt-reading or upload operation—the scanner is an external link an agent cannot actually use to parse files. There is also no way to inspect or list previously processed receipts, leaving a notable gap in the workflow.
Turn receipts you have read into an Excel (.xlsx), CSV, Xero or QuickBooks import file, with VAT split into one column per rate. Returns totals per currency and VAT rate, warnings where net + VAT doesn't match the total, and a download link valid for 24 hours. Up to 200 receipts per call.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | xlsx (Excel), csv, xero (bank statement CSV) or quickbooks (bank upload CSV) | xlsx |
| csvStyle | No | For csv only: standard = comma-separated with dot decimals; european = semicolons with comma decimals (Excel in most EU countries) | standard |
| receipts | Yes | ||
| totalsCurrency | No | Also convert every total to this currency at the ECB rate of the receipt date, e.g. EUR | |
| includeLineItems | No | xlsx: add a Line items sheet; csv: one row per line item |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-destructive, non-idempotent, closed-world operation but say nothing concrete. The description fills that in well: it discloses the return payload (totals per currency and VAT rate, mismatch warnings), the output medium (download link valid 24 hours), and a hard per-call limit of 200 receipts. It does not explain why it is non-idempotent (presumably a fresh link per call) or whether repeated calls with identical input produce duplicate artifacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the transformation and output formats, then the return payload and limits. Every clause carries information an agent needs; nothing is repeated from the schema verbatim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 describing the return values (totals, warnings, 24-hour download link). For a 5-parameter, single-required-array tool with 80% schema coverage, the description supplies everything an agent needs to build a correct call and know what comes back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the baseline is 3. The description adds output-level meaning for format (which import file you get) and the VAT column split, but adds nothing on csvStyle, includeLineItems or totalsCurrency beyond what the schema already documents, so it does not meaningfully improve on the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete verb and output artifact ("Turn receipts ... into an Excel (.xlsx), CSV, Xero or QuickBooks import file") and the phrase "receipts you have read" implicitly separates it from scan_receipts_on_website, which produces the readings this consumes. It also states the distinguishing internal logic (VAT split into one column per rate), so an agent can tell what it gets without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by "receipts you have read" — the tool is downstream of scanning — and the 200-receipt cap gives a practical bound. But no explicit when-to-use/when-not guidance is given and neither sibling (scan_receipts_on_website, convert_currency) is named, even though totalsCurrency overlaps with convert_currency and could confuse an agent choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The European Central Bank reference rate for a currency on a date (the last published rate on or before it), and the converted amount.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| date | Yes | YYYY-MM-DD, usually the receipt date | |
| from | Yes | ||
| amount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower, and the description adds genuinely useful non-obvious behavior: it returns the last published rate on or before the given date, which explains weekend/holiday handling. It does not disclose what happens with unsupported currency codes, dates before the rate series begins, or numeric precision of the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with zero filler, and the most important detail (rate lookup semantics) is front-loaded. Its only structural weakness is that it is a fragment describing outputs rather than an action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly carries the return-value burden by naming both the reference rate and the converted amount. For a four-parameter financial lookup it still leaves gaps: supported currency universe, error conditions, and result precision are unstated, and there is no usage context despite sitting alongside receipt tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only 'date' is documented), so the description must compensate. It does clarify the one non-obvious parameter by defining date as the as-of point for the rate with a last-published fallback, and 'for a currency' plus the 3-letter pattern make from/to reasonably self-evident, but amount handling (rounding, precision of the converted value) is never addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (European Central Bank reference rate) and signals a converted amount, but it is written as a noun phrase with no verb, so the action ('converts an amount from one currency to another') is only inferable from the tool name and title. Nothing distinguishes it from the receipt-oriented siblings build_receipt_spreadsheet and scan_receipts_on_website.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives or when not to call it. The receipt-date hint in the schema ('usually the receipt date') weakly implies the receipt-processing context, but the description itself offers nothing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link to InvoiceSnap's own scanner, for when receipt photos are hard to read or there are many: it reads photos and PDFs (up to 50 at once) and exports the same files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful operational detail (photos and PDFs, up to 50 at once), but 'exports the same files' is ambiguous about what the agent actually receives and whether the external site is involved in the flow, which sits awkwardly against openWorldHint=false. The added context is real but leaves the return behavior underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the purpose and then layers the trigger condition and limits. Every clause carries information except the trailing 'and exports the same files,' which is vague enough to be close to filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers what it is, when to use it, and what it handles. The remaining gap is the return payload — whether the agent gets a URL, a handoff instruction, or something else — which matters because there is no output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The stated file-type and batch-size limits describe the tool's capacity, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('InvoiceSnap's own scanner') and makes clear this tool hands back a link rather than performing OCR itself, which is the key distinction an agent needs. It does not name the siblings (build_receipt_spreadsheet, convert_currency), but their purposes are far enough apart that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger condition: use it 'when receipt photos are hard to read or there are many.' That is clear routing guidance. It stops short of stating when not to use it (e.g. single clean receipt where an in-agent flow would suffice), so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
build_receipt_spreadsheetconvert_currencyscan_receipts_on_websiteTurn receipts and invoices (photos, PDFs or a zip) into checked numbers: vendor, date, currency, line items, tax and total, each field marked ok, check or missing. Doubtful documents come back flagged with reasons instead of guessed; repeated receipts are marked as duplicates. Exports CSV, line-item CSV, QuickBooks CSV or a renamed file pack. Free daily quota, no API key. Files deleted after 24 hours, never used for training.
Search, summarise and export your invoices and receipts collected from email and supplier portals.
Receipt tracker with no friction: receipts arrive by email and file themselves
Log business expenses with the VAT split and mileage, total them, export CSV or XLSX.
Add one secure layer between your agents and this server.
