State document requirements for all 50 US states, an after-a-loss checklist, and a planning gap chec
Scored across 4 tools
Each tool targets a distinct purpose: assessing planning gaps, connecting an account, looking up state requirements, and getting post-loss steps. There is no overlap between them.
All tool names use a consistent verb_noun pattern (assess_, connect_, find_, get_). The only minor deviation is 'connect_finalpeace_account' which uses the product name rather than a generic noun, but the pattern remains predictable.
Four tools is a reasonable, focused set for a niche end-of-life planning assistant. It is slightly on the smaller side but each tool covers a distinct high-level need, so the count feels appropriate rather than thin.
The set covers assessment, state requirements, post-loss steps, and account connection, but there are notable gaps: no tools for actually creating or storing documents, updating plans, or managing vault contents directly. The account connection tool implies member-only features that are not exposed, leaving some workflows incomplete.
Score how prepared someone's end-of-life planning is and rank what is missing by consequence. Pass whichever answers are known; unanswered areas are reported back as questions to ask. Use this when someone wants to know where they stand, what to do first, or whether their planning has holes. No account needed.
| Name | Required | Description | Default |
|---|---|---|---|
| hasWill | No | Has a valid signed will | |
| hasFinancialPoa | No | Named someone to handle finances if incapacitated | |
| wishesAreRecorded | No | The people close to them know what they would want | |
| hasHealthCareAgent | No | Named someone to make medical decisions for them | |
| documentsAreFindable | No | Family could actually locate the documents | |
| beneficiariesAreCurrent | No | Account and policy beneficiary designations are up to date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint and mark it non-destructive; the description adds meaningful behavioral detail by explaining that partial inputs are allowed ('Pass whichever answers are known') and that unanswered areas are returned as questions. It also states 'No account needed,' covering authentication expectations beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose, then input behavior, then when-to-use guidance. Every sentence earns its place, and nothing redundantly repeats the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-optional-boolean read-only tool with no output schema, the description covers selection context, input flexibility, and the output shape at a high level: score, ranked gaps, and questions. It stops short of defining the score scale or exact response format, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all six booleans have clear individual descriptions, so the baseline is 3. The description adds one layer of cross-parameter meaning: callers may pass any subset of answers, and omitted booleans become follow-up questions rather than errors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb and object: 'Score how prepared someone's end-of-life planning is and rank what is missing by consequence.' This goes beyond a vague label and clearly differentiates the tool from siblings like find_state_document_requirements or get_after_loss_first_steps, which address different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'Use this when someone wants to know where they stand, what to do first, or whether their planning has holes.' That provides clear selection context, though it does not name exclusions or alternative sibling tools, so it falls just 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.
Explain how to connect an existing FinalPeace account so the member tools (vault contents, personal checklist progress, next steps) become available. Use this only if someone says they already have a FinalPeace account and wants their own data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description consistently describes an explanatory action rather than a mutation. It adds useful context that the tool unlocks member tools, but it does not disclose details such as credential requirements or the exact connecting workflow. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences with the purpose front-loaded and the usage condition placed second. Every word earns its place; there is no repetition of the title or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only explanation tool with annotations covering safety, the description supplies the trigger condition, scope, and result. The only conceivable addition would be guidance for users without an account, which is outside this tool's stated purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema imposes no burden and there is nothing for the description to clarify. The baseline of 4 applies because the description does not need to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Explain how to connect'), a specific resource ('existing FinalPeace account'), and the intended outcome ('member tools ... become available'). It is clearly distinct from the sibling tools, which concern estate-planning gaps, document requirements, and after-loss steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition: 'Use this only if someone says they already have a FinalPeace account and wants their own data.' It does not name an alternative tool for the opposite case, but the 'only if' phrasing acts as a clear exclusion gate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up what a specific US state legally requires to execute a will, financial power of attorney, health care proxy, or living will — how many witnesses, whether a notary is needed, who is barred from witnessing, and whether the state publishes an official form. Use this whenever someone asks what their state requires for estate planning or advance directive paperwork. Covers all 50 states. No account needed.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | US state as a two-letter code or full name, e.g. 'TX' or 'Texas' | |
| documentType | No | Omit to get requirements for all four document types in that state |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds useful non-obvious context by noting 'Covers all 50 states' and 'No account needed.' These are beyond the structured annotation fields and help the agent understand scope and authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: primary purpose and scope first, then usage trigger, coverage, and authentication note. Every sentence adds new information and there is no repetition of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with two well-documented parameters, the description covers the input scope, output categories, state coverage, and authentication needs. No output schema exists, but the description sufficiently conveys what information the agent should expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents state as two-letter code or full name and documentType as an omit-able enum. The tool description adds no additional parameter-specific semantics beyond what the schema already provides, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and identifies a clear resource: legal requirements for four named estate-planning document types by US state. It also lists the specific details returned (witnesses, notary, barred witnesses, official form), making it easy to distinguish from sibling tools like assess_estate_planning_gaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition: 'Use this whenever someone asks what their state requires for estate planning or advance directive paperwork.' It does not explicitly mention alternative sibling tools or when not to use this tool, so it falls just short of the highest guidance level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the practical checklist of what has to be done after someone dies, organized by when it actually matters: the first 24-48 hours, the first week, the first month, and ongoing. Use this when someone has recently lost a person and is asking what to do, what comes first, or what they might be forgetting. No account needed.
| Name | Required | Description | Default |
|---|---|---|---|
| phase | No | Omit to get all phases; pass one to focus on the immediate horizon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds useful context beyond annotations by disclosing that no account is needed and describing the checklist's time-based organization, which helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The main purpose is front-loaded, the usage trigger is stated clearly, and the auth note is compactly included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description provides everything an agent needs: content type, phase organization, trigger scenario, and access requirements. No output schema is necessary for a checklist resource this clearly described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already well documented. The description adds some meaning by elaborating the phases ('first 24-48 hours, first week, first month, and ongoing'), but does not substantially exceed what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get the practical checklist of what has to be done after someone dies') and clearly distinguishes this from siblings by focusing on immediate after-death action items rather than estate planning, account connection, or state document requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: when someone has recently lost a person and is asking what to do, what comes first, or what they might be forgetting. It does not name exclusions or alternatives explicitly, so it falls just 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
assess_estate_planning_gapsconnect_finalpeace_accountfind_state_document_requirementsget_after_loss_first_stepsUS legal documents matched to each state's law: leases, notices, NDAs, wills. PDF or Word.
US company filing obligations, plus a 25-check bookkeeping diagnostic. Sourced, dated, no signup.
US LLC filing fees, deadlines, and name checks for all 50 states — from official sources.
Contract drafting, statute-cited US state law requirements, non-compete checks, risk analysis.
Add one secure layer between your agents and this server.
