stub

Create asset

create_asset

Create a new fixed asset — an item of equipment, property or similar that the business owns and depreciates over time. Use when recording a capital purchase you want to depreciate over its useful life rather than expensing outright; link it to the originating purchase via :expense (see list_expenses) so its cost basis flows from the ledger. To amend an existing asset use update_asset; to remove one use delete_asset.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Asset id. Required on update; omit on create.
`name`	No	Name of the asset (e.g. "Delivery van").
`notes`	No	Free-text notes about the asset.
`amount`	No	(Deprecated) legacy purchase value; the asset's cost now derives from its linked expense/transaction, so this is ignored.
`income`	No	Id of an income record linked to this asset (e.g. proceeds from its disposal).
`unlink`	No	(Legacy) id of a linked transaction to detach from the asset; prefer the dedicated unlink asset-transaction endpoint.
`expense`	No	Id of the expense record that recorded the asset's purchase (its cost basis).
`disposed`	No	Whether the asset has been disposed of (sold or retired).
`accountid`	No	Chart-of-accounts account id categorising this asset (see list_accounts).
`usefullife`	No	Useful life of the asset in years.
`transaction`	No	(Legacy) id of a bank transaction to associate with the asset; asset↔transaction links are normally managed via the dedicated link/unlink asset-transaction endpoints.
`depreciation`	No	Whether this asset depreciates over time.
`disposeddate`	No	Date the asset was disposed (ISO 8601); defaults to now when :disposed is set without a date.
`baseaccountid`	No	Chart-of-accounts account id for the asset's accumulated-depreciation / base account (see list_accounts).
`depreciationrate`	No	Annual depreciation rate as a decimal fraction (e.g. 0.2 = 20% per year); used by the diminishing-balance method.
`depreciationtype`	No	Depreciation method: a string containing "straight" (straight-line), "diminish" (reducing/diminishing balance), or "fifty" (50/30/20 wear-and-tear).
`depreciationstart`	No	Date depreciation starts (ISO 8601).
`usedefaultdepreciation`	No	Whether to use the business/category default depreciation settings instead of the values on this asset.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 8, 2026

addedInput schema / properties / transaction / description

Added value: +"(Legacy) id of a bank transaction to associate with the asset; asset↔transaction links are normally managed via the dedicated link/unlink asset-transaction endpoints."

addedInput schema / properties / unlink / description

Added value: +"(Legacy) id of a linked transaction to detach from the asset; prefer the dedicated unlink asset-transaction endpoint."

Changed16 schema fields changedSep 7, 2026

addedInput schema / properties / accountid / description

Added value: +"Chart-of-accounts account id categorising this asset (see list_accounts)."

addedInput schema / properties / amount / description

Added value: +"(Deprecated) legacy purchase value; the asset's cost now derives from its linked expense/transaction, so this is ignored."

addedInput schema / properties / baseaccountid / description

Added value: +"Chart-of-accounts account id for the asset's accumulated-depreciation / base account (see list_accounts)."

addedInput schema / properties / depreciation / description

Added value: +"Whether this asset depreciates over time."

addedInput schema / properties / depreciationrate / description

Added value: +"Annual depreciation rate as a decimal fraction (e.g. 0.2 = 20% per year); used by the diminishing-balance method."

addedInput schema / properties / depreciationstart / description
```
Added value: +"Date depreciation starts (ISO 8601)."
```

addedInput schema / properties / depreciationtype / description

Added value: +"Depreciation method: a string containing \"straight\" (straight-line), \"diminish\" (reducing/diminishing balance), or \"fifty\" (50/30/20 wear-and-tear)."

addedInput schema / properties / disposed / description

Added value: +"Whether the asset has been disposed of (sold or retired)."

addedInput schema / properties / disposeddate / description

Added value: +"Date the asset was disposed (ISO 8601); defaults to now when :disposed is set without a date."

addedInput schema / properties / expense / description

Added value: +"Id of the expense record that recorded the asset's purchase (its cost basis)."

addedInput schema / properties / id / description

Added value: +"Asset id. Required on update; omit on create."

addedInput schema / properties / income / description

Added value: +"Id of an income record linked to this asset (e.g. proceeds from its disposal)."

addedInput schema / properties / name / description

Added value: +"Name of the asset (e.g. \"Delivery van\")."

addedInput schema / properties / notes / description
```
Added value: +"Free-text notes about the asset."
```

addedInput schema / properties / usedefaultdepreciation / description

Added value: +"Whether to use the business/category default depreciation settings instead of the values on this asset."

addedInput schema / properties / usefullife / description
```
Added value: +"Useful life of the asset in years."
```

First observedSep 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate non-destructive write, and the description adds transparency by noting that the 'amount' field is ignored and that legacy link fields should be avoided in favor of dedicated endpoints. This gives the agent a realistic expectation of side effects.

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 a single well-structured paragraph that leads with the core purpose, then gives usage context and clarifies legacy vs. preferred fields. It avoids redundancy and is appropriately sized for the tool's complexity.

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 absence of an output schema, the description sufficiently covers what the tool does and key behavioral nuances (disposal, depreciation defaults, legacy fields). It doesn't enumerate every parameter, but the schema does, so the combination is complete.

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?

All 18 parameters have descriptions in the schema, and many include additional semantic context (e.g., depreciation type examples, default for disposeddate, decimal format for rate). This goes beyond basic parameter listing, helping the agent choose correct values.

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 creates a new fixed asset, elaborates on what qualifies as an asset, and distinguishes it from update/delete operations. It also explains the core behavior of linking to the originating expense for cost basis.

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 on when to use the tool (recording a capital purchase to depreciate) and references alternative endpoints for unlink operations. It could be slightly more explicit about not using it for non-capital expenses, but the context is clear enough.

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

All stub tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?