Monexa

List records

list_records

Read-onlyIdempotent

Lists income and expense records, newest first by default, each with its category name and type and its payment method name. Amounts are in each record's own currency. Returns at most limit records (default 50) together with the total number that matched; filter by date range, category, payment methods or text to narrow the result. Date filters are calendar days in UTC, and "today" from get_profile is the UTC date: for ranges such as today or this month, pass the user's local dates (YYYY-MM-DD) when you know them.

Input Schema

Name	Required	Description
`limit`	No	Maximum number of records to return (default 50, max 500).
`search`	No	Case-insensitive text matched against record descriptions and category names.
`sortBy`	No	Sort field; default date.
`endDate`	No	Only include records on or before this date (23:59:59 UTC for a date-only value). Format: YYYY-MM-DD or an RFC 3339 timestamp such as 2026-03-05T14:30:00Z.
`sortOrder`	No	Sort direction; default desc.
`startDate`	No	Only include records on or after this date (00:00:00 UTC for a date-only value). Format: YYYY-MM-DD or an RFC 3339 timestamp such as 2026-03-05T14:30:00Z.
`categoryId`	No	Only include records in this category (ID from list_categories).
`paymentMethodIds`	No	Only include records paid with one of these payment methods (IDs from list_payment_methods).

Output Schema

Name	Required	Description	Default
`total`	Yes
`records`	Yes
`returned`	Yes
`truncated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 1, 2026

changedOutput schema / properties / records / items / properties / currency / enum

Previous value: -[
-  "MKD",
-  "EUR",
-  "USD",
-  "AUD",
-  "CHF",
-  "GBP"
-]New value: +[
+  "MKD",
+  "EUR",
+  "USD",
+  "AUD",
+  "CHF",
+  "GBP",
+  "HUF",
+  "RSD"
+]

addedOutput schema / properties / records / items / properties / groupExpenseShareId

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / records / items / properties / groupId

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedOct 18, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish that this is a read-only, idempotent, non-destructive local operation. The description adds useful behavioral context beyond that: default newest-first ordering, limit default, total matched count, embedded category/payment method names, per-record currency, and UTC date semantics.

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

Conciseness5/5

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

The description is dense and front-loaded: purpose, default behavior, return shape, filtering, and date semantics follow in logical order. Every sentence adds relevant information for an 8-parameter list tool, with no filler.

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?

Given an output schema, rich annotations, and eight optional parameters, the description covers the remaining agent-critical context: default ordering, pagination limit and total count, returned relationship names, currency handling, and date-filter timezone behavior.

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 description coverage is 100%, so the schema already documents parameters well. The description still adds meaningful semantics for the date parameters by clarifying UTC calendar-day filtering and advising use of local YYYY-MM-DD dates for ranges like today or this month.

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 states a specific verb and resource: it lists income and expense records, with default ordering, returned category/payment method names, and per-record currency semantics. This clearly distinguishes it from sibling single-record tools like get_record and from category/payment-method list tools.

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 explains how to narrow results using date range, category, payment methods, or text search, and gives explicit timezone guidance for date filters. It does not explicitly compare itself with alternatives such as get_record or get_spending_summary, so it falls short of a 5.

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

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