Skip to main content
Glama
minhyeoky

Ledger CLI MCP Server

by minhyeoky

ledger_budget

Generate budget reports by filtering accounts, setting date ranges, and grouping data by day, week, month, or year using Ledger CLI financial data.

Instructions

Show budget report

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Implementation Reference

  • main.py:242-261 (handler)
    The main handler function for the 'ledger_budget' tool. It builds the ledger CLI command based on input parameters and executes it via the run_ledger helper.
    @mcp.tool(description="Show budget report")
    def ledger_budget(params: LedgerBudget) -> str:
        cmd = ["budget"]
    
        if params.query:
            cmd.append(params.query)
        if params.begin_date:
            cmd.extend(["-b", params.begin_date])
        if params.end_date:
            cmd.extend(["-e", params.end_date])
        if params.monthly:
            cmd.append("--monthly")
        if params.weekly:
            cmd.append("--weekly")
        if params.daily:
            cmd.append("--daily")
        if params.yearly:
            cmd.append("--yearly")
    
        return run_ledger(cmd)
  • Pydantic BaseModel schema defining the input parameters for the ledger_budget tool, including filters and period groupings.
    class LedgerBudget(BaseModel):
        query: Optional[str] = Field(None, description="Filter accounts by regex pattern")
        begin_date: Optional[str] = Field(
            None, description="Start date for transactions (YYYY/MM/DD)"
        )
        end_date: Optional[str] = Field(
            None, description="End date (exclusive) for transactions (YYYY/MM/DD)"
        )
        monthly: bool = Field(False, description="Group by month")
        weekly: bool = Field(False, description="Group by week")
        daily: bool = Field(False, description="Group by day")
        yearly: bool = Field(False, description="Group by year")
  • Shared helper function that executes ledger CLI commands safely, handling subprocess calls and error messages. Used by ledger_budget and other tools.
    def run_ledger(args: List[str]) -> str:
        try:
            if not LEDGER_FILE:
                return "Ledger file path not set. Please provide it via --ledger-file argument or LEDGER_FILE environment variable."
    
            # Validate inputs to prevent command injection
            for arg in args:
                if ";" in arg or "&" in arg or "|" in arg:
                    return "Error: Invalid characters in command arguments."
    
            result = subprocess.run(
                ["ledger", "-f", LEDGER_FILE] + args,
                check=True,
                text=True,
                capture_output=True,
            )
            return result.stdout
        except subprocess.CalledProcessError as e:
            error_message = f"Ledger command failed: {e.stderr}"
            if "couldn't find file" in e.stderr:
                error_message = f"Ledger file not found at {LEDGER_FILE}. Please provide a valid path via --ledger-file argument or LEDGER_FILE environment variable."
            return error_message
Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Show budget report' gives no indication of whether this is a read-only operation, what permissions might be required, whether it has side effects, how results are formatted, or any rate limits. The description provides zero behavioral context beyond the minimal implication that it displays information rather than modifies it.

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

Conciseness5/5

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

The description is maximally concise at just two words. While severely under-specified, it contains zero wasted language and is perfectly front-loaded. Every word (both of them) serves the core purpose of identifying the tool's function, though that function remains poorly defined.

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?

Given the tool's apparent complexity (7 parameters for generating budget reports with date ranges and grouping options), no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. 'Show budget report' fails to explain what a budget report contains, how it differs from other financial reports, what the parameters control, or what format the output takes. This leaves the agent unable to properly invoke or interpret results from this tool.

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?

The description mentions no parameters whatsoever, while the input schema shows 7 parameters (begin_date, daily, end_date, monthly, query, weekly, yearly) with 0% schema description coverage. The agent receives no guidance about what 'budget report' means in terms of date ranges, grouping options, or filtering capabilities. This leaves all parameter semantics completely undocumented in both the schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Show budget report' is a tautology that essentially restates the tool name 'ledger_budget' without adding meaningful specificity. It doesn't explain what a 'budget report' actually contains or how it differs from other ledger tools like 'ledger_balance' or 'ledger_stats'. The description lacks a clear verb+resource combination that would help an agent understand the tool's distinct function.

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

Usage Guidelines1/5

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

The description provides absolutely no guidance on when to use this tool versus the 7 sibling tools available (ledger_accounts, ledger_balance, ledger_commodities, ledger_payees, ledger_print, ledger_raw_command, ledger_register, ledger_stats). There's no mention of appropriate contexts, prerequisites, or alternatives, leaving the agent with no basis for selecting this specific budget tool over other ledger-related operations.

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

Related 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/minhyeoky/mcp-server-ledger'

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