UseHourly

List invoices

list_invoices

Read-onlyIdempotent

Invoice history (newest 200 at most), each with the currency it was issued in. Filter by text, client, paid status or issue-date range. unpaid_totals has one figure per currency; unpaid_total is only set when every match is in one currency.

Input Schema

Name	Required	Description	Default
`sort`	No	newest/oldest by issue date, highest/lowest by total	newest
`query`	No	Matches number, client, notes, project names and entry notes
`client`	No	Only this client: id or exact name
`status`	No	Filter by whether the invoice has been paid	all
`issued_to`	No	Only invoices issued on or before this date
`issued_from`	No	Only invoices issued on or after this date

Output Schema

Name	Required	Description
`count`	Yes
`invoices`	Yes
`unpaid_total`	Yes	Still unpaid across the matches, in their currency; null when the matches use more than one currency
`unpaid_totals`	Yes	Still unpaid per currency code, e.g. { USD: 150 }

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 20, 2026

changedOutput schema / properties / unpaid_total / description

Previous value: -"Dollars still unpaid across the matches"New value: +"Still unpaid across the matches, in their currency; null when the matches use more than one currency"

changedOutput schema / properties / unpaid_total / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

addedOutput schema / properties / unpaid_totals

Added value: +{
+  "additionalProperties": {
+    "type": "number"
+  },
+  "description": "Still unpaid per currency code, e.g. { USD: 150 }",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "count",
-  "unpaid_total",
-  "invoices"
-]New value: +[
+  "count",
+  "unpaid_total",
+  "unpaid_totals",
+  "invoices"
+]

First observedOct 17, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description goes further by disclosing the 200-record result cap and the conditional output semantics of unpaid_totals (per currency) vs unpaid_total (only when a single currency matches). That is real behavioral context an agent could not infer from annotations or schema.

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?

Three dense sentences, with the scope constraint front-loaded ahead of the filter list. Every clause carries information, though the trailing unpaid_totals/unpaid_total sentence is somewhat compressed and takes a moment to parse.

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 return-value documentation is not required, and the description still fills the key gaps: result cap, per-invoice currency, filter dimensions, and the conditional totals fields. Only the sort behavior and any pagination/ordering interaction with the 200 cap go unexplained.

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 description coverage is 100%, so the schema already documents query, client, status, issued_from/issued_to and sort. The description restates the filter axes in prose but adds no syntax, formats, or precedence rules beyond the schema; baseline 3 applies. It also omits any mention of the sort parameter.

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?

States a specific resource (invoice history) and adds concrete scope details: the 200-item cap, per-invoice currency, and the available filter dimensions. It clearly reads as a paginated list operation rather than the single-record get_invoice sibling, though it never names that sibling explicitly.

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?

Filter dimensions are listed ('Filter by text, client, paid status or issue-date range'), which implies when the tool is useful, but there is no explicit when-to-use/when-not guidance or routing to alternatives like get_invoice for a single record.

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

All UseHourly 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.