Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ledger-mcp Cross-examine my rent ledger for any discrepancies with my lease."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Keep an eye on your rent ledger — and cross-examine it against your lease — through your AI assistant.
LedgerMCP is a Model Context Protocol server built for renters. Import your property/rent-portal ledger (CSV, TSV, Excel) and your lease (PDF), and LedgerMCP gives an AI assistant a set of deterministic tools to answer questions like:
"Am I being charged the right rent every month?"
"Is this 'Valet Trash' fee actually in my lease?"
"Did they charge me the late fee my lease specifies — or more?"
"What have I paid this year, and what's my current balance?"
The assistant answers by calling tools that do exact arithmetic in Python
(every amount is a Decimal,
never a float) and by comparing your ledger line-by-line to your lease —
instead of eyeballing a table in its context window and guessing.
Ask an LLM to "total my fees for Q2" or "check my rent against my lease" from a pasted statement and you get plausible, confidently-wrong numbers. LedgerMCP moves the numbers and the comparisons out of the prompt and behind tools:
The model decides what to ask (check_rent_charges, find_unexpected_charges, …).
LedgerMCP decides what the answer is, deterministically, in Decimal — and shows its work by quoting the exact lease text it relied on.
Related MCP server: Tenant Leasing Analytics
Renter-first workflow — import a rent ledger and a lease, then cross-examine.
Lease parsing (PDF) — heuristically extracts rent, deposit, term dates, due day, late-fee policy, recurring fees and parties, each with a confidence level and the source excerpt. The full lease text is retained so the assistant can read anything the heuristics miss.
Deterministic cross-examination — rent checks, unexpected-charge audits, deposit and late-fee comparisons, all exact.
Pluggable ledger parsers — CSV/TSV and the Excel "Full Ledger" rent-portal export out of the box; add QuickBooks/OFX/QIF/Xero by writing one small class.
SQLite storage with lossless Decimal (amounts stored as integer cents).
Classic analytics too — balances, category/monthly rollups, income statement, balance sheet.
MCP server (FastMCP) + a Typer CLI over one shared service layer.
Idempotent ledger imports, high test coverage, Ruff, Pyright, GitHub Actions CI.
Lease cross-examination
Tool | Description |
| One-call cross-examination: lease terms + every check + human-readable |
| Compare each month's rent charges to the lease's monthly rent. |
| Classify every charge category as expected / referenced / mismatch / unexpected. |
| Compare the deposit charged to the lease deposit. |
| Compare late fees charged to the lease late-fee policy. |
| Extracted lease terms, each with confidence + source excerpt. |
| Read the raw lease, or just the lines matching a query (pet rules, subletting…). |
Ledger analytics
Tool | Description |
| Filter by date, category, type, account, source, text, amount range. |
| Running balance for an account or the whole ledger, optionally as-of a date. |
| Net / inflow / outflow totals for a filtered set. |
| Spending grouped by calendar month. |
| Per-category rollup, ranked by spend. |
| Accrual-basis P&L for a period. |
| Assets / liabilities / equity as of a date. |
| The chart of accounts and each account's type. |
LedgerMCP uses uv.
git clone https://github.com/luke-nielsen/ledger-mcp.git
cd ledger-mcp
uv sync# 1. Import your rent ledger
uv run ledger-mcp import examples/sample_ledger.csv --db ledger.db
# 2. Import your lease
uv run ledger-mcp import-lease examples/sample_lease.pdf --db ledger.db
# 3. See what the lease says
uv run ledger-mcp lease --db ledger.db
# 4. Cross-examine ledger vs lease
uv run ledger-mcp lease-report --db ledger.dbThe bundled example intentionally shows a clean rent match, a late-fee discrepancy (lease says $75, ledger charged $50), and coverage gaps (a deposit and pet rent that were never charged):
LEASE vs LEDGER
Findings:
• 'Late Fee' charged $50.00 but lease specifies $75.00.
• Lease items not seen in the ledger: Security Deposit, Pet Rent.
• Late fees charged $50.00 but lease late fee is $75.00.
Rent check:
2026-04 charged $1,450.00 expected $1,450.00 [match]
2026-05 charged $1,450.00 expected $1,450.00 [match]
2026-06 charged $1,450.00 expected $1,450.00 [match]You can also import a real Excel rent-portal statement and your real lease:
uv run ledger-mcp import "full_ledger.xlsx" --db ledger.db
uv run ledger-mcp import-lease "my_lease.pdf" --db ledger.dbRun the MCP server and point any MCP client at it. For Claude Desktop, add to
claude_desktop_config.json:
{
"mcpServers": {
"ledger": {
"command": "uv",
"args": ["run", "ledger-mcp", "serve"],
"cwd": "/absolute/path/to/ledger-mcp",
"env": { "LEDGER_MCP_DB": "/absolute/path/to/ledger.db" }
}
}
}Then ask: "Does my ledger match my lease?" — the assistant calls
lease_ledger_report, relays the flags, and can drill in with check_rent_charges
or get_lease_text to quote the exact clause.
from ledger_mcp import LedgerService, Settings
service = LedgerService.from_settings(Settings.from_env(db_path="ledger.db"))
service.import_file("examples/sample_ledger.csv")
service.import_lease("examples/sample_lease.pdf")
report = service.lease_report()
for flag in report.flags:
print("•", flag)Lease PDFs are unstructured and vary wildly, so LedgerMCP splits the problem:
Extraction is heuristic but honest. Regex/keyword rules pull the common
fields; each extracted value carries a Confidence (high/medium/low)
and the verbatim excerpt it came from. Whatever isn't matched is simply
left unset.
The full lease text is retained, so a client can read anything the
heuristics miss via get_lease_text (pet policies, subletting, maintenance).
The comparisons are deterministic. Every check below is exact Decimal arithmetic over stored data — the terms may be fuzzy, but the math isn't:
Check | What it does |
Rent | Sums each month's rent charges and compares to the lease's monthly rent (match / over / under / missing). |
Charge audit | Matches each charge category to base rent, the deposit, a named lease fee, or a mention in the lease text; anything else is unexpected. Flags amount mismatches. |
Deposit | Compares the deposit charged in the ledger to the lease deposit. |
Late fees | Compares late fees charged to the lease late-fee amount and grace period. |
Notes:
National Apartment Association (NAA) leases — the most common US apartment lease — are handled by a dedicated extractor. Signed NAA packets are flattened forms whose fill-in values are detached from their labels in the text, so LedgerMCP reads the reliably-anchored fields (base monthly rent, landlord, tenants, address, effective date) and leaves the positionally ambiguous ones (deposit, late fee) for
get_lease_textrather than guessing.Scanned/image-only PDFs have no text layer; OCR is out of scope and such files are reported with a clear error. Export a text-based PDF if you can.
For unusual leases, lean on
get_lease_textand the confidence levels.
Every source line normalizes to one EntryType, signed by a single rule:
| Meaning | Sign on balance |
| Billed to you |
|
| You paid |
|
| Concession/discount in your favour |
|
| Money returned to you |
|
| Manual correction |
|
A positive ledger balance means money is owed.
The default ClassificationRuleset reflects a renter's perspective: charges →
one expense account per category, concessions → income, payments/refunds
→ a liability (Accounts Payable). Override per category — e.g. treat a
security deposit as an asset:
from ledger_mcp import ClassificationRuleset, AccountType
ruleset = ClassificationRuleset(category_overrides={"security deposit": AccountType.ASSET})Layers are decoupled so each is independently testable and swappable:
ledger files ─▶ parsers ─▶ RawEntry ─▶ validate + normalize + classify ─▶ Transaction ─┐
▼
lease PDF ─────▶ lease.pdf ─▶ lease.extract ─▶ LeaseTerms ─────────────────▶ SQLite (SQLAlchemy)
│
┌────────────────────────────────────────────────────────────── ┘
▼
analytics + lease.review (cross-examination)
│
▼
LedgerService ← shared by the MCP server & CLIModule | Responsibility |
| Read ledger formats → |
| Canonical Pydantic models, enums, sign convention. |
| Map entries onto a chart of accounts and apply signs. |
| Semantic checks + reconciliation against reported balances. |
| The parse → validate → normalize → persist pipeline. |
| SQLAlchemy schema, engine, repositories. |
| PDF text extraction, heuristic term extraction, storage, and cross-examination. |
| Deterministic Decimal queries and statements. |
| Application facade owning session lifecycle. |
| FastMCP server exposing the tools. |
from pathlib import Path
from ledger_mcp.models import RawEntry
from ledger_mcp.parsers import ParseResult, default_registry
class QifParser:
name = "qif"
def can_parse(self, path: Path) -> bool:
return path.suffix.lower() == ".qif"
def parse(self, path: Path) -> ParseResult:
entries: list[RawEntry] = ... # read the file
return ParseResult(entries=entries, source_name=path.name, parser=self.name)
default_registry.register(QifParser())Validation, classification, storage, analytics and lease cross-examination are all format-agnostic, so nothing else changes.
uv sync
uv run pytest # tests
uv run ruff check . # lint
uv run ruff format . # format
uv run pyright # type checkCI (.github/workflows/ci.yml) runs lint, type-check and tests on every push and PR.
Variable | Meaning | Default |
| SQLite path or SQLAlchemy URL |
|
The CLI --db flag overrides the environment.
Everything runs locally. Your ledger and lease live in a local SQLite file; no
data leaves your machine. The bundled examples/ are synthetic.
MIT — see LICENSE.
Compare late fees charged in the ledger to the lease late-fee policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only says 'compare' but fails to mention if the tool makes any changes, requires permissions, or has side effects. For a tool that likely reads data, stating it is read-only would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose. No redundant words or unnecessary details are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no annotations, and the presence of an output schema, the description is mostly adequate. However, with 15 sibling tools, a bit more context on specific use cases or when to prefer this tool would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema covers 100% (empty). The description adds value by explaining the tool's purpose beyond the schema. However, since there are no parameters, the baseline is 4, and the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('compare') and the specific resources ('late fees charged in the ledger' vs 'lease late-fee policy'). It effectively distinguishes this tool from siblings like 'check_rent_charges' and 'check_security_deposit' by focusing on late fees and policy comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying late fees against policy but provides no explicit guidance on when to use this tool versus alternatives (e.g., compare-late-fees to policy vs. just listing fees). With many sibling tools, additional context on when not to use it or specific scenarios would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare each month's rent charges in the ledger to the lease's monthly rent.
Flags months that are overcharged, undercharged or missing a rent charge.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the basic comparison and flagging but does not disclose whether it modifies data, what output format is, prerequisites, or rate limits. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. No unnecessary words—every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks parameter semantics and usage guidance. With no annotations and no schema descriptions, the agent is missing key context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has two optional parameters 'start' and 'end' with 0% description coverage. The description does not mention these parameters at all, leaving the agent unable to infer their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it compares rent charges to lease monthly rent and flags overcharges, undercharges, or missing charges. This distinguishes it from sibling tools like 'check_late_fees' or 'check_security_deposit'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to check rent charges vs lease), but does not explicitly mention when not to use or suggest alternatives. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare the security deposit charged in the ledger to the lease deposit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'compare' without clarifying if the operation is read-only, modifies data, or requires specific permissions. The return format or side effects are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the tool's purpose. Every word is necessary, and it is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters), the description is adequate but lacks explanation of the output (e.g., whether it returns a boolean, difference, or report). The existence of an output schema suggests more detail could be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The schema coverage is trivially 100%. The description does not add parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: comparing security deposit charged in the ledger to the lease deposit. It uses a specific verb-resource pair ('compare...security deposit...to lease deposit') and distinguishes itself from sibling tools like 'check_late_fees' and 'check_rent_charges'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'get_lease_summary' or 'find_unexpected_charges'). The description does not indicate prerequisites or situations where this tool is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit every ledger charge category against the lease.
Classifies each category as expected (rent/deposit/named fee), referenced (mentioned in the lease text), amount_mismatch, or unexpected (not found in the lease at all), and lists lease items never charged.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly explains the classification logic (expected, referenced, amount_mismatch, unexpected) and mentions listing lease items never charged. However, it does not explicitly state whether the tool is read-only or if it has side effects, which would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the overall purpose, and the second provides the detailed classification scheme, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description is complete. It explains what the tool does and how it classifies charges, which suffices for an agent to understand its function. The output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and schema description coverage is 100%, so the description does not need to add parameter information. The absence of parameters is handled correctly, and the description focuses on the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits every ledger charge category against the lease, classifying each as expected, referenced, amount_mismatch, or unexpected. This specific verb+resource combination distinguishes it from sibling tools like check_late_fees or check_rent_charges, which focus on specific categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a comprehensive audit of all charge categories, but it does not explicitly state when to use this tool versus alternatives. No exclusions or direct comparisons to sibling tools are provided, leaving the agent to infer context from the tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the running balance for an account, or the whole ledger.
Omit account for the overall outstanding balance. as_of (YYYY-MM-DD)
limits to transactions on or before that date.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| account | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses parameter behavior (date format) but does not mention side effects, authentication needs, rate limits, or that it is a read-only operation. The behavioral scope is partially inferred but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose. Every word contributes meaning. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameter usage adequately. An output schema exists, so return values are documented elsewhere. However, given the rich set of sibling tools, it lacks guidance on when to choose this tool over similar ones (e.g., lease_ledger_report, sum_transactions). Some aspects like pagination or performance are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), but the description adds clear semantics: omitting account returns overall balance, and as_of must be YYYY-MM-DD and limits transactions. This compensates for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'running balance for an account, or the whole ledger'. It distinguishes two use cases (with or without account) and uses specific terminology ('running balance', 'overall outstanding balance').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions for parameter usage: omit account for overall balance, and use as_of for date limiting. However, it does not guide when to use this tool versus siblings like get_balance_sheet or sum_transactions, missing exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Balance sheet (assets, liabilities, equity) as of a date.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions timing (as of a date). Does not disclose required permissions, data source, or if results are aggregated across entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (5 words), but at the expense of completeness. Could be front-loaded but lacks structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too minimal. Does not mention typical use cases, report scope, or any caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description adds no detail on format or behavior of 'as_of' (e.g., if null, returns most recent balance sheet). The schema's default null is uninterpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a balance sheet with assets, liabilities, and equity as of a date, distinguishing it from siblings like get_income_statement which covers a period.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs. alternatives (e.g., income statement for performance). Does not mention that this is a snapshot for a single date.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accrual-basis income statement (profit & loss) for a period.
start/end are inclusive ISO dates; omit for all data.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions 'accrual-basis' but does not clarify what that entails (e.g., revenue recognition timing), nor does it address authentication needs, rate limits, data freshness, or error handling. The tool is presumably read-only, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the tool's purpose, and then explains the parameters efficiently. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations but does have an output schema (which may document return values), the description covers the essential purpose and parameter usage. However, it lacks behavioral context (e.g., accrual meaning, period handling edge cases) that would help an agent use it correctly, making it adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning by stating that 'start' and 'end' are inclusive ISO dates and can be omitted for all data. However, it does not specify the exact date format (e.g., YYYY-MM-DD) or provide examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides an accrual-basis income statement (profit & loss) for a period, using a specific verb ('get') and resource ('income statement'). It distinguishes itself from sibling tools like 'get_balance_sheet' by explicitly naming the financial statement type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the date parameters (inclusive ISO dates, omit for all data) but does not provide explicit guidance on when to use this tool versus alternatives (e.g., cash-basis reporting, other financial statements). Usage context is implied but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the lease terms extracted from the tenant's lease.
Returns rent, deposit, term dates, due day, late-fee policy, recurring fees and parties — each with a confidence level and the source excerpt it was read from. Low-confidence values should be verified with get_lease_text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the behavioral trait that returned values have confidence levels and source excerpts, which is useful beyond a simple 'Get'. No annotations exist, but the description adequately communicates read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no redundant information. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters, the description gives a full picture of what the tool returns (rent, deposit, etc.) and directs to an alternative when confidence is low. Output schema exists, so no need to detail return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4. Description adds no parameter info, which is fine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves extracted lease terms (rent, deposit, etc.) with confidence levels and source excerpts. It distinguishes itself from sibling get_lease_text by mentioning verification of low-confidence values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use get_lease_text for low-confidence values. However, it does not contextualize when to use this tool over other siblings like check_late_fees or check_rent_charges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the raw lease text, or only the lines matching query (with context).
Use this to answer questions the structured terms don't cover (pet rules, subletting, maintenance) or to verify an extracted value against the source.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Read' implies non-destructive behavior. It mentions the filtering and context for query results, but lacks details on output format or behavior when query is null. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences, no wasted words. First sentence states the action, second provides usage guidance. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description covers the main purpose, usage scenarios, and basic behavior. It could mention what happens when query is null (returns whole text) or define 'context' more precisely, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains that the 'query' parameter filters lines and returns them with context, adding meaningful information beyond the schema's type definition. It could be more precise about the query syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the raw lease text', a specific verb+resource. It also specifies optional query filtering and provides concrete use cases (pet rules, subletting, maintenance, verification). This distinguishes it from sibling tools, which are all financial/accounting related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to answer questions not covered by structured terms or to verify extracted values. It gives context but does not explicitly mention when not to use it or list alternatives, though the sibling tools are clearly different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full lease-vs-ledger cross-examination in one call.
Bundles the lease terms, rent check, charge audit, deposit and late-fee
checks, plus a flags list of human-readable findings to relay to the user.
Start here for open-ended questions like 'is my ledger consistent with my lease?'.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states that the tool returns a 'flags' list of human-readable findings, implying a read-only report. However, it doesn't disclose potential side effects, authentication needs, or rate limits, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long: the first packs the tool's comprehensive nature, the second provides usage context. No superfluous words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return format doesn't need full explanation) and only two optional parameters, the description covers the tool's purpose and bundling. It lacks parameter documentation, but the overall context is adequate for a report tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (end, start) with 0% description coverage, and the tool description does not mention them at all. The agent must infer that these are date-range filters from their names, which is insufficient for precise invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a comprehensive lease-vs-ledger cross-examination bundling multiple checks (lease terms, rent, charges, deposit, late fees) and returning findings. It distinguishes itself from sibling tools like check_late_fees or check_rent_charges by being an all-in-one report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Start here for open-ended questions like is my ledger consistent with my lease?', providing clear guidance on when to use it. While it doesn't mention when not to use it or list alternatives, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the chart of accounts with each account's type.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only states the output (accounts with types) and omits details like whether all accounts are returned, any default ordering, or potential pagination. For a simple read tool, more context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with nine words, providing all essential information without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the simplicity of the tool (0 parameters), the description adequately explains the main output. It could hint at the scope (e.g., 'all accounts in the organization'), but it is largely complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the description naturally need not add parameter meaning. The baseline for 0-parameter tools is 4, and the description meets that well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the chart of accounts with each account's type, using a specific verb and resource. It distinguishes itself from sibling tools like get_account_balance or get_balance_sheet by focusing on the full list of accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. It is implied that this tool is for retrieving the full chart of accounts, but no exclusions or alternatives are mentioned, which would help an agent choose among siblings like search_transactions or get_account_balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total spending (charges/expenses) per calendar month.
Optionally restrict to a year and/or category.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| category | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior, but it is minimal. It omits details on data range, ordering, default filters, whether accounts are aggregated, or output format, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two front-loaded sentences. It wastes no words, though it could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description is mostly adequate but omits default behavior when no filters are applied and does not clarify scope across accounts. It meets minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context that the parameters are for restriction, which the schema (with 0% property descriptions) lacks. However, it does not provide format specifics, valid values, or interaction semantics (e.g., AND vs OR).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides total spending per calendar month, which is a specific aggregation. However, it does not explicitly differentiate from sibling tools like sum_transactions or transactions_by_category, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions optional restriction by year and category but provides no guidance on when to use this tool versus alternatives like check_late_fees or get_balance_sheet. No conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ledger transactions with flexible filters.
Filters combine with AND. entry_types accepts charge/payment/credit/
refund/adjustment. Amount bounds apply to the signed amount. Returns the
matching transactions (newest first) and a count.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| limit | No | ||
| source | No | ||
| account | No | ||
| date_to | No | ||
| date_from | No | ||
| categories | No | ||
| max_amount | No | ||
| min_amount | No | ||
| entry_types | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that filters combine with AND, entry_types has specific allowed values, amount bounds apply to the signed amount, and results return newest first with a count. This adds significant behavioral context beyond the empty schema descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with clear structure. The first sentence states the purpose, and the second provides key details in a bullet-like format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no schema descriptions, and an output schema, the description covers the essential behavioral aspects (AND combination, entry_types, amount bounds, ordering, count). It lacks details on some parameters but leverages the output schema to convey return structure, resulting in good overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains entry_types values and the fact that amount bounds apply to signed amount. Other parameters (text, source, account, dates, categories, limit) are not described. This adds partial meaning but is insufficient for 10 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches ledger transactions with flexible filters. The verb 'search' combined with the resource 'ledger transactions' is specific. It distinguishes from siblings by emphasizing filtering capability, which is not present in tools like sum_transactions or get_account_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: for flexible filtering of transactions. It explains that filters combine with AND and lists acceptable values for entry_types, but does not explicitly mention when not to use or name alternatives. Given sibling tools have different purposes, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sum a filtered set of transactions.
Returns net (signed total), outflow (charges) and inflow
(payments/credits) magnitudes, and a count.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| source | No | ||
| account | No | ||
| date_to | No | ||
| date_from | No | ||
| categories | No | ||
| entry_types | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It reveals that the tool returns aggregated magnitudes and a count, implying a read operation. However, it does not explicitly state that it is read-only, mention any rate limits, authentication needs, or effects on data. The presence of an output schema partially compensates, but more transparency about permissions or side effects would be beneficial. Score 3 is reasonable as it adds some context beyond the schema but lacks completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that directly state the purpose and return value. No redundant or extraneous information. It is well-structured and front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description neglects to explain the filter parameters or any constraints. With 7 optional parameters and no guidance on valid values, format, or behavior when omitted, the description is incomplete for an agent to use effectively. For example, it does not clarify that 'text' likely searches transaction descriptions or that 'date_from' and 'date_to' are date strings. The sibling tools suggest a financial domain, but the description lacks sufficient context to distinguish filter fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation for any of the 7 parameters. With 0% schema description coverage, the parameters are entirely self-documenting (names only). The description only covers return fields, not what each parameter does (e.g., format for date_from, expected values for categories). This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: summing a filtered set of transactions. It specifies the return fields (net, outflow, inflow, count), which distinguishes it from sibling tools like search_transactions (which returns individual transactions) and monthly_spending (time-series aggregation). The verb 'Sum' and resource 'transactions' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives, such as when a total is needed vs. individual transaction details, or how it compares to monthly_spending or transactions_by_category. There are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarise activity per category, ordered by spending descending.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | No | ||
| date_from | No | ||
| entry_types | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the output ordering (descending by spending) but omits crucial behavioral traits: what 'summarise activity' means (counts, totals?), what happens with empty results, or whether it requires authentication. The lack of detail leaves the agent uninformed about side effects or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but conciseness comes at the cost of completeness. It could be restructured to include parameter context without being verbose. An average score is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three optional parameters and no schema descriptions, the description is insufficient. It does not explain how to use the parameters to filter or vary the summary. The presence of an output schema reduces the need to describe return values, but parameter information is critically missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the three parameters (date_to, date_from, entry_types). It fails to do so, offering no clue about their purpose, format, or default behavior. This is a major gap for agent decision-making.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarizes activity per category and orders by spending descending. It uses a specific verb and resource, and distinguishes from siblings like search_transactions or monthly_spending by focusing on category-level aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., monthly_spending might also categorize). No when-not-to-use or prerequisites mentioned. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0check_late_feescheck_rent_chargescheck_security_depositfind_unexpected_chargesget_account_balanceget_balance_sheetget_income_statementget_lease_summaryget_lease_textlease_ledger_reportlist_accountsmonthly_spendingsearch_transactionssum_transactionstransactions_by_categoryEach tool has a clearly distinct purpose: separate audit checks for late fees, rent, deposit, and unexpected charges; distinct financial statements; lease retrieval and report generation; and various transaction queries. No two tools overlap significantly in function.
Most tools follow a verb_noun pattern (e.g., check_rent_charges, get_balance_sheet, search_transactions). Exceptions include monthly_spending (adjective+noun) and transactions_by_category (noun_preposition_noun), but these are still clear and predictable.
With 15 tools, the set is well-scoped for a domain covering lease analysis, ledger auditing, financial reporting, and transaction search. Each tool serves a specific purpose without unnecessary bloat or gaps.
The tools cover the full lifecycle of lease-vs-ledger analysis: reading lease terms (summary and raw text), checking each major component (rent, deposit, late fees, unexpected charges), generating financial statements, and querying transactions with multiple filters and aggregations. The convenience tool lease_ledger_report bundles the core checks, making the surface complete for its intended use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ask your Rent Manager portfolio anything: live, read-only financials, rent roll, leasing.
Lease analysis: flag illegal/risky clauses by jurisdiction (ontario, bc, nyc, texas, general).
Extract verified data from CRE rent rolls and T12 operating statements (PDF, Excel, CSV, scans)
Messy spreadsheets in, clean checkable tables out. Every result carries its arithmetic proof.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/luke-nielsen/ledger-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server