Plan Before You Die facts

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds two useful behavioural facts: results are 'sourced' (provenance) and include 'conditional review checkpoints', plus an explicit scope disclaimer about authority and form selection. It says nothing about how many deadlines are returned, whether results are date-sorted, or any jurisdiction caveats.

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?

Two short sentences with no filler, so it is size-appropriate. However the front-loaded clause references an undefined 'public calendar', forcing the agent to resolve an opaque comparison before it understands what the tool returns.

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?

With six required parameters, no output schema, and no annotations describing the result shape, the description carries the burden of explaining what comes back. It only vaguely mentions 'dates and conditional review checkpoints' and never explains which inputs condition which checkpoints, leaving an agent unable to predict the response.

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 67% and the description contributes no parameter meaning at all — notably date_of_death, a required input, has no schema description and no mention here. The agent must infer from the enum names which inputs drive which checkpoints; the description does not compensate for the coverage gap.

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 gives a verb ('Return') and a resource ('sourced dates and conditional review checkpoints'), which suggests a deadline/checkpoint lookup, but it defines the output only by reference to 'the public calendar' — a resource the agent cannot see. It never states that the tool computes after-death deadlines from date of death, state, will, spouse, executor status and assets, so the actual purpose is only implied by the title.

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 second sentence gives negative scoping — it does not establish who can act nor select a form — which implicitly routes the agent to siblings like agency_permissions and get_form. But there is no positive statement of when to call this tool versus readiness_checklist or state_rules, so usage is only inferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond annotations by clarifying that the output includes conditions and death limits and that selecting a situation 'never grants authority,' which prevents misuse.

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?

Two short sentences, front-loaded with the core action and followed by the key caveat. Every sentence earns its place with no repetition or wasted wording.

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, two-parameter enum-based tool with full schema descriptions and strong annotations, the description is largely complete. It explains what is returned and clarifies the authority limitation, though it does not describe output structure, which is less critical absent an output schema but still a minor gap.

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 both parameters have clear enum descriptions, so the schema already carries the main parameter burden. The description adds only a modest clarification that situation selects a reading focus and does not confer authority, which is useful but does not go beyond the schema substantially.

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 and resource: returning published agency routes with forms, conditions, incapacity, and death limits. It is clear what the tool does, though it does not explicitly name sibling alternatives such as state_rules or after_death_deadlines.

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?

Usage is implied by the phrase 'the situation selects a reading focus,' but the description gives no explicit when-to-use guidance or comparison to sibling tools. It also adds the useful caveat that the tool 'never grants authority,' but that is a behavioral clarification rather than routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value beyond them by disclosing the return payload: a plain-language purpose, the official link, and a step-by-step guide — meaningful since no output schema exists. It stops short of describing behavior for an unknown/invalid code (error vs. empty result).

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?

A single sentence with zero filler; the input (by code, with example) is front-loaded and the promised outputs follow immediately. Nothing is repeated from the title 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 one-parameter read-only lookup, the description covers the identifier format and what comes back, which is enough for an agent to call it correctly. The only remaining gap is edge-case behavior on an unrecognized code, which is minor given the annotated low-risk, idempotent profile.

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?

The schema documents only that "code" is a required string with 0% description coverage, so the description must compensate. It does so partially by supplying a format example ("CMS-10106"), but omits casing rules, whether alternative identifiers are accepted, or what a malformed code produces.

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?

States a specific verb+resource ("look up an official form") and gives a concrete identifier example ("CMS-10106"), making the resource distinguishable from siblings like state_rules or search_facts. It does not clarify its relationship to the sibling list_guides, even though the description says it returns "our step-by-step guide," leaving minor ambiguity about which tool surfaces guides.

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 phrase "by code" plus the example implies the invocation condition: you already have a form identifier. But there is no explicit when-not guidance, no statement about what to do if you only have a form name or topic (e.g., search_facts), and no mention of alternatives.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description does add scope-limiting behavior: it returns review conditions and timing rather than a definitive answer, and it explicitly 'does not choose a spouse option or an election,' which tells the agent not to treat the result as an election decision. It says nothing about how 'unsure' enum inputs are handled, which matters for a 12-param determination tool.

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?

It is short, but it opens with a low-value meta-statement about an 'existing sourced calculator' instead of front-loading what the tool determines. 'It does not choose a spouse option or an election' is also underspecified — an agent cannot tell what an 'election' refers to here.

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 12-parameter determination tool with no output schema, the description should at least characterize the shape of 'review conditions and timing' and note that optional/unsure inputs are tolerated. Instead it gives a one-line nod to returns and leaves the caller to infer the rest, which is adequate but thin.

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% with enums on 8 of 12 params, so the schema carries parameter meaning. The description only confirms that previous_dec31_balance is optional and only needed for dollar amounts, which is a marginal but real addition over the schema's own wording.

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 name and title identify the domain (inherited IRA rules/schedule) and the description adds that it returns 'review conditions and timing,' which hints at a rules/determination output. But the lead sentence — 'Use the existing sourced calculator' — describes an implementation choice rather than what the tool computes, and no sibling (state_rules, after_death_deadlines, readiness_checklist) is differentiated from it.

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?

