Skip to main content
Glama

update_estate

Destructive

Update high-level estate details that the user can correct after onboarding. Use this when the user mentions a fact that should be persisted (e.g. "actually there is a will", "the will is in the safe deposit box", "the case number is 2026-001234"). NOT for who the heirs are or what the estate owns — record a person with create_heir, an asset with create_asset, and when the user says the list is finished call mark_heirs_complete / mark_assets_complete. This is ALSO where you record the estate's OPERATING/checking account (the account the executor opens after death with the estate's EIN) — use estate_account_institution / estate_account_number, NOT create_asset. The operating account is not an estate asset. It is ALSO where you save the estate's IRS EIN (tax ID) — use the ein field, which is distinct from the court's case number (estate_number). Always confirm changes before calling. When changing deceased_state or deceased_county, follow the special jurisdiction-change flow described in the system prompt: explain that tasks are based on county of residence at time of death, confirm via suggest_actions, then after the update review and revise jurisdiction-affected tasks. Replaces supplied estate details. Resolving will status may remove the will-determination task and add succession tasks from local reference data.

Input Schema

NameRequiredDescriptionDefault
einNoThe estate's IRS Employer Identification Number (tax ID), formatted like '12-3456789'. The executor gets it from the IRS after death to open the estate bank account and file the estate's tax return (Form 1041). Save it here whenever the user shares their estate's EIN. This is NOT the court's case / estate number (that's `estate_number`) — do not confuse the two. Empty string clears it.
estate_idYesThe estate to act on. Call list_my_estates first to get this id.
will_statusNoWhether the deceased left a will. Use 'present' if there IS a will (testate), 'none' if there is NO will (intestate), or 'unsure' if it hasn't been determined yet (e.g. the user is still looking for one). This is the ONLY field for the will answer. When it changes away from 'unsure', the task list reconciles automatically (the 'find the will' task is removed; if 'none', succession tasks are added).
deceased_cityNoCity of the deceased's last address. Empty string clears it.
estate_numberNoThe probate case / estate number the county court (register of wills / clerk) assigns once the estate is opened (e.g. '2026-001234', 'PR-2026-5678'). Save this whenever the user says the court issued their estate, case, or file number — county offices require it on filed documents and it's used to fill court forms. NEVER store the estate's IRS EIN / tax ID here (EINs look like '12-3456789') — it is a different number with its own field; use `ein` for that. Empty string clears it.
executor_cityNoCity of the executor's mailing address. Empty string clears it.
executor_nameNoName of the user managing the estate (the executor / personal representative). Empty string clears it.
will_locationNoWhere the will is stored (e.g. 'safe deposit box at Wells Fargo', 'with attorney Smith'). Empty string clears it.
deceased_stateNoTwo-letter US state code where the deceased lived at time of death (e.g. 'CA', 'NY'). Must be a valid US state. Changing state invalidates county — you must also provide deceased_county in the same call.
executor_emailNoThe executor's email address for court forms. Empty string clears it.
executor_phoneNoThe executor's phone number, as the user gives it. The Form Assistant pre-fills it on every form. Empty string clears it.
executor_stateNoState of the executor's mailing address as a two-letter code (e.g. 'CA'). This is where the EXECUTOR lives — never change deceased_state for it. Empty string clears it.
deceased_countyNoCounty where the deceased lived at time of death (e.g. 'Los Angeles', 'Cook'). Must be non-empty. Use the bare county name without the word 'County'.
situation_notesNoDurable, estate-level narrative context that has no structured field of its own — the will situation (e.g. 'has a handwritten will from 2017, executed in CA, validity unconfirmed'), a pending claim (e.g. a partner's CIR claim), family dynamics, or other facts you'll need to remember later in this or a future conversation. This field is shown back to you in your Estate Context every turn. IMPORTANT: it is a single curated summary, NOT an append log — read the current Estate Notes in your context, fold the new detail in, and pass the FULL revised text (you are replacing the whole field, so don't drop anything still relevant). Keep it concise (a few sentences). Do NOT use it for facts that belong on a specific heir, asset, task, or ledger entry — use those records. Empty string clears it.
executor_capacityNoThe role the user is acting in, as the user states it: 'executor' (named in the will), 'administrator' (appointed by the court, no will), 'successor' (small-estate affidavit claimant) or 'petitioner' (has not been appointed yet). Only save what the user tells you — never pick one for them. Empty string clears it.
executor_legal_nameNoThe executor's full legal name exactly as it should appear on court filings (e.g. 'Lisa Marie Durjava'). The Form Assistant pre-fills it on every form. Distinct from executor_name, the informal name from onboarding. Empty string clears it.
deceased_postal_codeNoZIP code of the deceased's last address. Empty string clears it.
executor_postal_codeNoZIP code of the executor's mailing address. Empty string clears it.
estate_account_numberNoThe estate operating account's number, if the user provides it. Stored on the estate and masked in the UI. Empty string clears it.
executor_relationshipNoRelationship of the user managing the estate to the deceased
surviving_spouse_nameNoName of the surviving spouse. Empty string clears it. To record THAT there is a surviving spouse, add them with create_heir (relationship 'spouse') — that is what makes the fact definite in your Estate Context.
deceased_address_line1NoStreet address where the deceased LIVED at the time of death, including any apartment or unit (e.g. '12 Oak St Apt 4'). Save it with deceased_city and deceased_postal_code in the same call. Its state is deceased_state — do not change deceased_state to save an address. Forms pre-fill it. Empty string clears it.
deceased_date_of_birthNoDate of birth as ISO date (e.g. 1945-03-12). Empty string clears it.
deceased_date_of_deathNoDate of death as ISO date (e.g. 2026-01-15). Empty string clears it.
executor_address_line1NoStreet line of the executor's MAILING address (e.g. '7906 Joanna Court'). Save the whole address the user gives you in one call: executor_address_line1, executor_address_line2 (if any), executor_city, executor_state, executor_postal_code. The Form Assistant pre-fills it on every form. Empty string clears it.
executor_address_line2NoApartment, suite or unit of the executor's mailing address (e.g. 'Apt 4B'). Empty string clears it.
deceased_marital_statusNoMarital status of the deceased at time of death
estate_account_institutionNoWhere the estate's OPERATING/checking account is held (the account opened after death with the estate's EIN) — e.g. 'Quorum FCU', 'PNC Bank'. This is reference info, NOT an asset; never use create_asset for it. Empty string clears it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • addedInput schema / properties / deceased_address_line1
      Added value: +{
      +  "description": "Street address where the deceased LIVED at the time of death, including any apartment or unit (e.g. '12 Oak St Apt 4'). Save it with deceased_city and deceased_postal_code in the same call. Its state is deceased_state — do not change deceased_state to save an address. Forms pre-fill it. Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / deceased_city
      Added value: +{
      +  "description": "City of the deceased's last address. Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / deceased_postal_code
      Added value: +{
      +  "description": "ZIP code of the deceased's last address. Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / executor_address_line1
      Added value: +{
      +  "description": "Street line of the executor's MAILING address (e.g. '7906 Joanna Court'). Save the whole address the user gives you in one call: executor_address_line1, executor_address_line2 (if any), executor_city, executor_state, executor_postal_code. The Form Assistant pre-fills it on every form. Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / executor_address_line2
      Added value: +{
      +  "description": "Apartment, suite or unit of the executor's mailing address (e.g. 'Apt 4B'). Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / executor_capacity
      Added value: +{
      +  "description": "The role the user is acting in, as the user states it: 'executor' (named in the will), 'administrator' (appointed by the court, no will), 'successor' (small-estate affidavit claimant) or 'petitioner' (has not been appointed yet). Only save what the user tells you — never pick one for them. Empty string clears it.",
      +  "enum": [
      +    "executor",
      +    "administrator",
      +    "successor",
      +    "petitioner",
      +    ""
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / executor_city
      Added value: +{
      +  "description": "City of the executor's mailing address. Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / executor_email
      Added value: +{
      +  "description": "The executor's email address for court forms. Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / executor_legal_name
      Added value: +{
      +  "description": "The executor's full legal name exactly as it should appear on court filings (e.g. 'Lisa Marie Durjava'). The Form Assistant pre-fills it on every form. Distinct from executor_name, the informal name from onboarding. Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / executor_phone
      Added value: +{
      +  "description": "The executor's phone number, as the user gives it. The Form Assistant pre-fills it on every form. Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / executor_postal_code
      Added value: +{
      +  "description": "ZIP code of the executor's mailing address. Empty string clears it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / executor_state
      Added value: +{
      +  "description": "State of the executor's mailing address as a two-letter code (e.g. 'CA'). This is where the EXECUTOR lives — never change deceased_state for it. Empty string clears it.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Adds real context beyond the annotations (destructiveHint=true, idempotentHint=false): 'Always confirm changes before calling', the jurisdiction-change sequence, and the disclosure that resolving will status removes the will-determination task and adds succession tasks. The one gap is partial-update semantics — 'Replaces supplied estate details' does not clearly say that fields omitted from the call are left untouched, which matters for a destructive non-idempotent write with 28 params.

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-loaded with the core definition, then ordered by descending risk (exclusions, operating account, EIN, confirmation, jurisdiction flow). It is long, and the repeated 'It is ALSO where...' construction plus all-caps emphasis adds some noise, but nearly every sentence carries a routing or safety instruction.

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 28-parameter destructive write with no output schema, the description covers confirmation, side effects on tasks, and the ambiguous-field routing. It does not state what the tool returns or whether omitted fields are cleared, which is the remaining surface an agent needs for a safe non-idempotent update.

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 already 100%, so the baseline is 3; the description goes further by disambiguating the two highest-risk pairs (ein vs estate_number, estate_account_* vs create_asset) and by flagging the estate_number/estate asset boundary in prose the agent will read before the schema. It does not add much for the address and executor fields, but those are already fully self-describing.

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 first sentence states a specific verb and resource ('Update high-level estate details') plus the trigger condition ('that the user can correct after onboarding'). It then explicitly carves out what belongs elsewhere (create_heir, create_asset, mark_heirs_complete/mark_assets_complete), so an agent can separate it from all four siblings without opening a 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 positive triggers with concrete utterances ('actually there is a will', 'the case number is 2026-001234'), explicit exclusions ('NOT for who the heirs are or what the estate owns'), and named alternatives for each excluded case. It even routes two easily-misfiled facts (the operating account and the EIN) away from create_asset and estate_number with stated reasons.

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