ledger-mcp

by luke-nielsen

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.6/5 across 15 of 15 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
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 (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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
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 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ledger-mcp MCP server](https://glama.ai/mcp/servers/luke-nielsen/ledger-mcp/badges/card.svg)](https://glama.ai/mcp/servers/luke-nielsen/ledger-mcp)

Score Badge

Copy to your README.md:

[![ledger-mcp MCP server](https://glama.ai/mcp/servers/luke-nielsen/ledger-mcp/badges/score.svg)](https://glama.ai/mcp/servers/luke-nielsen/ledger-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/luke-nielsen/ledger-mcp'

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