Skip to main content
Glama
Jtewen

You Need A Budget (YNAB) MCP

by Jtewen

list-transactions

Fetch and analyze transactions for a specific account or month to review spending patterns. Provides detailed insights for budgeting and financial tracking in YNAB.

Instructions

List transactions for a specific account or an entire month. Use this to investigate spending patterns identified in the financial overview.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idNoThe ID of the account to fetch transactions for.
budget_idNoThe ID of the budget. If not provided, the default budget will be used.
limitNoThe maximum number of transactions to return.
monthNoThe month to fetch transactions for (YYYY-MM-DD format).
since_dateNoThe starting date for transactions (YYYY-MM-DD). Only valid if 'account_id' is provided.

Implementation Reference

  • Main execution logic for the 'list-transactions' tool: validates input using ListTransactionsInput, fetches transactions via ynab_client based on account_id or month parameters, applies filters and limits, formats a text response with transaction details.
    elif name == "list-transactions":
        args = ListTransactionsInput.model_validate(arguments or {})
        budget_id = await _get_budget_id(args.model_dump())
        
        limit = int(args.limit) if args.limit is not None else None
        
        if args.account_id and not args.month:
            transactions = await ynab_client.get_transactions(
                budget_id=budget_id,
                account_id=args.account_id,
                since_date=args.since_date,
                limit=limit,
            )
            header = f"Here are the latest transactions for account {args.account_id}:"
        elif args.month:
            since_date = args.month
            if args.account_id:
                transactions = await ynab_client.get_transactions(
                    budget_id=budget_id,
                    account_id=args.account_id,
                    since_date=since_date,
                )
                header = f"Here are the transactions for account {args.account_id} in {args.month}:"
            else:
                transactions = await ynab_client.get_monthly_transactions(
                    budget_id=budget_id,
                    month=since_date,
                )
                header = f"Here are the transactions for {args.month}:"
    
            if transactions:
                # Filter transactions to the specified month
                transactions = [
                    t for t in transactions if str(t.var_date).startswith(since_date[:7])
                ]
                if limit:
                    transactions = transactions[:limit]
        else:
            # This case should now be primarily for account_id with since_date
            transactions = await ynab_client.get_transactions(
                budget_id=budget_id,
                account_id=args.account_id,
                since_date=args.since_date,
                limit=limit,
            )
            header = f"Here are the latest transactions for account {args.account_id}:"
    
        if not transactions:
            return [types.TextContent(type="text", text="No transactions found.")]
    
        transaction_list = "\n".join(
            f"- {t.var_date}: {t.payee_name or 'N/A'} | "
            f"{t.category_name or 'N/A'} | {t.amount / 1000:.2f} (ID: {t.id})"
            for t in transactions
        )
        return [
            types.TextContent(
                type="text",
                text=f"{header}\n{transaction_list}",
            )
        ]
  • Pydantic model ListTransactionsInput defining the input schema for the tool, with fields for budget_id (inherited), account_id, month, since_date, limit, and validation ensuring either account_id or month is provided.
    class ListTransactionsInput(BudgetIdInput):
        account_id: Optional[str] = Field(None, description="The ID of the account to fetch transactions for.")
        month: Optional[str] = Field(None, description="The month to fetch transactions for (YYYY-MM-DD format).")
        since_date: Optional[str] = Field(
            None, description="The starting date for transactions (YYYY-MM-DD). Only valid if 'account_id' is provided."
        )
        limit: Optional[float] = Field(
            None, description="The maximum number of transactions to return."
        )
    
        @model_validator(mode='before')
        @classmethod
        def check_exclusive_fields(cls, values):
            if not values.get('account_id') and not values.get('month'):
                raise ValueError('Either "account_id" or "month" must be provided.')
            if values.get('month') and values.get('since_date'):
                raise ValueError('"since_date" is not applicable when "month" is provided.')
            return values
  • Tool registration in handle_list_tools(), defining name, description, and inputSchema for 'list-transactions'.
    types.Tool(
        name="list-transactions",
        description="List transactions for a specific account or an entire month. Use this to investigate spending patterns identified in the financial overview.",
        inputSchema=ListTransactionsInput.model_json_schema(),
    ),
  • Includes 'list-transactions' in the set of read-only tools, which are always available even in read-only mode.
    READ_ONLY_TOOLS = {
        "list-budgets",
        "list-accounts",
        "list-transactions",
        "list-categories",
        "list-payees",
        "list-scheduled-transactions",
        "get-financial-overview",
        "get-month-info",
        "lookup-payee-locations",
    }
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. While it mentions the investigation purpose, it doesn't describe key behavioral traits: whether this is a read-only operation, if it requires authentication, how results are returned (pagination, format), rate limits, or error conditions. The description adds minimal behavioral context beyond the basic purpose.

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 appropriately concise with two sentences. The first sentence states the core functionality, and the second provides usage context. Both sentences earn their place, though the second could be more specific. No wasted words or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what the tool returns (transaction format, structure), how results are limited or paginated, or error handling. For a list operation with multiple filtering parameters and no output schema, more complete context is needed.

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 fully documents all 5 parameters. The description mentions 'specific account or an entire month' which aligns with 'account_id' and 'month' parameters, but adds no additional semantic context beyond what's in the schema. With complete schema coverage, the baseline score of 3 is appropriate.

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 clearly states the tool's purpose: 'List transactions for a specific account or an entire month.' It uses a specific verb ('List') and resource ('transactions'), and provides scope details (account-specific or month-wide). However, it doesn't explicitly distinguish this from sibling tools like 'list-scheduled-transactions' or 'bulk-manage-transactions' beyond the investigation context.

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 usage context: 'Use this to investigate spending patterns identified in the financial overview.' This implies when to use the tool (for investigation after reviewing financial overview), but doesn't offer explicit guidance on when to choose this tool versus alternatives like 'list-scheduled-transactions' or 'get-month-info'. No exclusions or clear alternatives are mentioned.

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

Related 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/Jtewen/ynab-mcp'

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