Skip to main content
Glama
jamiew

Monarch Money MCP Server

Get Transactions

get_transactions
Read-only

Fetch financial transactions with flexible filters for date range, account, category, and more. Control output detail with compact or verbose mode.

Instructions

Fetch transactions with flexible date filtering and smart output formatting.

Args: limit: Maximum number of transactions to return (default: 100, max: 1000) offset: Number of transactions to skip for pagination (default: 0) start_date: Filter transactions from this date onwards. Supports natural language like 'last month', 'yesterday', '30 days ago' NOTE: If you provide start_date without end_date, end_date will auto-default to 'today' end_date: Filter transactions up to this date. Supports natural language NOTE: If you provide end_date without start_date, start_date will auto-default to 'this month' account_id: Filter by specific account ID (converted to list internally) category_id: Filter by specific category ID (converted to list internally) tag_ids: Comma-separated tag IDs to filter by (e.g., "tag1,tag2") has_attachments: Filter to transactions with (True) or without (False) attachments has_notes: Filter to transactions with (True) or without (False) notes hidden_from_reports: Include hidden transactions (True), exclude them (False), or show all (None) is_split: Filter to split transactions only (True) or non-split (False) is_recurring: Filter to recurring transactions only (True) or non-recurring (False) verbose: Output format control (default: False) - False (compact mode): Returns essential fields only (~80% smaller) Fields included: id, date, amount, merchant, plaidName, category, account, pending, needsReview, notes

    - True (verbose mode): Returns ALL fields including:
        Essential fields (same as compact) PLUS:
        • hideFromReports (bool)
        • reviewStatus (str: "needs_review" | "reviewed" | null)
        • isSplitTransaction (bool)
        • isRecurring (bool)
        • attachments (list of attachment objects)
        • tags (list of tag objects)
        • createdAt (ISO timestamp)
        • updatedAt (ISO timestamp)
        • __typename (GraphQL metadata)
        • Full nested objects with all their fields

    Use verbose=False for most queries to reduce token usage.
    Use verbose=True when you need: timestamps, split info, attachment details,
    or are updating transactions (need full context).

Key Transaction Fields: Core Identifiers: - id: Unique transaction ID (required for updates) - date: Transaction date (YYYY-MM-DD format) - amount: Transaction amount (negative = expense, positive = income)

Merchant Information:
    IMPORTANT: Monarch normalizes merchant names for cleaner UI
    - merchant.name: User-facing display name shown in Monarch UI (normalized/cleaned)
        Example: "Chipotle" for all Chipotle locations
    - plaidName: Original bank statement text from Plaid/institution (raw data)
        Example: "CHIPOTLE 4963", "CHIPOTLE MEX GR ONLINE", "CHIPOTLE 1879"
        Use this to see location numbers or original descriptors
    - Multiple transactions from different locations share the same merchant.name
    - Use plaidName to distinguish between specific locations/variants

Categorization:
    - category.id: Category ID (for filtering/updates)
    - category.name: Category display name (e.g., "Restaurants & Bars")
    - tags: List of tag objects applied to transaction

Account Info:
    - account.id: Account ID where transaction occurred
    - account.displayName: Account name (e.g., "Main Credit Card")

Status Flags:
    - pending: True if transaction hasn't cleared yet
    - needsReview: True if flagged for user review
    - reviewStatus: "needs_review", "reviewed", or null
    - hideFromReports: True if hidden from budget/reports

Transaction Types:
    - isSplitTransaction: True if split into multiple categories
    - isRecurring: True if part of a recurring series

User Annotations:
    NOTE: These are different fields with different purposes
    - notes: Free-form user memo/annotation (e.g., "Business lunch with client")
    - merchant_name: The merchant's display name (e.g., "Olive Garden")
    - Both are editable, but serve different purposes in the UI
    - attachments: List of receipt/document attachments

Metadata (verbose mode only):
    - createdAt: When transaction was first imported
    - updatedAt: Last modification timestamp
    - __typename: GraphQL type information

Returns: JSON string containing transaction list

Common Filter Examples: - Unreviewed transactions: has_notes=False, needs_review=True - Split transactions: is_split=True - Transactions with receipts: has_attachments=True - Manual transactions: synced_from_institution=False

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
start_dateNo
end_dateNo
account_idNo
category_idNo
tag_idsNo
has_attachmentsNo
has_notesNo
hidden_from_reportsNo
is_splitNo
is_recurringNo
verboseNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
transactionsYes
countYes
verboseYes
Behavior5/5

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

Beyond the readOnlyHint annotation, the description details pagination, date auto-defaults, natural language date support, verbose vs compact output modes, and internal parameter handling (e.g., converting account_id to list). This fully discloses behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with headings but is very long, containing a large reference section on transaction fields that could be streamlined. While detailed, it sacrifices conciseness, especially for a tool with 13 parameters.

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 the complexity and the absence of an output schema (only indicated as present), the description covers parameters, output fields, and examples thoroughly. It omits error handling and edge cases (e.g., exceeding limit max), but overall provides a comprehensive picture.

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?

With 0% schema description coverage, the description compensates extensively by explaining each parameter's purpose, default values, data types, and special behaviors (e.g., 'converted to list internally', 'auto-default to today'). It even includes common filter examples.

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 'Fetch transactions with flexible date filtering and smart output formatting,' specifying the verb and resource. It distinguishes from siblings by focusing on filtering and output formatting, but does not explicitly differentiate from 'search_transactions' or other related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides filtering examples but no explicit guidance on when to use this tool versus alternatives like 'search_transactions' or 'get_complete_financial_overview'. It lacks when-not-to-use scenarios or tool selection criteria.

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/jamiew/monarch-mcp'

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