YNAB MCP Server

Get month category

get_month_category

Read-only

Retrieve a YNAB category’s assigned, activity, available, and target amounts for a chosen month, including current, last, next, or a specific date.

Instructions

Get one category's assigned, activity, available, and target for a month.

Input Schema

Name	Required	Description	Default
`month`	No	Which plan month (default: "current"): • "current": This calendar month • "last": The previous calendar month • "next": The next calendar month • A date: The month containing that date, such as 2024-03-01	current
`category_id`	Yes	Category to look up (required)

Output Schema

Name	Required	Description
`id`	Yes	Unique category identifier
`name`	Yes	Category name
`note`	No	Category notes
`activity`	No	Activity this month (negative = spending)
`assigned`	No	Amount assigned this month
`internal`	No	Whether YNAB manages this category itself. 'Inflow: Ready to Assign' is internal: categorize income to it.
`available`	No	Amount available to spend, including rollover
`target_date`	No	Date the target should be met, for targets with a date
`target_type`	No	Target type: NEED (needed for spending, refills each period), TB (have a balance), TBD (have a balance by a date), MF (fund monthly), DEBT (pay down a debt)
`target_amount`	No	Target amount
`category_group_id`	Yes	Category group ID
`target_underfunded`	No	Amount still needed this month to stay on track
`category_group_name`	No	Category group name
`target_overall_left`	No	Amount still needed to meet the target this period
`target_percentage_complete`	No	How much of the target is funded, as a percentage

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 26, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds which budget figures are returned (assigned, activity, available, target), which is mildly useful, but says nothing about permissions, missing-category behavior, or how the values are scoped.

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?

A single front-loaded sentence with zero filler; the key scope words ('one category', 'for a month') come first.

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 annotations, full schema coverage, and an output schema, the description only needs to frame the call, which it does. The one residual gap is that it doesn't relate the tool to its closely-named siblings, leaving routing slightly under-specified.

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%, including a detailed enum/date explanation for 'month' and a required note for 'category_id', so the schema carries the parameter burden. The description only restates the category and month framing, adding no syntax or format detail beyond the schema.

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?

The description names a specific verb ('Get') and resource ('one category's assigned, activity, available, and target for a month'), and the phrase 'one category' implicitly distinguishes it from month-wide siblings like get_plan_month. It never names a sibling explicitly, so an agent must infer the boundary from the phrasing.

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?

Usage is implied by 'for a month' on a single category, but there is no explicit when-to-use, when-not, or pointer to alternatives such as get_plan_month or list_categories. The agent has to reason about the boundary itself.

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