SwiftProbate

update_heir

Destructive

Update an existing heir's details. Use when the user wants to correct or add information to a recorded heir. Get the heir_id from the pre-loaded Heirs context block.

Input Schema

Name	Required	Description
`name`	No	Updated name exactly as the customer gave it. Never add a last name or any part they didn't give.
`email`	No	Updated email address (empty string clears it)
`notes`	No	Updated free-text notes about this heir (empty string clears). Use for context like whereabouts unknown, predeceased details, per-stirpes notes, disputes, or anything the user wants remembered.
`phone`	No	Updated phone number (empty string clears it)
`address`	No	Updated mailing address (empty string clears it)
`heir_id`	Yes	ID of the heir to update
`is_minor`	No	Whether the heir is under 18
`estate_id`	Yes	The estate to act on. Call list_my_estates first to get this id.
`is_deceased`	No	Whether the heir is deceased
`is_divorced`	No	For a spouse only: whether they are a divorced/former spouse (not a surviving spouse).
`relationship`	No	Updated relationship to the deceased. Canonical values: spouse, child, stepchild, grandchild, parent, sibling, other. Free-text wording (e.g. 'half-brother') is accepted and normalized automatically. "My brother" is the customer's brother, not the deceased's: ask before changing it.
`parent_heir_id`	No	ID of the heir this person inherits through (e.g. a grandchild's predeceased parent). Use it to fix or add that link; empty string removes it.
`name_from_document`	No	true when the new name was read from a document the customer shared rather than typed by them.
`relationship_detail`	No	The relationship exactly as the user described it, when it carries more than the canonical value (empty string clears it). Shown on probate forms.
`relationship_confirmed`	No	Required when changing relationship: true only when the customer has said or confirmed this person's relationship to the deceased (not to themselves), in this conversation or in a document they shared.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 1, 2026

changedInput schema / properties / name / description

Previous value: -"Updated full legal name"New value: +"Updated name exactly as the customer gave it. Never add a last name or any part they didn't give."

addedInput schema / properties / name_from_document

Added value: +{
+  "description": "true when the new name was read from a document the customer shared rather than typed by them.",
+  "type": "boolean"
+}

addedInput schema / properties / parent_heir_id

Added value: +{
+  "description": "ID of the heir this person inherits through (e.g. a grandchild's predeceased parent). Use it to fix or add that link; empty string removes it.",
+  "type": "string"
+}

changedInput schema / properties / relationship / description

Previous value: -"Updated relationship to the deceased. Canonical values: spouse, child, stepchild, grandchild, parent, sibling, other. Free-text wording (e.g. 'half-brother') is accepted and normalized automatically."New value: +"Updated relationship to the deceased. Canonical values: spouse, child, stepchild, grandchild, parent, sibling, other. Free-text wording (e.g. 'half-brother') is accepted and normalized automatically. \"My brother\" is the customer's brother, not the deceased's: ask before changing it."

addedInput schema / properties / relationship_confirmed

Added value: +{
+  "description": "Required when changing relationship: true only when the customer has said or confirmed this person's relationship to the deceased (not to themselves), in this conversation or in a document they shared.",
+  "type": "boolean"
+}

First observedOct 11, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the safety profile is covered upstream. The description adds only an implicit cue that this is a partial 'correct or add' edit rather than a full replacement; it never says whether omitted fields are preserved or how relationship_confirmed gating behaves. For a destructive 15-parameter mutation, that is a modest addition over the annotations.

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 short sentences with the purpose first, the triggering condition second, and the ID prerequisite last. No filler or restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 15 parameters, destructiveHint=true, and no output schema, an agent still has an open question the description could answer: are unspecified fields left untouched or cleared? The rich schema partly compensates for name/relationship semantics, but partial-update behavior and confirmation gating are only inferable.

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 description coverage is 100% and the per-parameter text is unusually rich (empty-string clears, canonical relationship values, relationship_confirmed requirement), so the schema carries the semantic load. The description only contributes the sourcing hint for heir_id from the pre-loaded Heirs context block.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Update an existing heir's details'), which cleanly separates it from create_heir and get_heirs. It doesn't name any sibling explicitly, so it falls short of full differentiation, but the mutation target is unambiguous.

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?

'Use when the user wants to correct or add information to a recorded heir' gives a clear triggering condition, and the second sentence supplies the prerequisite for heir_id. No alternatives or exclusions are named (e.g. use create_heir when the person isn't recorded yet), so it stops short of a 5.

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

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