Depreciation calculator for tax and bookkeeping, for small businesses, landlords and bookkeepers.
Scored across 2 tools
The two tools have clearly distinct scopes: one for a single asset and one for multiple assets/register. Their descriptions explicitly cross-reference each other with 'do not use' guidance, making misselection unlikely.
Both names follow a snake_case verb_noun pattern (calculate_depreciation, generate_depreciation_schedule). The second is longer and adds 'schedule', but the convention is still predictable.
Two tools is thin for a depreciation server, though the split between single-asset and batch-asset use is logical. The surface feels minimal rather than well-scoped.
Core depreciation workflows are covered: single asset, multi-asset schedules, several methods, MACRS, and downloadable outputs. Section 179, bonus depreciation, ADS, and dispositions are explicitly excluded, which is a reasonable boundary but leaves some common tax-depreciation gaps.
Use this when the user wants a depreciation calculator result for one asset: a straight-line depreciation schedule, double declining balance or 150% declining balance, sum-of-the-years' digits, units of production, or a MACRS depreciation calculator result for a computer, vehicle, equipment, rental property (27.5-year) or commercial building (39-year). Only cost is required; method, life or property class, salvage value and date placed in service are optional with stated defaults. Returns the year-by-year schedule (depreciation, accumulated depreciation, book value) to the cent, and PDF, Excel and CSV downloads. Does not model Section 179, bonus depreciation, ADS or dispositions, and is not tax advice. Do not use for several assets (use generate_depreciation_schedule).
| Name | Required | Description | Default |
|---|---|---|---|
| cost | No | Required. Cost basis of the asset (purchase price plus sales tax, shipping and installation), e.g. 25000 or "$25,000". For a building, leave out the land value. | |
| name | No | Asset name or description, e.g. "Dell laptop" or "Rental house at 12 Oak St". Also used to pick a MACRS class or a default life when none is given. | |
| method | No | Depreciation method: straight_line (default), double_declining (200% declining balance), 150db, declining_balance, sum_of_years, units_of_production, or macrs (US tax, IRS Pub 946 tables). Synonyms like "DDB", "SYD", "tax" work. | |
| convention | No | First-year convention. MACRS: half_year (default) or mid_quarter; real property always uses mid_month. Book methods: full_month (default, the month placed in service counts), mid_month, half_year or full_year. | |
| land_value | No | Land value included in cost, e.g. 70000 for a house bought with its lot. It is taken out of the basis because land is not depreciable. | |
| units_total | No | Units of production only: estimated total lifetime units, e.g. 100000 (miles, hours or pieces). | |
| salvage_value | No | Salvage (residual) value at the end of the life, e.g. 2000 or "10%". Default 0. Ignored by MACRS. | |
| declining_rate | No | Declining balance rate in percent: 200 (default, double declining), 150 or 125. | |
| property_class | No | MACRS GDS recovery period: 3, 5, 7, 10, 15, 20, 27.5 (residential rental) or 39 (nonresidential real property), or words like "residential rental", "computer", "office furniture". | |
| units_per_year | No | Units of production only: units used each year starting with the year placed in service, e.g. [20000, 25000, 18000] or "20000, 25000, 18000". | |
| placed_in_service | No | Date placed in service, e.g. 2026-03-15, "March 2026" or 03/15/2026 (US order). Only the month and year matter. Default January of this year. | |
| useful_life_years | No | Useful life in years for book methods, e.g. 5 or "7 years" or "60 months". Default from the property class or the description, else 5. | |
| business_use_percent | No | Business-use percent of the asset, e.g. 80 for 80%. Default 100. Basis and salvage are scaled by it. | |
| switch_to_straight_line | No | Declining balance only: switch to straight-line when it gives more depreciation. Default true. |
| Name | Required | Description |
|---|---|---|
| asset | Yes | |
| summary | Yes | |
| currency | Yes | |
| schedule | Yes | |
| tax_note | Yes | |
| warnings | Yes | |
| downloads | Yes | |
| first_year | Yes | |
| assumptions | Yes | |
| years_count | Yes | |
| ending_book_value | Yes | |
| total_depreciation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds non-obvious scope boundaries the annotations cannot convey: no Section 179, no bonus depreciation, no ADS, no dispositions, and not tax advice, plus the fact that results are produced to the cent with PDF/Excel/CSV downloads. It does not discuss pagination or failure modes, but for a pure computation tool that is a minor omission.
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?
It is a single dense paragraph, but the order is well front-loaded: purpose, then optionality, then return values, then exclusions, then the sibling alternative. The long method enumeration is slightly list-like but each item is a genuinely distinct supported mode, so little could be cut without losing selection signal.
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?
For a 14-parameter tool with full schema coverage, existing annotations and an output schema, the description supplies what the structured fields cannot: scope, unsupported tax features, required-input minimum, and the sibling boundary. The only residual gap is that it does not flag the conditional requirement of units_total/units_per_year for units-of-production, though the schema descriptions do.
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 100%, so the baseline would be 3 regardless. The description still adds real meaning by sorting the 14 parameters into a required minimum (cost) versus optional ones with stated defaults (method, life or property class, salvage value, date placed in service), which tells the agent it can call the tool with almost no input. It does not re-explain individual parameter formats, which is appropriate since the schema does 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 names a specific verb and resource ('depreciation calculator result for one asset') and enumerates the supported methods (straight-line, 200%/150% declining balance, SYD, units of production, MACRS) plus the property classes covered. It explicitly differentiates from the sibling by restricting scope to a single asset and naming generate_depreciation_schedule for multi-asset cases.
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?
It opens with an explicit when-to-use cue ('Use this when the user wants a depreciation calculator result for one asset') and closes with a when-not-to-use rule plus the alternative tool to use instead. The prerequisites ('Only cost is required') tell the agent the minimum viable invocation, which is strong routing guidance for a 14-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants a depreciation schedule template filled in for several assets or a fixed asset register: a list of assets, pasted CSV, or an attached CSV/Excel file, each with cost, date placed in service and method (straight-line, declining balance, sum-of-the-years' digits, units of production or MACRS). Returns each asset's schedule, totals by year, the IRS 40% mid-quarter test for MACRS assets, and a PDF, Excel workbook and CSV. Rows that cannot be read are listed with the reason, never dropped silently. Does not model Section 179, bonus depreciation, ADS or dispositions, and is not tax advice. Do not use for a single asset (use calculate_depreciation).
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Optional fixed-asset list as a CSV, TSV or Excel .xlsx file with one asset per row, e.g. fixed-assets.xlsx. Columns like Asset, Cost, Date placed in service, Method, Life or Class, Salvage are detected from the headings. | |
| title | No | Title for the PDF and spreadsheet, e.g. "Acme LLC fixed assets 2026". | |
| assets | No | The assets: an array of objects with name, cost, placed_in_service, method, useful_life_years or property_class, salvage_value, e.g. [{"name":"Laptop","cost":2400,"placed_in_service":"2026-03-15","method":"macrs","property_class":5}]. Or pasted CSV / one asset per line text, e.g. "Laptop, 2400, 2026-03-15, 5-year". | |
| method | No | Default method for assets that do not name one, e.g. macrs or straight_line. | |
| convention | No | Default convention. For MACRS leave it out to let the 40% mid-quarter test decide per year, or pass half_year or mid_quarter. | |
| declining_rate | No | Default declining balance rate in percent, 200 or 150. | |
| placed_in_service | No | Default date placed in service for assets without one, e.g. 2026-01-01. | |
| useful_life_years | No | Default useful life in years for book methods, e.g. 5. |
| Name | Required | Description |
|---|---|---|
| assets | Yes | |
| by_year | Yes | |
| skipped | Yes | |
| summary | Yes | |
| currency | Yes | |
| tax_note | Yes | |
| warnings | Yes | |
| downloads | Yes | |
| asset_count | Yes | |
| assumptions | Yes | |
| skipped_count | Yes | |
| assets_not_shown | Yes | |
| mid_quarter_test | Yes | |
| total_cost_basis | Yes | |
| total_depreciation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantial context beyond them: what is returned (per-asset schedules, yearly totals, the IRS 40% mid-quarter test, PDF/Excel/CSV artifacts) and the silent-failure guarantee ('Rows that cannot be read are listed with the reason, never dropped silently'). It also discloses a precise modeling boundary (no Section 179, bonus depreciation, ADS, dispositions) and a 'not tax advice' caveat.
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?
Front-loaded with the trigger condition, followed by accepted inputs, outputs, then limitations and the exclusion — a logical order with no filler sentences. It runs long as a single dense paragraph, which slightly hurts scannability for a description this feature-rich.
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?
For an 8-parameter, nested-object tool with an output schema, the description covers the trigger, accepted input shapes, method vocabulary, output artifacts, error handling, and modeling limits. An agent has everything needed to select it and call it correctly, with return-value detail appropriately delegated to the output schema.
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 100%, so the baseline is 3, but the description adds real meaning the schema lacks: it enumerates the supported methods (straight-line, declining balance, sum-of-the-years'-digits, units of production, MACRS) for a free-string method parameter with no enum, and explains that omitting convention lets the 40% mid-quarter test decide per year. It does not restate every default parameter, which is appropriate given the schema.
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?
States a specific verb+resource (generate a depreciation schedule) and immediately scopes it to 'several assets or a fixed asset register', then names the sibling it is not for. An agent can distinguish it from calculate_depreciation without opening either schema.
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?
Explicit when-to-use ('Use this when the user wants a depreciation schedule template filled in for several assets'), including the three accepted input shapes, plus an explicit exclusion with a named alternative ('Do not use for a single asset (use calculate_depreciation)'). Nothing is left to inference about routing.
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.
calculate_depreciationgenerate_depreciation_scheduleA fixed asset register with depreciation from bundled Polish KST, HMRC and IRS MACRS tables.
Track Australian work-related tax deductions: expenses, assets, car trips and work-from-home days.
MACRS schedules, Section 179 and bonus depreciation with 2026 limits.
Log business expenses with the VAT split and mileage, total them, export CSV or XLSX.
Add one secure layer between your agents and this server.