Skip to main content
Glama
lapin7771n

Wallet BudgetBakers MCP

by lapin7771n

get_records

Retrieve financial transactions for a specific account using filters for date range, amount, category, and payee.

Instructions

Get financial records (transactions) for a specific account.

IMPORTANT: account_id is required. Use get_accounts() first to find it. Max date range is 370 days. If no date filter, returns last 3 months.

Date filter examples:

  • "gte.2025-01-01" — from Jan 1, 2025

  • "gte.2025-01-01,lte.2025-01-31" — January 2025

Amount filter examples:

  • "gte.100" — amount >= 100

  • "gte.100,lte.500" — between 100 and 500

Text filter prefixes: eq., contains., contains-i.

Args: ctx: MCP context account_id: Required. Account ID (use get_accounts to find IDs) record_date: Date range filter with prefix (e.g. "gte.2025-01-01") limit: Items per page (1-100, default 30) offset: Items to skip for pagination category_id: Filter by category ID label_id: Filter by label ID note: Filter by note text (use prefix: contains-i.grocery) payee: Filter expenses by payee (use prefix: contains-i.amazon) payer: Filter income by payer amount: Filter by amount (use prefix: gte.100,lte.500) record_type: Filter by type: income or expense. Transfers are not a separate type — they are identified by transferId/transferAccountId fields in the response sort_by: Sort field and direction (e.g. "recordDate,asc" or "amount,desc") created_at: Filter by creation date (e.g. "gte.2025-01-01") updated_at: Filter by last update date (e.g. "gte.2025-01-01")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
limitNo
payeeNo
payerNo
amountNo
offsetNo
sort_byNo
label_idNo
account_idYes
created_atNo
updated_atNo
category_idNo
record_dateNo
record_typeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations are provided, so the description carries full burden. It discloses critical behaviors: max date range 370 days, default 3 months if no date filter, transfer records identified by transferId/transferAccountId, and detailed filter syntax. This goes far beyond a basic description.

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 well-structured and front-loaded with the most critical info (required account_id, date limits), but it has some redundancy: filter examples are given in a dedicated section and then repeated in the args list. While this improves self-containedness, it slightly hurts conciseness.

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 params, no annotations, output schema present), the description provides comprehensive context: required parameters, default pagination, filter formats, and transfer behavior. It is sufficient for an agent to select and invoke correctly.

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?

Schema description coverage is 0%, so the description fully compensates. Every parameter (14 total) is listed with examples and explanations (e.g., 'note: Filter by note text (use prefix: contains-i.grocery)' and 'amount: Filter by amount (use prefix: gte.100,lte.500)'). This adds substantial meaning beyond the raw 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 clearly states 'Get financial records (transactions) for a specific account.' This is a specific verb+resource with scope, and it distinguishes from siblings like get_records_by_id (single record) and get_accounts (accounts).

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?

It explicitly says 'account_id is required. Use get_accounts() first to find it,' providing a prerequisite and directing to a sibling tool. It also clarifies default behavior (last 3 months) and max date range. However, it does not explicitly contrast with alternatives like get_records_by_id for single-record retrieval.

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/lapin7771n/wallet-budgetbakers-mcp'

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