Skip to main content
Glama
Sign In
Wave MCP

Wave MCP

by agustinsacco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Run a financial report

wave_run_report
Read-onlyIdempotent

Generate Wave financial reports—profit and loss, balance sheet, cash flow, trial balance, and more—from an imported ledger or live API, with paginated rows and full totals.

Instructions

Financial reports computed by this server (Wave's API has no report endpoint). Rows are paginated with limit/offset; totals always cover every row. From the imported ledger (wave_import_ledger; any period, default year to date; balance-sheet style reports as of endDate): profit_and_loss, balance_sheet, cash_flow, trial_balance, account_balances, account_transactions/general_ledger (filter with account or accountId), sales_tax (sales and purchases), aged_payables, purchases_by_vendor. Without a ledger, profit_and_loss, balance_sheet, trial_balance and account_balances fall back to current account balances from the API (as of now only), and sales_tax to invoices. Live from invoices (invoice date range): income_by_customer, sales_by_product, invoice_summary; as of today: aged_receivables; customer_statement needs customerId. Not possible: tax_line, payroll_wage_tax, payroll_benefits_deductions.

Input Schema

NameRequiredDescriptionDefault
limitNoRows to return
offsetNoRows to skip; use nextOffset
reportYes
sourceNoauto: imported ledger when available for this report, else the live APIauto
accountNoaccount_transactions: account name (exact, else contains)
endDateNoPeriod end; also the as-of date for balance_sheet, trial_balance, account_balances, aged_payables
accountIdNoaccount_transactions: Wave account ID
startDateNoDate, YYYY-MM-DD
businessIdNoBusiness ID; defaults to the one wave_get_context reports
customerIdNoRequired for customer_statement; filters invoice-based reports
fiscalYearStartNobalance_sheet: fiscal year start MM-DD, splits retained earnings from current-year profit01-01
outstandingOnlyNocustomer_statement: only invoices with an amount due
includeZeroBalancesNoaccount_balances: include accounts with a zero balance
includeArchivedAccountsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses server-side computation, lack of a Wave report endpoint, limit/offset pagination with totals covering all rows, source fallbacks, as-of date semantics, and unavailable reports. These are meaningful behavioral constraints not present in annotation or schema fields.

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

Conciseness4/5

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

The description is dense and front-loaded, covering purpose, pagination, source rules, report availability, and unsupported reports without filler. The semicolon-heavy single paragraph could be more scannable, but the length is justified by 18 report types and 14 parameters.

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 complex report tool with no output schema, it explains data sources, report availability, date semantics, pagination, and unsupported requests. It does not describe response fields per report, but given the breadth that is a reasonable gap rather than a blocking omission.

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

Parameters4/5

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

Schema coverage is high at 86%, so the baseline is 3; the description still adds report-specific meaning such as account/accountId for account_transactions, customerId for customer_statement, endDate as the as-of date for balance-style reports, and source/report availability. It does not explain every parameter, but it substantially supplements 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 opening sentence states this tool computes financial reports server-side because Wave's API has no report endpoint, and it enumerates the supported report types. That is a specific verb/resource plus scope, distinguishing it from sibling CRUD and data-source tools such as wave_import_ledger.

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 maps each report family to its source (imported ledger vs live invoices/API), names wave_import_ledger, explains fallback behavior when no ledger exists, and flags unsupported reports. It stops short of explicit 'use this instead of X' guidance for every alternative, but the conditions are clear.

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

Deploy Server

Other Tools