'Use the existing sourced calculator' is a directive with no when-to-use condition and no named alternative, so an agent cannot tell when this beats state_rules or after_death_deadlines. The one real precondition given — dollar amounts need an optional prior December 31 balance — is useful but is a data requirement, not usage routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's only added behavioral context is 'with their short answers', which hints at the shape of returned content, but with no output schema the return structure and size remain unspecified.

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?

A single front-loaded sentence naming verb, resource, and content, with no filler. Nothing in it could be cut without losing scope information.

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-argument, read-only listing tool with a full annotation set, the description covers what is listed and roughly what each entry contains. A minor gap is that it never indicates whether the list is exhaustive or how the 'short answers' relate to the individual guide tools.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly does not waste space on inputs.

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?

States a specific verb (List) and resource (free guides and tools) scoped to planbeforeyoudie.app, and adds that each item carries a 'short answer'. That is enough for an agent to distinguish it from the sibling tools, which are all specific lookups (state_rules, get_form, search_facts) rather than catalog listings, though the description never says so.

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?

There is no explicit when-to-use statement and no mention of alternatives or follow-up tools. An agent can infer this is a discovery entry point into the guide catalog, but the description does not say how to use the results or when a sibling like get_form or search_facts would be the better call.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds useful shape information (25 checks, grouped by area), but says nothing about how the result is returned or whether checks carry completion state — modest added value on top of structured fields.

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?

A single front-loaded sentence with no filler — the identity of the standard and its structure come first. Every clause earns its place.

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?

With no parameters, no output schema, and annotations carrying the safety profile, the description covers enough to call the tool correctly. The remaining gap is minor: it does not state the return shape beyond 'grouped by area,' but nothing an agent needs in order to invoke it is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level gaps exist.

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 names the specific resource (the Family Readiness Standard, 25 checks grouped by area) and gives the domain condition it addresses (someone gets sick or dies). It is clearly distinguishable from siblings like list_guides or get_form, though the verb is implicit — it never says 'returns' or 'retrieves'.

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?

There is no guidance on when to call this versus alternatives such as list_guides, get_form, or search_facts. The description tells the agent what the content is but not the situation that selects it, leaving routing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value beyond that by disclosing what each result contains — official source, date checked, guide link — which matters because there is no output schema. It still omits result count, ranking, and empty-result behavior.

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?

Two sentences, zero filler. The subject matter and domain are front-loaded, and the second sentence carries the return-value information an agent needs. Nothing redundant with the title or schema.

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 single-parameter, annotated, read-only search with no output schema, the description covers purpose, domain boundaries, and result fields — enough to call it correctly. Minor gaps remain around result volume, ranking, and what happens with no matches.

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?

Only one parameter, and the schema already documents it at 100% coverage with concrete example phrasings ('medicare form for family'). The description contributes domain context but no additional syntax, normalization, or formatting guidance beyond the schema, so the baseline 3 applies.

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?

Names a specific verb ('Search') and a specific resource ('checked facts'), then scopes it with concrete domain examples (Medicare permission forms, Social Security, hospital stays, unclaimed money). This is far from a tautology, but it never explicitly distinguishes itself from adjacent siblings like get_form, state_rules, or agency_permissions.

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 domain framing implies when the tool is relevant, and the statement that results carry an 'official source' and 'date checked' hints it is a discovery-first tool. However, there is no explicit when-to-use/when-not guidance and no sibling is named as an alternative for narrower questions (e.g., a specific form fetch).

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value on top: the row returns conditions plus source passages stamped with official source and a checked date, and it explicitly disclaims decision-making authority. Missing only pagination/size or fallback behavior for sparse topics.

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?

Front-loaded with the return contract, then the topic menu, then the scope disclaimer. The topic list is long but its parenthetical glosses carry information the bare enum does not; trimming the glosses would cost comprehension.

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?

Since there is no output schema, the description correctly carries the burden of describing the return payload (conditions, passages, sources, checked date) and the scope limit. It does not say what happens for a valid state/topic pair with no published row, which is the one operational gap.

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% with both parameters enum-constrained, so the baseline is 3. The description goes beyond raw enum keys by glossing each topic in plain language ('who inherits without a will, from each state intestacy statute'), which helps an agent pick the right topic value.

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?

States a precise verb+resource ('Return the complete published state row') and scopes it to conditions and source passages with provenance metadata. The enumerated topic list makes clear what the row can contain, distinguishing it from narrative tools like search_facts or after_death_deadlines.

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?

Usage context is clear: fetch a reference row for a given state+topic, and the closing sentence carves out what it is NOT for (eligibility decisions, estate shares, individual legal results). No sibling tool is named as an alternative, so routing is inferred rather than explicit.

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