Skip to main content
Glama
tillbooks

tillbooks

Official

asset_depreciation_run_create

Create a draft depreciation run for a period, calculating proposed depreciation for every eligible asset so a bookkeeper can review amounts before anything is posted.

Instructions

Create a DRAFT depreciation run for a period (H04): calculate the depreciation for every eligible asset via the H03 engine and persist a run header (status=draft) plus one line per asset that returned amount > 0, so a bookkeeper can review the proposed expense before anything hits the books. Eligible = status active/fully_depreciated, method != none, accumulated depreciation below cost minus residual, last_depreciation_period null or before the target period, not disposed. Optional filters narrow the set: assetIds (an explicit subset), categoryId, costCenterId. unitsByAsset maps assetId to the WHOLE units produced this period and is what makes a units_of_production asset depreciable at all (TILL captures no production data of its own, so the run carries it; same shape as asset_depreciation_preview, and values must be non-negative safe integers up to 1e12 or the create is invalid_input). skipped[] reports assets that produced NO line, as {assetId, assetNumber, reason}: on an EXPLICIT assetIds list every named asset that produced no line is reported (non_depreciable | asset_terminal | already_at_residual | period_already_processed | filtered_out | missing_production_data | missing_units_estimate | zero_amount), because naming an asset is an instruction about that asset; on a SWEEP the eligible register IS the selection, so only assets that reached the calculation are reported (missing_production_data | missing_units_estimate | zero_amount). A units_of_production asset named EXPLICITLY in assetIds is refused, not merely reported, when the input can be corrected: missing_production_data (no figure supplied) or missing_units_estimate (the asset carries no totalEstimatedUnits, so there is no denominator to allocate over). Nothing is written in either case. postingGranularity is detailed (one expense + one accum line per asset, the default) or summarised (grouped by account + cost centre); the per-asset lines exist either way for the sub-ledger audit. period is YYYY-MM. Refused with invalid_period, period_locked (the period is hard-locked in A03) or run_already_exists (a draft for the same period and selection already exists, and the response names it). Writes NO journal (the post verb does). Idempotent on idempotencyKey and on the (period, selection) signature, where the signature is built from the LINES the run would write (asset, amount and production figure), so two creates over the same eligible set yield ONE draft however the filters or the units map were spelled. When there is nothing to charge, NO run is persisted at all: the answer is {ok:true, run:null, lines:[], empty:true, skipped:[...]}, computed fresh, so it is identical on every call however many times it is repeated and whatever key each call carries. A run header exists only where at least one asset is charged, which is why a finished period never leaves an outstanding draft in run_list for a period-close checklist to trip over. Once a period is POSTED its assets carry it as their last depreciation period, so nothing is eligible and a later create for that period returns exactly that empty answer, carrying alreadyPostedRunId: the id of the most recently posted run for the period (two disjoint selections can both post for one period). A foreign assetId is not_found (§H-TENANT).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
periodYes
assetIdsNo
categoryIdNo
workspaceIdYes
costCenterIdNo
unitsByAssetNo
idempotencyKeyYes
postingGranularityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With zero annotations, the description carries the full burden and delivers richly: it discloses side effects (persists header and lines), non-effects ('Writes NO journal', 'Nothing is written in either case'), idempotency on both idempotencyKey and the (period, selection) signature, and the no-op empty outcome where 'NO run is persisted at all'. It even discloses state-transition behavior ('Once a period is POSTED its assets carry it as their last depreciation period') and error semantics (period_locked, run_already_exists, not_found §H-TENANT).

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?

Every sentence carries real operational meaning and the length is arguably justified by the tool's complexity (8 params, two filter modes, two granularities, many error codes). However, it is a single dense unbroken paragraph with no paragraph breaks or bullets, and there is some redundancy (the 'identical on every call' restatement of idempotency and the period-close checklist rationale). The size is appropriate; the structure is not.

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?

For a tool with 8 parameters, no annotations, and no output schema, the description covers eligibility, filters, skipped-reporting semantics, granularity, error codes, idempotency, and empty-run behavior in exceptional depth. The remaining gaps are the explicit success-case return shape (only the empty response {ok:true, run:null, lines:[], empty:true, skipped:[...]} is fully spelled out) and the thin treatment of workspaceId's scoping. These are minor but real contract gaps given the absence of an output schema.

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

Parameters5/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, and it does comprehensively: period is 'YYYY-MM'; unitsByAsset is defined as whole units produced with 'non-negative safe integers up to 1e12' and validation consequences; postingGranularity is explained as detailed vs summarised with sub-ledger implications; idempotencyKey's role is described; and assetIds/categoryId/costCenterId are identified as narrowing filters with distinct skipped-reporting semantics. Only workspaceId's tenant-scoping is left to the §H-TENANT cross-reference.

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 opens with a specific verb and resource ('Create a DRAFT depreciation run for a period (H04)') and states exactly what is persisted: a run header with status=draft plus one line per asset with amount > 0. It also distinguishes itself from its closest siblings by noting 'Writes NO journal (the post verb does)' and referencing asset_depreciation_preview for the unitsByAsset shape. An agent can unambiguously separate this from run_post, run_reverse, run_get, and preview.

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 draft-vs-post lifecycle is explicit ('so a bookkeeper can review the proposed expense before anything hits the books'; 'the post verb does'), which tells the agent when to call this tool versus asset_depreciation_run_post, and the full eligibility criteria define when a create is meaningful. However, there is no explicit 'use X instead when you don't want to persist' statement; the preview alternative is only implied via the shape reference.

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

Deploy Server

Other Tools