Kema Invoice

Get revenue summary

get_revenue_summary

Read-only

Aggregate revenue figures: collected in the period (by payment date), current outstanding and overdue (point-in-time), documents issued in the period, draft count, and net credit-note effect. Defaults to the current month.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`to`	No	Period end (inclusive), YYYY-MM-DD. Defaults to today.
`from`	No	Period start, YYYY-MM-DD. Defaults to the 1st of the current month.

Output Schema

TableJSON Schema

Name	Required	Description
`period`	Yes	Period the collected/issued figures cover.
`overdue`	Yes	Amount currently due on Overdue invoices (point-in-time).
`collected`	Yes	Gross total of invoices paid within the period (by payment date).
`draft_count`	Yes	Current number of drafts.
`outstanding`	Yes	Amount currently due on Sent invoices (point-in-time).
`currency_note`	Yes	Caveat about amounts being summed across currencies.
`invoice_count`	Yes	Documents issued within the period, drafts excluded.
`overdue_count`	Yes	Number of Overdue invoices.
`collected_count`	Yes	Number of invoices paid within the period.
`credit_note_total`	Yes	Net effect of credit notes issued within the period (negative or zero).
`outstanding_count`	Yes	Number of Sent invoices.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 7, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "collected": {
+      "description": "Gross total of invoices paid within the period (by payment date).",
+      "type": "number"
+    },
+    "collected_count": {
+      "description": "Number of invoices paid within the period.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "credit_note_total": {
+      "description": "Net effect of credit notes issued within the period (negative or zero).",
+      "type": "number"
+    },
+    "currency_note": {
+      "description": "Caveat about amounts being summed across currencies.",
+      "type": "string"
+    },
+    "draft_count": {
+      "description": "Current number of drafts.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "invoice_count": {
+      "description": "Documents issued within the period, drafts excluded.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "outstanding": {
+      "description": "Amount currently due on Sent invoices (point-in-time).",
+      "type": "number"
+    },
+    "outstanding_count": {
+      "description": "Number of Sent invoices.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "overdue": {
+      "description": "Amount currently due on Overdue invoices (point-in-time).",
+      "type": "number"
+    },
+    "overdue_count": {
+      "description": "Number of Overdue invoices.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "period": {
+      "additionalProperties": false,
+      "description": "Period the collected/issued figures cover.",
+      "properties": {
+        "from": {
+          "description": "Period start, YYYY-MM-DD.",
+          "type": "string"
+        },
+        "to": {
+          "description": "Period end (inclusive), YYYY-MM-DD.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "from",
+        "to"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "period",
+    "collected",
+    "collected_count",
+    "outstanding",
+    "outstanding_count",
+    "overdue",
+    "overdue_count",
+    "invoice_count",
+    "draft_count",
+    "credit_note_total",
+    "currency_note"
+  ],
+  "type": "object"
+}

First observedSep 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The readOnlyHint annotation already indicates the operation is safe, so the bar is lower. The description adds useful behavioral details beyond the annotation, such as the period applying to payment dates for collected figures and point-in-time evaluation for outstanding/overdue, and the default to the current month. No contradictions with 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 compact, forming two sentences with a colon-delimited list of metrics. It is efficient and avoids fluff, though the first sentence is dense with multiple comma-separated items, making it slightly harder to parse quickly than a more structured list.

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?

With an output schema present, the description does not need to detail return values. It covers the primary context: aggregate figures, the metrics included, and the default time period. It does not mention potential edge cases (e.g., empty periods, timezone handling), but these are not critical for basic usage.

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 input schema covers both parameters with descriptions (period start/end, inclusive, defaults). The tool description adds context about how these parameters affect the different metrics (e.g., collected by payment date, outstanding point-in-time), which slightly enriches the parameter semantics 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 clearly states the tool aggregates revenue figures and enumerates the specific metrics (collected, outstanding, overdue, documents issued, draft count, net credit-note effect). This distinguishes it from sibling tools like list_invoices or get_invoice, which return raw records rather than summaries.

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 implies when to use the tool (for summary-level revenue metrics over a period) but does not explicitly mention alternatives or when not to use it. The context is clear enough from the aggregate nature and the default period, but it lacks explicit disambiguation from similar reporting tools.

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

All Kema Invoice 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.