Skip to main content
Glama
erp-mafia

Fortnox MCP Server

by erp-mafia

List Fortnox Invoices

fortnox_list_invoices
Read-onlyIdempotent

List Fortnox invoices with pagination and filters by status, customer, date, amount, and sorting to find exactly what you need.

Instructions

List invoices from Fortnox accounting system.

Retrieves a paginated list of invoices with optional filtering by status, customer, date range, or amount. Supports convenience period filters and can fetch all results for large datasets.

Args:

  • limit (number): Max results per page, 1-100 (default: 20)

  • page (number): Page number for pagination (default: 1)

  • filter ('cancelled' | 'fullypaid' | 'unpaid' | 'unpaidoverdue' | 'unbooked'): Filter by invoice status

  • customer_number (string): Filter by customer number

  • from_date (string): Filter invoices from this date (YYYY-MM-DD)

  • to_date (string): Filter invoices to this date (YYYY-MM-DD)

  • period ('today' | 'yesterday' | 'this_week' | 'last_week' | 'this_month' | 'last_month' | 'this_quarter' | 'last_quarter' | 'this_year' | 'last_year'): Convenience date period, overrides from_date/to_date

  • from_final_pay_date (string): Filter by due date from (YYYY-MM-DD)

  • to_final_pay_date (string): Filter by due date to (YYYY-MM-DD)

  • sortby ('customername' | 'customernumber' | 'documentnumber' | 'invoicedate' | 'total'): Field to sort by

  • sortorder ('ascending' | 'descending'): Sort order (default: ascending)

  • fetch_all (boolean): Fetch all results by auto-paginating (max 10,000 results)

  • min_amount (number): Filter invoices >= this amount (client-side)

  • max_amount (number): Filter invoices <= this amount (client-side)

  • response_format ('markdown' | 'json'): Output format

Returns: For JSON: { total, page, limit, count, has_more, total_pages, next_offset?, truncated?, invoices: [...] } For Markdown: Formatted list with pagination info

Examples:

  • List unpaid invoices: filter="unpaid"

  • Last month's invoices: period="last_month"

  • Top invoices by amount: sortby="total", sortorder="descending"

  • All invoices over 10000: fetch_all=true, min_amount=10000

  • Customer invoices this year: customer_number="1001", period="this_year"

Error Handling:

  • Returns "Error: Rate limit exceeded..." if API limit hit

  • Returns truncation info if fetch_all hits safety limits

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination
limitNoMaximum number of results to return (1-100)
filterNoFilter invoices by status
periodNoConvenience date period filter (e.g., 'last_month', 'this_quarter'). Overrides from_date/to_date if provided.
sortbyNoField to sort results by
to_dateNoFilter invoices to this date (YYYY-MM-DD)
fetch_allNoFetch all results by auto-paginating through all pages. WARNING: May take time for large datasets (max 10,000 results).
from_dateNoFilter invoices from this date (YYYY-MM-DD)
sortorderNoSort order for resultsascending
max_amountNoFilter invoices with total <= this amount (client-side filter, applied after fetching)
min_amountNoFilter invoices with total >= this amount (client-side filter, applied after fetching)
customer_numberNoFilter by customer number
response_formatNoOutput format: 'markdown' or 'json'markdown
to_final_pay_dateNoFilter by due date to (YYYY-MM-DD)
from_final_pay_dateNoFilter by due date from (YYYY-MM-DD)
Behavior5/5

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

The description enriches the readOnly/openWorld/idempotent annotations by disclosing auto-pagination limits (max 10,000 results), client-side filtering behavior for min/max_amount, error handling for rate limits, and optional truncation. This is valuable behavioral context beyond the annotations.

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 long but well-structured with clear sections (Args, Returns, Examples, Error Handling). It front-loads the core purpose and keeps each element purposeful, although some details repeat schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 15 parameters and no output schema, the description is comprehensive: it explains return formats for JSON and Markdown, includes pagination details, provides five illustrative examples, and covers error scenarios. This gives the agent sufficient context to use the tool correctly.

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?

The schema covers all 15 parameters with 100% documentation, but the description adds extra semantic value through an organized Args list with defaults, explicit override behavior (period overrides from_date/to_date), and practical examples tying parameters to use cases.

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 clearly states 'List invoices from Fortnox accounting system' and explains it provides a paginated list with filtering options. This distinguishes it from related tools like fortnox_get_invoice (single invoice) and fortnox_invoice_summary (summaries). The scope is specific and actionable.

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?

The description provides detailed use cases through examples (unpaid invoices, period filters, sorting, fetch_all) and clarifies when to use filters. However, it does not explicitly contrast with alternative tools like fortnox_get_invoice, so the guidance is implied rather than explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/erp-mafia/fortnox-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server