Skip to main content
Glama
Sign In

SwiftProbate

by com.swiftprobate
OverviewDiscussionsAdmin

update_asset

Destructive

Update an existing asset's details (name, type, value, jurisdiction, notes, etc.). Use this instead of creating a duplicate when the user wants to modify an asset — including when it was saved under the wrong type: change asset_type here rather than deleting and recreating it, which would wipe its tasks. To empty a field, list it in clear_fields.

Input Schema

NameRequiredDescriptionDefault
notesNoUpdated notes
asset_idYesID of the asset to update
estate_idYesThe estate to act on. Call list_my_estates first to get this id.
asset_nameNoUpdated name for the asset. Use this to correct a typo or add detail the user gave later (e.g. "Jeep Cherokee" → "2018 Jeep Cherokee Latitude Plus"). Renaming edits the existing row — do NOT create a second asset for the same item.
asset_typeNoCorrected type for the asset (same values as create_asset). Changing the type keeps the asset's linked tasks, documents and ledger entries.
dispositionNoWhat has happened to the asset: 'on_hand' (still in the estate), 'sold', 'transferred', or 'distributed' (given to an heir in kind). Record the sale proceeds as a money-in transaction in the Ledger linked to this asset.
clear_fieldsNoFields to empty when the user says a saved detail is wrong and there is no replacement (e.g. ["account_number"]). Clearing has_beneficiary or bypasses_probate marks it as not yet known. Do not also pass a new value for a field you clear.
jurisdictionNoUpdated state/jurisdiction
account_numberNoUpdated account/policy/VIN number
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_valueNoUpdated estimated value in dollars
has_beneficiaryNoWhether the account or policy itself names a beneficiary (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
beneficiary_nameNoName of the beneficiary
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).
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
    • addedInput schema / properties / asset_type
      Added value: +{
+  "description": "Corrected type for the asset (same values as create_asset). Changing the type keeps the asset's linked tasks, documents and ledger entries.",
+  "enum": [
+    "bank_accounts",
+    "investment_accounts",
+    "retirement_accounts",
+    "real_estate",
+    "vehicles",
+    "life_insurance",
+    "business_interests",
+    "personal_property",
+    "digital_assets",
+    "debts_liabilities",
+    "other"
+  ],
+  "type": "string"
+}
    • 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"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 / clear_fields
      Added value: +{
+  "description": "Fields to empty when the user says a saved detail is wrong and there is no replacement (e.g. [\"account_number\"]). Clearing has_beneficiary or bypasses_probate marks it as not yet known. Do not also pass a new value for a field you clear.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • 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"New value: +"Whether the account or policy itself names a beneficiary (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"
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, and the description adds real context beyond that: type changes preserve linked tasks, documents and ledger entries, while delete-and-recreate 'would wipe its tasks'. It still doesn't say the update is a full/partial replacement or that clearing a field is irreversible beyond the schema's own note.

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?

Three sentences, front-loaded with purpose then the sibling distinction then the clear_fields escape hatch. No restatement of the name and no filler.

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 16-parameter mutation with no output schema, the description covers the decisions that matter (update vs. recreate, type correction, clearing). It doesn't describe the return value or the customer_words gating for probate/beneficiary flags, leaving those to the schema.

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 coverage is 100%, so the baseline is 3; the description earns above that by explaining the clear_fields mechanism ('to empty a field, list it in clear_fields') and the consequence of asset_type, which are the two parameters most likely to be misused. It adds nothing for the remaining 14 params, which the schema already handles 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?

Specific verb plus resource plus the fields it touches (name, type, value, jurisdiction, notes), and it explicitly separates itself from create_asset ('use this instead of creating a duplicate'). An agent can tell it apart from the siblings without opening the 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?

States when to use it (modifying an existing asset), when not to (creating a duplicate, deleting and recreating), and names the corrective path for a wrong type — change asset_type here. It also routes field-emptying to clear_fields, which is otherwise a counterintuitive operation.

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

All SwiftProbate toolsInspect
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