Skip to main content
Glama

Run a report

books_report
Read-onlyIdempotent

A report in the base currency. profit_and_loss and tax cover from-to (default: this fiscal year so far); balance_sheet and trial_balance are as of to (default today); general_ledger lists each account's lines from-to with running balances (one account, or all, paged); oss is a quarter's sales to consumers in other EU countries for the One Stop Shop return, per country and VAT rate in euros (quarter, default the last one ended; no books needed); reconciliation holds each bank account's books against the closing balance its latest statement on or before to stated: reconciled, to_match (statement lines and entries still to pair explain the difference) or off (unexplained). Like Xero's: profit_and_loss with compare adds columns for earlier months, quarters or years; cash_summary shows the money accounts at the start and end of from-to and what came in and went out, by account; executive_summary (default this month so far) gives cash, profit, margins, what is owed both ways, debtor and creditor days and invoices issued, against the same days a month before; budget_variance holds a budget (books_save_budget) against the actual figures for the months from-to touches; vat_return gives from-to by the boxes of the VAT return the business files itself, Germany's advance return by Kennzahl or the UK's nine boxes (country, default the business's), with what the books can't tell yet. Like Xero's short-term cash flow, cash_forecast projects the money accounts days ahead (default 30, up to 180) from open invoices and bills on their due, expected or planned dates and what repeating templates will make, by day and week, with the lowest point and the overdue invoices and bills it leaves out until they have a date to come (each with the id that invoices_set_expected_date or purchasing_set_planned_date takes). snapshot is the year so far (default) against the same days a year before: profit, margins, income and expenses by month, the largest costs, the balance sheet, cash, and the average days from an invoice's or a bill's date to the payment that settled it, for those paid in the period. euer is the cash-basis profit for from-to (default: the calendar year so far), Germany's Einnahmenüberschussrechnung: income and costs by account on the day the money moved (a payment on an invoice or bill is spread over what the document was for), VAT received and paid as lines of their own, depreciation counted, and under not_counted what moved money without being income or a cost (an asset bought, a loan, the owner's own money). To show a person, put it in a view (view_show). Free.

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": {
      "report": "<report>"
    },
    "name": "books_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoYYYY-MM-DD
daysNoFor cash_forecast: how many days ahead.
fromNoYYYY-MM-DD
limitNo
budgetNoFor budget_variance: the budget's name (books_list_budgets).
offsetNo
reportYes
accountNoAn account code from the chart, e.g. "6600".
compareNoFor profit_and_loss: add columns for the same days `periods` months, quarters or years before.
countryNoFor vat_return: whose form. Default the business's country.
periodsNoWith compare; default 1.
quarterNoFor oss: like 2026-Q3.
trackingNoFor profit_and_loss: only lines with these options, e.g. {"Department": "Service"}.
by_trackingNoFor profit_and_loss: a tracking category to split by, one column per option and one for what is not tracked.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / report / enum
      Previous value: -[
      -  "profit_and_loss",
      -  "balance_sheet",
      -  "trial_balance",
      -  "general_ledger",
      -  "tax",
      -  "oss",
      -  "reconciliation",
      -  "cash_summary",
      -  "executive_summary",
      -  "budget_variance",
      -  "vat_return",
      -  "cash_forecast",
      -  "snapshot"
      -]New value: +[
      +  "profit_and_loss",
      +  "balance_sheet",
      +  "trial_balance",
      +  "general_ledger",
      +  "tax",
      +  "oss",
      +  "reconciliation",
      +  "cash_summary",
      +  "executive_summary",
      +  "budget_variance",
      +  "vat_return",
      +  "cash_forecast",
      +  "snapshot",
      +  "euer"
      +]
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the description's job is to add semantics — and it does: reconciliation's three outcomes (reconciled, to_match, off), euer's not_counted bucket, and cash_forecast's exclusion of undated overdue invoices with the ids needed to fix them. Gaps remain around pagination behavior for general_ledger ('paged' with no detail) and the limit/offset contract.

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

Conciseness3/5

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

Nearly every clause carries real information for a 14-mode tool, so the length is defensible, and the base-currency scope plus the from/to semantics are front-loaded. However, the content is delivered as a comma-spliced wall of text with no line breaks or grouping by report, which makes scanning for a specific mode slow and error-prone.

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?

For a tool with 14 parameters, 14 enum modes, a nested tracking object and no output schema, the description covers what almost every mode returns and what each parameter means in context. The notable omissions are the shape of the returned data and pagination semantics (limit/offset), which matter for the paged general_ledger mode.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 79% schema coverage, the description materially extends the schema: it states per-report defaults for from/to (fiscal year so far, today, calendar year so far, last completed quarter), the days cap of 180, country defaulting to the business's, quarter format expectations, and what account, compare/periods, tracking and by_tracking do. Only limit and offset are left unexplained in both places.

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?

Opens with a concrete verb+resource ('A report in the base currency') and then defines all 14 report modes individually (profit_and_loss, balance_sheet, oss, reconciliation, euer, etc.) with their scope and defaults, so an agent can tell exactly what each mode produces. It differentiates from a couple of siblings (books_save_budget for budgets, view_show for presenting), but says nothing about how it relates to plausible alternatives like books_export or books_get.

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

Usage Guidelines3/5

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

Usage is conveyed implicitly through the per-report semantics and defaults ('balance_sheet and trial_balance are as of to', 'oss ... no books needed'), which effectively tells the agent which mode to pick for a given question. There is no explicit when-to-use vs. when-not guidance, no statement of prerequisites or permissions, and no routing to sibling tools other than view_show.

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