mcp-ledger-server-ts

Ledger summary

ledger_summary

Read-onlyIdempotent

Get a read-only ledger overview with invoice counts and totals by status and currency, past-due open invoices, oldest open invoice, and decision-reason tallies to answer "how are we doing" questions.

Instructions

Portfolio overview of the ledger: invoice counts and totals per status and currency, how many open (received or on_hold) invoices are past their due date, the oldest open invoice, and a tally of recorded decision reasons. Read-only. Use for "how are we doing" questions.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ledger_summary"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`asOf`	Yes
`byStatus`	Yes
`oldestOpen`	Yes
`overdueOpen`	Yes
`invoiceCount`	Yes
`decisionReasons`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description's 'Read-only.' merely restates it. Beyond that it discloses no cost, latency, caching, or data-freshness behavior; most of its length goes to enumerating return fields, which the output schema already carries.

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 lead phrase 'Portfolio overview of the ledger' is properly front-loaded, but the middle clause is a long enumeration of return fields that duplicates the output schema and dilutes the selection signal. The trailing 'Read-only.' and usage sentence are short but one repeats annotations and the other could be merged.

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?

With zero parameters, an output schema for return shape, and annotations covering safety and idempotency, the only remaining burden is telling the agent what question this tool answers — which the 'how are we doing' cue does. Naming the nearest sibling as the alternative would close the last gap.

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

Parameters4/5

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

The tool takes no parameters, so there is no per-argument semantics to explain and the schema (empty object) is complete. The baseline of 4 applies; nothing in the description is needed or missing on this dimension.

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 names the resource (the ledger) and enumerates concrete outputs — invoice counts and totals per status/currency, count of past-due open (received or on_hold) invoices, oldest open invoice, decision-reason tally — so the agent knows this is an aggregate overview rather than a record fetch. It does not explicitly contrast itself with list_invoices or get_invoice, leaving the aggregate-vs-item distinction to be inferred from the word 'overview'.

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

Usage Guidelines3/5

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

'Use for "how are we doing" questions' gives a clear situational cue for when to reach for this tool. However, it never names an alternative or states when NOT to use it (e.g. use list_invoices for per-invoice detail), so routing still requires inference from sibling names.

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

Deploy Server