ExpensifyAI

Overview Schema Source Related Servers Discussions Admin

Analyze Spending

analyze_spending

Analyze spending for yourself, a group, or a friend: see category breakdowns, monthly trends, top transactions, and settlement plans. Optionally generate an HTML dashboard.

Instructions

Deterministic spending analytics for the current user, a group, or a friend.

All numbers are computed in Python (never estimated by the model): category breakdown, monthly trend, owed-vs-paid ("mine vs split"), transaction ledger, top transactions, and — for groups — per-member comparison, category×member matrix, and a minimum-transaction settlement plan. Every result includes a reconciliation check (shares must sum to cost) and a multi-currency guard.

target_type: "me" (all your expenses), "group" (needs target_id=group_id), or "friend" (needs target_id=friend user_id). dated_after / dated_before: ISO 8601 date filters (optional). generate_dashboard: if True, also writes a self-contained HTML dashboard and returns its file path in dashboard_path. Perspective is always the authenticated user.

Input Schema

TableJSON Schema

Name	Required	Default
`top_n`	No
`target_id`	No
`dated_after`	No
`target_type`	No	me
`dated_before`	No
`generate_dashboard`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 21, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses deterministic computation (not model estimation), reconciliation checks, a multi-currency guard, the authenticated-user perspective, and the side effect of generating an HTML dashboard. This is substantial transparency, though it does not mention permissions or rate limits.

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 a bit long but well-organized: a clear opening sentence, a detailed output list, then parameter explanations. It is front-loaded with the core purpose, and each sentence adds value without redundancy.

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 6 optional parameters, an output schema, and no annotations, the description covers the essential behavioral traits and parameter semantics. It does not explain the output schema structure, but that is provided separately. It is complete for an agent to call 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 coverage is 0%, so the description must explain parameters. It explicitly describes target_type, target_id, date filters (ISO 8601), and generate_dashboard's behavior and output path. top_n is implied via 'top transactions'. All parameters are effectively covered, exceeding the compensation expected at 0% schema coverage.

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 the tool computes deterministic spending analytics for the user, group, or friend, and lists specific outputs like category breakdown, monthly trend, and settlement plans. It distinguishes itself from raw data retrieval siblings like get_expenses by emphasizing computed analytics rather than simple listing.

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 explains target_type and when to use each scope (me, group, friend) and implies this tool is for analytics rather than raw data. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it when computed insights are needed.

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