Skip to main content
Glama
naveen6768

Expense Tracker MCP

by naveen6768

get_expense_summary

Retrieve totals and category breakdown for expenses matching specified date range and category filters.

Instructions

Return totals and category breakdown for matching expenses.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryNo
start_dateNo
end_dateNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
total_amountYes
category_breakdownYes
filtersYes

Implementation Reference

  • main.py:217-254 (handler)
    Handler function for the get_expense_summary tool. It lists expenses (optionally filtered by category/date range), computes total and per-category amounts, and returns an ExpenseSummary Pydantic model with count, total_amount, category_breakdown, and applied filters.
    @mcp.tool
    def get_expense_summary(
        category: str | None = None,
        start_date: str | None = None,
        end_date: str | None = None,
    ) -> ExpenseSummary:
        """Return totals and category breakdown for matching expenses."""
        filtered = list_expenses(
            category=category,
            start_date=start_date,
            end_date=end_date,
        )
    
        total = Decimal("0.00")
        by_category: dict[str, Decimal] = {}
    
        for expense in filtered:
            amount = Decimal(expense.amount)
            total += amount
            by_category.setdefault(expense.category, Decimal("0.00"))
            by_category[expense.category] += amount
    
        return ExpenseSummary(
            count=len(filtered),
            total_amount=format(total.quantize(Decimal("0.01")), ".2f"),
            category_breakdown={
                category_name: format(
                    category_total.quantize(Decimal("0.01")),
                    ".2f",
                )
                for category_name, category_total in sorted(by_category.items())
            },
            filters=SummaryFilters(
                category=category,
                start_date=start_date,
                end_date=end_date,
            ),
        )
  • main.py:33-37 (schema)
    Pydantic model defining the return schema for get_expense_summary: count (int), total_amount (str), category_breakdown (dict of category to amount string), and filters (SummaryFilters).
    class ExpenseSummary(BaseModel):
        count: int
        total_amount: str
        category_breakdown: dict[str, str]
        filters: SummaryFilters
  • main.py:27-30 (schema)
    Pydantic model for the filters sub-object used in ExpenseSummary, capturing the optional category, start_date, and end_date applied to the query.
    class SummaryFilters(BaseModel):
        category: str | None = None
        start_date: str | None = None
        end_date: str | None = None
  • main.py:217-217 (registration)
    The @mcp.tool decorator registers get_expense_summary as an MCP tool on the FastMCP instance.
    @mcp.tool
  • Helper used by get_expense_summary (via list_expenses) to filter expenses by category and date range.
    def _filter_expenses(
        expenses: list[Expense],
        category: str | None = None,
        start_date: str | None = None,
        end_date: str | None = None,
    ) -> list[Expense]:
        normalized_category = category.strip().lower() if category else None
        parsed_start = date.fromisoformat(start_date) if start_date else None
        parsed_end = date.fromisoformat(end_date) if end_date else None
    
        if parsed_start and parsed_end and parsed_start > parsed_end:
            raise ValueError("start_date cannot be after end_date.")
    
        filtered: list[Expense] = []
        for expense in expenses:
            expense_day = date.fromisoformat(expense.expense_date)
    
            if normalized_category and expense.category.lower() != normalized_category:
                continue
            if parsed_start and expense_day < parsed_start:
                continue
            if parsed_end and expense_day > parsed_end:
                continue
    
            filtered.append(expense)
    
        return filtered
Behavior2/5

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

No annotations provided, and the description is minimal. It does not disclose any behavioral traits such as side effects, read-only nature, or rate limits. The agent is left to assume it's safe and stateless.

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 a single concise sentence, which is efficient for a simple tool. However, it is too terse and could benefit from including parameter details or usage notes without sacrificing brevity.

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

Completeness1/5

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

With 3 undocumented parameters and no annotations, the description fails to provide sufficient context for correct invocation. The output schema exists but the description should at least mention filtering behavior or return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not explain any parameters. The agent receives no help understanding the formatting of dates or the expected category values beyond the field name.

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 it returns totals and category breakdown for matching expenses, which distinguishes it from sibling tools like add_expense and delete_expense. However, list_expenses might also provide totals, but the focus on category breakdown differentiates it.

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?

No guidance on when to use this tool versus alternatives like list_expenses or when not to use it. Lacks context about prerequisites or typical use cases.

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/naveen6768/MCP'

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