Skip to main content
Glama

get_transactions

Read-only

Retrieve transactions from Copilot Money with filters by date, category, merchant, amount, and more. Supports single lookup, text search, and location-based queries.

Instructions

Reads from the local LevelDB cache, which may lag behind Copilot's server if the macOS app hasn't synced recently. For real-time data use --live-reads with get_transactions_live. Unified transaction retrieval tool. Supports multiple modes: (1) Filter-based: Use period, date range, category, merchant, amount filters. (2) Single lookup: Provide transaction_id to get one transaction. (3) Text search: Use query for free-text merchant search. (4) Special types: Use transaction_type for foreign/refunds/credits/duplicates/hsa_eligible/tagged. (5) Location-based: Use city or lat/lon with radius_km. (6) Tag filter: Use tag to find transactions with a specific tag. Returns human-readable category names and normalized merchant names.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
periodNoPeriod shorthand: this_month, last_month, last_7_days, last_30_days, last_90_days, ytd, this_year, last_year
start_dateNoStart date (YYYY-MM-DD)
end_dateNoEnd date (YYYY-MM-DD)
categoryNoFilter by category (case-insensitive substring)
merchantNoFilter by merchant name (case-insensitive substring)
account_idNoFilter by account ID
min_amountNoMinimum transaction amount
max_amountNoMaximum transaction amount
limitNoMaximum number of results (default: 100)
offsetNoNumber of results to skip for pagination (default: 0)
exclude_transfersNoExclude transfers between accounts and credit card payments (default: true)
exclude_deletedNoExclude deleted transactions marked by Plaid (default: true)
exclude_excludedNoExclude user-excluded transactions (default: true)
exclude_split_parentsNoExclude split-transaction parents (docs with children_transaction_ids). The children already carry the real categorized amounts — returning the parent would double-count the spend. Default: true.
pendingNoFilter by pending status (true for pending only, false for settled only)
regionNoFilter by region/city (case-insensitive substring)
countryNoFilter by country code (e.g., US, CL)
transaction_idNoGet a single transaction by ID (ignores other filters)
queryNoFree-text search in merchant/transaction names
transaction_typeNoFilter by special type: foreign (international), refunds, credits (cashback/rewards), duplicates (potential duplicate transactions), hsa_eligible (medical expenses), tagged (has tags)
tagNoFilter by tag name (e.g. "vacation")
cityNoFilter by city name (partial match)
latNoLatitude for proximity search (use with lon and radius_km)
lonNoLongitude for proximity search (use with lat and radius_km)
radius_kmNoSearch radius in kilometers (default: 10)
Behavior5/5

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

The description discloses behavioral traits beyond the readOnlyHint annotation: it explains the tool reads from a local LevelDB cache that may lag, describes return format (human-readable category names, normalized merchant names), and details six distinct usage modes. No contradiction with annotations exists.

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-organized with numbered list for modes and key caveat upfront. However, it is slightly verbose with some redundant phrasing (e.g., 'Unified transaction retrieval tool' followed by detailed enumeration). Every sentence is useful, but conciseness could be improved.

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 (25 parameters, no output schema), the description thoroughly covers all usage modes, data source characteristics, caching latency, and output format. It provides complete guidance for an AI agent to correctly select and invoke the 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?

Despite 100% schema coverage, the description adds substantial contextual meaning by grouping parameters into intuitive modes (e.g., 'location-based: Use city or lat/lon with radius_km'). It explains how parameters interact, such as 'transaction_id ignores other filters' and 'exclude_split_parents avoids double-counting'. This goes far beyond the schema descriptions.

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 'Unified transaction retrieval tool' and enumerates multiple specific modes, each with distinct purposes (filter-based, single lookup, text search, special types, location-based, tag filter). The name 'get_transactions' directly indicates the action and resource, effectively distinguishing it from sibling tools like 'get_accounts' or 'get_budgets'.

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 warns about cache lag and directs users to 'get_transactions_live' for real-time data. It outlines when to use each mode (e.g., 'single lookup: Provide transaction_id'). However, it lacks explicit when-not-to-use guidance or exclusion of other tools beyond the live alternative.

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/ignaciohermosillacornejo/copilot-money-mcp'

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