Invoices to Spreadsheets

Create invoice spreadsheet

create_invoice_spreadsheet

Use this when the user wants invoices, bills or receipts put into an Excel spreadsheet. Builds an .xlsx workbook with one row per invoice, one row per line item, a sheet of arithmetic, missing-field and duplicate checks, and totals per currency, and returns a download link that works for 24 hours.

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": {
      "invoices": "<invoices>"
    },
    "name": "create_invoice_spreadsheet"
  }
}

Input Schema

Name	Required	Description	Default
`title`	No	Optional name for the file, e.g. "October supplier invoices".
`invoices`	Yes	Every invoice, one entry each, with values exactly as printed on the document. Use null for anything not printed or not legible; never estimate.

Output Schema

Name	Required	Description
`checks`	Yes
`totals`	Yes
`filename`	Yes
`expires_at`	Yes	When the link stops working and the file is deleted.
`check_count`	Yes	All findings; every one is on the Checks sheet.
`download_url`	Yes	Link to the .xlsx file. Give it to the user unchanged.
`invoice_count`	Yes
`line_item_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The annotations already declare that this is a non-read-only, non-destructive, closed-world write operation. The description adds real behavioral context beyond that: it describes the sheets produced, the row layout, and the 24-hour expiry of the download link, though it does not mention permissions or whether files are overwritten.

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, both of which earn their place: the first gives the trigger condition, and the second describes the output and its lifetime. The trigger is front-loaded and there is no filler.

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?

An output schema exists, so the description need not explain return values; its 24-hour link note is a useful addition. For a complex invoice-ingestion tool, it covers the essential workflow and output shape, with only minor gaps around failure behavior or file naming conflicts.

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?

Schema coverage is 100%, so the schema already documents the title and invoice fields in detail. The description adds only a structural hint that each invoice and each line item becomes a row, which is useful but does not deepen parameter meaning beyond the schema.

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: it builds an .xlsx workbook from invoices, bills, or receipts, with one row per invoice and per line item. This distinguishes it clearly from list_spreadsheet_templates and check_invoices.

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 gives an explicit trigger: use it when the user wants invoices, bills, or receipts put into an Excel spreadsheet. It does not state when not to use it or name an alternative for validation-only tasks, so the guidance is clear but not complete.

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

All Invoices to Spreadsheets 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.

Resources

Need Help?