Skip to main content
Glama

create_asset

Create a new asset in the estate. Use this when the user wants to add a bank account, property, vehicle, insurance policy, other asset, or a debt the estate owes. A same-named asset does NOT block creation (two accounts at the same institution are legitimate) — but if you created this exact asset moments ago, the tool returns the existing one instead of a duplicate. Use update_asset to change details of an existing asset. For eligible paid estates, adding an asset may start public-source research and add asset-specific tasks. Recent same-name assets may have empty fields filled instead of a duplicate being added. Repeating after the deduplication window may create another asset.

Input Schema

NameRequiredDescriptionDefault
notesNoAdditional notes about the asset (optional)
estate_idYesThe estate to act on. Call list_my_estates first to get this id.
asset_nameYesName or description of the asset (e.g. 'Chase Checking Account', '123 Main St'). Never put an account number in the name — use account_number.
asset_typeYesType of asset (use plural form to match database schema). When the customer named the kind of asset, use that type; ask before choosing a different one. 'debts_liabilities' = money the estate OWES (mortgage, credit card, medical bill, unsecured claim on a court schedule) — record the outstanding balance as a positive estimated_value. It is tracked in the Assets & Debts tab as a liability and is never counted as estate inventory.
jurisdictionNoState where the asset is located (optional, for real estate or vehicles)
account_numberNoAccount or policy number (optional)
customer_wordsNoRequired when marking a task completed or not_applicable, or setting bypasses_probate or has_beneficiary to true: the customer's own words stating that decision, quoted exactly from their message (e.g. "mark this not required", "I paid the filing fee", "it's payable on death to my brother"). Never your own conclusion. If they haven't stated the decision, don't call — ask them.
estimated_valueNoEstimated value in dollars (optional)
has_beneficiaryNoWhether the account or policy itself names a beneficiary (POD/TOD, life insurance, retirement). Not an heir of the estate. Set true only with the customer's words in customer_words — it leaves the asset out of the probate accounting (optional)
beneficiary_nameNoName of the beneficiary if known (optional)
bypasses_probateNoWhether this asset passes outside probate (e.g. POD/TOD accounts, joint tenancy with survivorship). Set true only when the customer has said it passes outside probate or named how (POD, TOD, joint with survivorship), with their words in customer_words. A mention of a "beneficiary" or a "joint" owner alone is not enough — ask how the asset is titled first.
date_of_death_valueNoThe asset's value at the date of death (the inventory value used for estate accounting and to compute gain/loss on sale). Set this at creation whenever you know it — for the decedent's own bank/investment accounts it is the balance at death, and it is what makes that balance flow into the Ledger's starting cash. If the user gives one figure for such an account and it is the date-of-death balance, set both this and estimated_value.
asset_type_confirmedNotrue only after the customer agreed to a different category than the one they named (e.g. they said "investment account" and then agreed it should be a retirement account). Never set it on your own.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / asset_name / description
      Previous value: -"Name or description of the asset (e.g. 'Chase Checking Account', '123 Main St')"New value: +"Name or description of the asset (e.g. 'Chase Checking Account', '123 Main St'). Never put an account number in the name — use account_number."
    • changedInput schema / properties / asset_type / description
      Previous value: -"Type of asset (use plural form to match database schema). 'debts_liabilities' = money the estate OWES (mortgage, credit card, medical bill, unsecured claim on a court schedule) — record the outstanding balance as a positive estimated_value. It is tracked in the Assets & Debts tab as a liability and is never counted as estate inventory."New value: +"Type of asset (use plural form to match database schema). When the customer named the kind of asset, use that type; ask before choosing a different one. 'debts_liabilities' = money the estate OWES (mortgage, credit card, medical bill, unsecured claim on a court schedule) — record the outstanding balance as a positive estimated_value. It is tracked in the Assets & Debts tab as a liability and is never counted as estate inventory."
    • addedInput schema / properties / asset_type_confirmed
      Added value: +{
      +  "description": "true only after the customer agreed to a different category than the one they named (e.g. they said \"investment account\" and then agreed it should be a retirement account). Never set it on your own.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / bypasses_probate / description
      Previous value: -"Whether this asset bypasses probate (e.g. POD/TOD accounts, joint tenancy) (optional)"New value: +"Whether this asset passes outside probate (e.g. POD/TOD accounts, joint tenancy with survivorship). Set true only when the customer has said it passes outside probate or named how (POD, TOD, joint with survivorship), with their words in customer_words. A mention of a \"beneficiary\" or a \"joint\" owner alone is not enough — ask how the asset is titled first."
    • addedInput schema / properties / customer_words
      Added value: +{
      +  "description": "Required when marking a task completed or not_applicable, or setting bypasses_probate or has_beneficiary to true: the customer's own words stating that decision, quoted exactly from their message (e.g. \"mark this not required\", \"I paid the filing fee\", \"it's payable on death to my brother\"). Never your own conclusion. If they haven't stated the decision, don't call — ask them.",
      +  "type": "string"
      +}
    • changedInput schema / properties / has_beneficiary / description
      Previous value: -"Whether the asset has a named beneficiary (optional)"New value: +"Whether the account or policy itself names a beneficiary (POD/TOD, life insurance, retirement). Not an heir of the estate. Set true only with the customer's words in customer_words — it leaves the asset out of the probate accounting (optional)"
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations by describing side effects the flags can't convey: adding an asset on an eligible paid estate may start public-source research and create asset-specific tasks, and recent same-name assets may get empty fields filled rather than duplicated. It also explains the dedup-window semantics behind idempotentHint=false, so the agent knows a later repeat can create a second asset.

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?

Front-loads purpose and the sibling disambiguation before the behavioral caveats, and most sentences earn their place. Minor redundancy: the dedup behavior is stated twice ("returns the existing one instead of a duplicate" and "Recent same-name assets may have empty fields filled instead of a duplicate being added"), which could be tightened.

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 13-parameter mutation with no output schema, the description covers the gaps that matter: side effects, dedup semantics, and the update-vs-create split. It stops short of saying what the call returns on success (e.g. the new asset id), which is the one thing an agent would still have to discover by calling.

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 coverage is 100%, so the baseline is 3. The description clarifies scope of asset kinds at a high level but adds no per-parameter meaning; the important guidance (customer_words, bypasses_probate, debts_liabilities, date_of_death_value) all lives in the schema descriptions. Adequate but not compensating beyond the schema.

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?

States a specific verb+resource ("Create a new asset in the estate") and enumerates the concrete asset kinds it covers (bank account, property, vehicle, insurance, debt). It also explicitly distinguishes itself from update_asset, so an agent can route without opening the sibling schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ("Use this when the user wants to add...") and names the alternative with its condition ("Use update_asset to change details of an existing asset"). It also resolves the exact ambiguity an agent would hit — creating a duplicate — stating that a same-name does not block creation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources