Skip to main content
Glama
pragprogrammer

YNAB MCP Server

update_transaction

Update an existing transaction's details such as date, amount, payee, category, memo, or flag. Only provide fields to change; split transactions have restrictions.

Instructions

Update an existing transaction. Only provide the fields you want to change.

Future-dated transactions are not permitted. Split transaction amounts and dates cannot be changed. If an existing transaction is a split, category_id cannot be changed and updating subtransactions is not supported.

Args: plan_id: The plan ID (use list_plans to find available IDs) transaction_id: The transaction ID to update account_id: New account ID date: New date (YYYY-MM-DD, must not be in the future) amount: New amount in dollars (negative for outflow, positive for inflow) payee_id: New payee ID. For account transfers, use target account's transfer_payee_id. payee_name: New payee name (resolves to existing or creates a new payee) category_id: New category ID. Use null with subtransactions to create a split. memo: New memo (max 500 chars) cleared: 'cleared', 'uncleared', or 'reconciled' approved: Whether the transaction is approved flag_color: 'red', 'orange', 'yellow', 'green', 'blue', 'purple', or null subtransactions: For creating a new split, list of dicts with: amount, payee_id, payee_name, category_id, memo exclude_fields: Optional list of field names to exclude from the response. If omitted, the model's default exclude list is used (see FIELDS.md). Pass [] to return all fields. Pass a custom list to override the default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo
memoNo
amountNo
clearedNo
plan_idYes
approvedNo
payee_idNo
account_idNo
flag_colorNo
payee_nameNo
category_idNo
exclude_fieldsNo
transaction_idYes
subtransactionsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/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. It transparently discloses key behavioral traits: future-dated transactions are not permitted, split transaction amounts/dates cannot be changed, category_id cannot be changed for existing splits, and updating subtransactions is unsupported. It also explains the 'exclude_fields' parameter behavior. It does not mention required permissions or destructive consequences, but given the zero-annotation context, this is quite thorough.

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?

The description is relatively long due to the number of parameters and edge cases, but it is well-structured with a clear introductory sentence, followed by important caveats, and then a parameter list. Every sentence contributes meaning. It could potentially be more concise by grouping common concepts, but given the complexity, it is appropriately detailed without being verbose.

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 the tool's complexity (14 parameters, special behaviors for splits and future dates, and existence of an output schema), the description covers all necessary aspects: parameter details, constraints, and optional exclude_fields behavior. It references external documentation (FIELDS.md) for default exclude lists. Most edge cases are addressed. The presence of an output schema reduces the need to describe return values, which is not done here. The description is complete for an update tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 14 parameters with 0% description coverage, meaning the schema provides no explanations. The description's 'Args' section adds detailed semantics for each parameter, including formats (e.g., YYYY-MM-DD for date), meanings (e.g., amount: 'negative for outflow, positive for inflow'), constraints (e.g., memo max 500 chars), and special cases (e.g., use null with subtransactions to create a split, payee_name resolves to existing or creates new). This adds enormous value beyond the schema.

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 begins with 'Update an existing transaction,' clearly stating the verb and resource. It distinguishes from sibling tools like 'create_transaction' and 'delete_transaction' by specifying update semantics and providing details unique to updates (e.g., split handling, future-date restrictions).

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?

The description explicitly advises to 'Only provide the fields you want to change' and warns against using it for future-dated transactions, split transactions where amount/date cannot change, and unsupported subtransaction updates. It references 'list_plans' for finding plan IDs. However, it does not directly compare to 'update_transactions' (plural) or other related tools, leaving some ambiguity about when to use this single-transaction update versus bulk update.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pragprogrammer/mcp-ynab'

If you have feedback or need assistance with the MCP directory API, please join our Discord server