mcp-ynab

by alexfu

Overview Schema Source Related Servers Discussions Admin

Python

Remote

getCategoryById

Retrieve a category's budget details by ID, including assigned, activity, and available amounts for the current month.

Instructions

Returns a single category. Amounts (assigned, activity, available, etc.) are specific to the current plan month (UTC).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "plan_id": "<plan_id>",
      "category_id": "<category_id>"
    },
    "name": "getCategoryById"
  }
}

Input Schema

Name	Required	Description	Default
`plan_id`	Yes	The id of the plan. "last-used" can be used to specify the last used plan and "default" can be used if default plan selection is enabled (see: https://api.ynab.com/#oauth-default-plan).
`category_id`	Yes	The id of the category

Output Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 15, 2026

TDQS

A3.8/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 full burden of behavioral disclosure. The description does add a key behavioral trait: the amounts are specific to the current plan month (UTC), which informs the agent that the returned data is time-dependent and may differ from other queries. However, it does not disclose other potential behaviors such as error handling (e.g., what happens if the category is not found), whether it is read-only (likely but not stated), or any authentication requirements. With no annotations, this is a moderate gap. The description adds some valuable context but not comprehensive behavioral transparency.

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 extremely concise and front-loaded. The first sentence states the primary purpose, and the second sentence adds a crucial caveat about month-specific amounts. There is no wasted wording, and the most critical information (the return's time-dependence) is placed immediately after the purpose. This is an efficient and well-structured description.

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?

Given that the tool has an output schema (which likely details the return structure), the description does not need to explain return format. The primary missing piece is error handling and prerequisites (e.g., must have a plan_id that exists), but the output schema and input schema cover the core. The description is complete enough for an agent to successfully call the tool with the given parameters and understand the key nuance of the data. Thus, a 4 is appropriate; it's nearly complete but could mention error cases or permissions.

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%, meaning both parameters (plan_id and category_id) are fully documented in the input schema. The description adds no additional meaning to the parameters themselves; it only clarifies the returned data's month-sensitivity. Since the schema already explains the parameters well, the baseline of 3 is appropriate. The description does not need to repeat parameter details, but it also doesn't add extra semantics beyond the schema, so a 3 is fair.

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 clearly states the tool's function: 'Returns a single category.' This directly and specifically describes the resource (category) and the action (get by ID). It is distinguished from sibling tools like 'getCategories' (plural) and 'getMonthCategoryById' (which is per-month) by the singular focus and the added detail about month-specific amounts. The specificity of 'single category' and the scope clarification make it a strong purpose statement.

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 description provides some implied usage context by explaining that amounts are specific to the current plan month (UTC), which is useful for understanding the data returned. However, it does not explicitly state when to use this tool over alternatives like 'getCategoryById' versus 'getMonthCategoryById' or when the month-specific amounts might be important. The guidance is clear enough for an agent to understand the tool's purpose, but it lacks explicit exclusions or alternatives. A 3 is appropriate because it gives context but does not fully guide selection among siblings.

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

Deploy Server