Skip to main content
Glama
hs737

MCP Server for YNAB

by hs737

Transactions — List by month

transactions_list_by_month
Read-only

Lists transactions for a specific month in YNAB, with filters for cleared, approved, manual, amount, and selected fields. Use it to review monthly activity and find uncategorized items.

Instructions

[READ] List transactions for a specific month. month: ISO date string for the first day of the month (e.g. '2024-01-01'). Amounts in milliunits. Returns a paginated envelope with items, count, has_more, and next_offset. limit defaults to 100 and cannot exceed 500. Filters applied before paging: cleared ('cleared', 'uncleared', 'reconciled'), approved (true/false), manual_only=true for transactions with no import_id (entered by hand), min_amount to keep only transactions whose absolute amount is at least that many milliunits. fields: name the columns you need and each item is projected down to them, which is where the size of a long list actually goes — fields=['id,date,amount,cleared,import_id,payee_name,memo'] is a fraction of the full row. id is always included, and an unknown name is refused with the list of valid ones. Fields that are null or empty are omitted from each item. A missing category_id therefore means the transaction is uncategorized, and a missing subtransactions list means it is not a split.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNo
limitNo
monthYes
fieldsNo
offsetNo
clearedNo
plan_idNo
approvedNo
min_amountNo
since_dateNo
manual_onlyNo
last_knowledge_of_serverNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description goes well beyond them: filters are applied before paging, limit defaults to 100 and is capped at 500, field projection behavior, id always injected, unknown field names rejected with the valid list, and null/empty values omitted so a missing category_id means uncategorized. That last point materially changes how results must be interpreted.

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?

It opens with the core purpose and is dense with useful detail rather than filler, though the aside about field projection being 'where the size of a long list actually goes' is slightly discursive. A long single paragraph rather than chunked sections costs a point on structure, not on substance.

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 the pagination envelope need not be re-explained, yet the description usefully names items/count/has_more/next_offset and the offset default. Combined with the annotations and the filter semantics, the definition is nearly self-sufficient for correct invocation; the handful of undocumented parameters (plan_id, since_date, type, last_knowledge_of_server) keep it short of complete.

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?

With 0% schema coverage the description carries the full burden and does cover month format, limit ceiling, cleared enum values, approved, manual_only (defined as no import_id), min_amount units, and fields projection syntax. However, type, plan_id, since_date, offset, and last_knowledge_of_server remain completely undocumented despite being real filters/sync controls.

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?

[READ] List transactions for a specific month' gives a precise verb, resource, and scoping key, and the month parameter format is spelled out with an example. The month-scoping immediately separates it from transactions_list, transactions_list_by_account, _by_category, and _by_payee.

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?

The filtered-list nature implies its use case (a month's transactions, optionally narrowed by cleared/approved/manual/min_amount), but there is no explicit when-to-use statement or pointer to an alternative such as transactions_list for non-month ranges. Routing is left entirely to inference from the name and filters.

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