Skip to main content
Glama
ScottyOmega

YNAB MCP Server

spending_trend

Track month-by-month spending changes over a recent period, either overall or for a specific category. Identify rising or falling trends to adjust your budget.

Instructions

Shows how spending has changed month by month over a recent window — either overall or for one category. Useful for spotting whether spending in an area is creeping up or down over time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
monthsNoHow many months back to look, including the current month.
budget_idNoThe budget ID, or 'last-used' for the most recently used budget.last-used
category_nameNoLimit the trend to one category (partial, case-insensitive match). Omit for overall spending.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.10.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It is evidently a read-only trend query and the phrase 'month by month' hints at the returned series shape, but there is no explicit statement that it is non-mutating, nor any note on permissions, defaults, or ordering of results.

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?

Two sentences, front-loaded with the core behavior and followed by a brief purpose statement. No wasted clauses, though the em-dash aside adds mild length without new information.

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 no output schema, the description adequately conveys that the result is a month-by-month trend series rather than a single total, which is the key expectation an agent needs. It is a simple read tool with fully documented params, so the remaining gaps (exact return fields) are minor.

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 months, budget_id, and category_name fully. The description only echoes the overall-vs-category distinction, adding no format or matching detail beyond what the schema already provides; baseline 3 applies.

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 verb and resource: 'shows how spending has changed month by month over a recent window,' with scope options (overall or one category). It is clearly distinguishable from the by-category breakdown or month-summary siblings, though it does not name any 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?

The second sentence gives implied usage ('spotting whether spending in an area is creeping up or down over time'), which tells the agent the analytic intent. However, there is no when-not guidance and no routing to alternatives like spending_by_category or get_month_summary for a single-period breakdown.

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