estate-planning

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

No annotations provided, so the description carries the full burden. It discloses what is modeled (nil-rate band, residence nil-rate band, etc.) and what is excluded (lifetime-gift history). This is comprehensive for a calculation tool with no side effects. It could mention if results are cached or if it makes external calls, but that is likely unnecessary.

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: first defines purpose and rules, second clarifies limitations. No wasted words. Information is front-loaded with the core purpose.

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?

Given 15 parameters and no output schema, the description adequately covers the modeling scope and exclusions. It does not describe the return format (e.g., breakdown by bands), which would be helpful, but the main purpose and constraints are clear.

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 baseline is 3. The description adds value by explaining the overall modeling context (e.g., '£2m taper', '36% at 10%+'), which helps the agent understand how parameters interact beyond their individual descriptions.

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 specifies exactly what the tool does: estimate UK Inheritance Tax bill for 2025/26 with detailed rules listed. It distinguishes from sibling tools (e.g., check_rnrb, gift_7_year_timeline) by focusing on full IHT estimation rather than a specific aspect.

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 states 'Illustrative only — excludes lifetime-gift history,' setting clear expectation of scope and limitation. While it doesn't explicitly compare to sibling tools, the purpose is distinct enough that an agent can infer when to use it (IHT estimation) vs. other tools (gift timeline, care costs).

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?

With no annotations, the description carries the full burden. It transparently discloses the fee rate, remission/exemption conditions, and that it only covers registration fees. It could mention it's a read-only calculation with no side effects, but the provided information is sufficient.

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 a single, well-structured paragraph that front-loads the core purpose and then provides key details. Every sentence is informative and there is no redundancy or wasted words.

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?

Given the tool has 4 boolean/enum parameters and no output schema, the description fully explains the fee logic, conditions, and scope. It provides enough context for an agent to correctly invoke the tool and interpret results.

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 description adds significant meaning beyond the schema by explaining how each parameter affects the fee calculation: 'couple doubles document count', 'incomeUnder12k' for 50% remission, 'qualifyingBenefits' for full exemption. Schema coverage is 100% but the description enriches understanding.

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 clearly states it calculates OPG fees for registering LPAs, with specific fee amounts and conditions. It explicitly differentiates from drafting costs and suitability advice, distinguishing it from siblings like 'calculate_iht' or 'estimate_probate_cost'.

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 sets clear boundaries by specifying 'Registration fees only' and excluding drafting costs and suitability advice. While it doesn't explicitly state when to use this tool over alternatives, the scope is well-defined and implies its use for LPA registration fee calculations.

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?

The description discloses key behavioral traits without relying on annotations: it is 'guidance-only', returns 'yes/no/depends with blockers', includes an 'honest note that ALWAYS accompanies the result', and states that no tax outcome is promised. This provides the agent with a clear picture of what to expect.

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 concise (three sentences) and front-loaded with the main purpose. Every sentence adds essential information without redundancy.

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?

Given the tool has no output schema, the description adequately explains the return format (yes/no/depends with blockers), lists all eligibility conditions, and includes a disclaimer. It covers the necessary context for an agent to use the tool correctly.

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?

With 100% schema coverage, the baseline is 3. The description adds value beyond the schema by explaining the 'hard two-year window' and HMRC's stance on extensions, clarifying the deathTiming parameter, and mentioning 'goal-mapped possibilities' for the goal parameter.

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 clearly states the tool's main purpose: 'Check whether a deed of variation is available', with a specific verb and resource. It references the legal conditions under s.142 IHTA 1984, distinguishing it from sibling tools like calculate_iht or check_rnrb.

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 implies the use case: checking eligibility for a deed of variation. However, it does not explicitly state when not to use this tool or provide alternatives, leaving the agent to infer from context.

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?

With no annotations, the description carries full burden and clearly states the tool is indicative, returns a verdict with reasons and next steps, and warns that each institution sets its own threshold. This provides adequate transparency about limitations, though it does not explicitly confirm it is read-only (implied by 'check').

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 paragraphs with the core action in the first sentence. It is efficient and front-loaded, though the caveat sentence could be slightly trimmed. Overall, it earns its place with no wasted words.

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?

Given 5 parameters, no output schema, and no annotations, the description compensates well by explaining the output structure (verdict with per-asset reasons and next steps) and the indicative nature. It is complete for a check tool, though it could mention if the result is purely deterministic or requires external data.

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 baseline is 3. The description adds minimal extra meaning beyond the schema, only indirectly referencing inputs ('from what the person owned and how they owned it'). It does not elaborate on parameter details or constraints.

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 clearly states the verb 'check' and the resource 'whether a grant of probate is likely needed', specifies the jurisdiction (England & Wales), and distinguishes from sibling tools like calculate_iht and estimate_probate_cost by focusing on the need for probate rather than costs or taxes.

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 implies usage for preliminary probate need assessment and includes a caveat about institutional variability, but does not explicitly state when to use this tool versus alternatives such as calculate_iht or will_readiness_check. No direct exclusions or comparisons are provided.

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?

With no annotations, the description carries full burden. It discloses the tool is an illustrative check, explains key behavioral traits like tapering, capping, and doubling, and notes the downsizing note does not affect numbers. However, it does not state whether the calculation is binding or for estimation.

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 a single dense paragraph with detailed numerical info. While informative, it lacks structure (e.g., bullet points) and could be more concise without losing clarity.

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?

Given 8 parameters and no output schema, the description explains the calculation logic but does not describe the return format. 'Illustrative check with plain-English reasons' hints at output but is vague; missing details on whether output includes eligibility, amount, or reasons.

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%, but the description adds significant value by explaining how each parameter fits into the calculation logic (e.g., homeValue caps allowance, estateValue drives taper). This integrates parameter meaning beyond the schema descriptions.

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 clearly states the tool checks residence nil-rate band eligibility and amount, with specific thresholds and conditions. It distinguishes itself from siblings like calculate_iht by focusing solely on RNRB, and uses specific verbs and resource.

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 implies RNRB is a component of IHT, but does not explicitly state when to use this tool versus alternatives like calculate_iht. No when-not-to-use guidance is provided, but the context of RNRB is clear.

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?

The description discloses it is an exposure model and not FCA-regulated advice, adding behavioral context beyond the schema. Without annotations, it carries the full burden but does not detail safety constraints or side effects.

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, front-loaded with purpose, no wasted words. Efficient and clear.

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?

Covers the core functionality and caveats well for a 6-parameter tool with no output schema. Could hint more at output format but is sufficient.

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 provides 100% parameter descriptions, so baseline is 3. The description adds overarching context (e.g., why pensionValue matters) but does not enhance individual parameter semantics beyond schema.

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 clearly states the tool shows the Inheritance Tax impact of the April 2027 pension change, comparing IHT before and after. It distinguishes itself from siblings like calculate_iht by specifying the 2027 context and emphasizing it is only an exposure model.

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 implies use for 2027 pension impact but does not explicitly mention when to use alternatives like calculate_iht. It provides context (exposure only) but lacks exclusion criteria or direct comparisons.

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?

With no annotations, the description carries full behavioral burden. It discloses an honest note that always accompanies recommendations, example of care fees limitation, and that no trust may be needed. This provides significant transparency beyond basic purpose.

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 three sentences, each adding essential information: purpose with honest note, output characteristics, and a valid null result. No wasted words, effectively front-loaded.

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?

Given one required parameter and no output schema, the description adequately covers what the tool does and what to expect. It could briefly mention return format, but is sufficient for agent use.

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 one parameter 'goal' having enum and description. The tool description does not add extra detail on the parameter itself but contextualizes its usage. Baseline 3 is appropriate as schema already documents the parameter.

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 clearly states the tool recommends UK trust types for a goal, with an honest note and lists what each trust does not do. This distinguishes it from sibling tools like calculate_iht or check_rnrb which focus on other estate planning aspects.

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 implies use when a user has a goal and needs trust recommendations. It does not explicitly state when not to use or mention alternatives, but the context is clear enough for an agent to differentiate from sibling tools.

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?

The description transparently explains the data source (2026 estimates, published averages, rounded), that means-test notes are educational only, and deliberately avoids a 'how much could you protect' computation. This adds behavioral context beyond what annotations (none provided) would typically convey.

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 a single, well-structured paragraph that front-loads the main purpose and efficiently covers data source, computation, and educational caveats. Every sentence contributes distinct value.

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 tool with 3 parameters and no output schema, the description adequately explains the computation model, included notes, and what is deliberately omitted. It does not specify the exact return format, but the overall purpose and behavior are clearly conveyed.

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 brief descriptions. The tool description adds value by explaining how parameters feed into the formula (years × 52 × weekly ranges) and provides context for the weekly ranges (typical self-funder, sourced 2026 estimates). This enriches meaning beyond the basic schema.

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?

Description clearly states 'Project what care home fees could cost' with specific computation details (weekly ranges × 52 × years, by region and care type). This distinguishes it from siblings like calculate_iht or check_deed_of_variation.

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 through the description's focus on projecting care costs for self-funders, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions.

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?

With no annotations, the description carries full transparency burden. It discloses the tool is guidance-only, explains VAT applicability, and specifies that professional fees are market ranges not firm fees. No destructive behavior is expected, and no authorization needs are mentioned, but the description is sufficiently transparent for a non-mutating calculator.

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 a single paragraph of moderate length, front-loaded with the main purpose. Each sentence adds value, though some detail (e.g., parenthetical about VAT) could be more concisely placed. Nevertheless, it is efficient.

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?

There is no output schema, and the description does not detail what the tool returns (e.g., a breakdown of costs). For a simple estimator, this may be acceptable, but more completeness would be helpful. The description covers inputs adequately but lacks return format.

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%, so baseline is 3. The description adds meaningful context beyond schema: it explains the fee threshold (£5,000) and that professional fees are typical market ranges (not firm-specific) and that VAT may apply. This enriches parameter understanding.

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 explicitly states the tool estimates probate costs in England & Wales, listing specific components (HMCTS fee, sealed-copy costs, professional fee ranges). It clearly distinguishes itself from siblings like calculate_iht by focus on probate costs.

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 provides a caveat ('Guidance, not advice') but does not explicitly state when to use this tool versus alternatives among the 16 siblings. Usage is implied by the tool's purpose, but no exclusions or comparisons are given.

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?

No annotations provided; description discloses it returns questions and answers but lacks details on side effects, rate limits, or authentication requirements, which is minimal for a read-only 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?

Single sentence that efficiently conveys purpose, scope, and optional filter, with no extraneous words.

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 tool with one optional parameter and no output schema, the description is adequate but does not specify return format, pagination, or behavior without query.

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% for the single parameter; description adds no new meaning beyond 'Optional keyword filter' which parallels the schema's description.

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?

Description clearly states it returns FAQs with specific topics (fees, regulation, IHT, trusts, wills/LPAs/probate), distinguishing it from sibling tools which are calculations and checks.

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?

Implied use for general FAQ queries but no explicit guidance on when to use versus alternatives or what not to use it for.

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?

With no annotations provided, the description carries full burden. It discloses the tool's educational nature, clarifies that taper relief reduces rate not value, and specifies that it only matters when total gifts exceed the nil-rate band. This provides clear behavioral context beyond the input schema.

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?

Description is two sentences with front-loaded purpose. The first sentence states the core action, the second provides essential caveats. No wasted words.

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?

The description explains what the tool does (maps gifts to taper bands) but does not specify the output format or content. Since there is no output schema, the description could better indicate what the user receives (e.g., timeline, table). Some gaps remain for complete understanding.

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 descriptions for each field (amount and yearsAgo). The description adds no extra semantics for parameters, relying on the schema's self-explanatory names and descriptions. 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?

Description clearly states the tool maps lifetime gifts onto the 7-year-rule timeline, specifying it identifies taper bands and when gifts exit the estate. It distinguishes itself from siblings like 'calculate_iht' by emphasizing it is educational only, not a personal tax computation.

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?

Description explicitly states it is an educational timeline, not a personal tax computation, and explains the conditions under which taper relief matters (total gifts exceed £325,000 nil-rate band). It implies when to use (for understanding bands) and when not to (for actual tax calculations), but does not explicitly name an alternative sibling for computation.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the behavior when 'term' is omitted (list all glossary entries), which is beyond the schema. While it doesn't detail safety or performance, the simple read-only nature is clear from context, making this adequate.

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 sentences, each adding value: the first defines the tool's purpose and scope, the second clarifies the optional parameter behavior. No extraneous words; it is perfectly concise and front-loaded.

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?

Given the simple single-parameter tool with no output schema, the description covers the essential functionality and the special behavior of omitting the parameter. It could optionally mention the return format or suggest example terms, but it is sufficiently complete for an agent to use correctly.

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 input schema already provides a clear description for the single parameter 'term' ('Term or partial term to match; omit to return the full glossary'). The tool description adds minimal new meaning—it restates the omission behavior but does not add constraints, examples, or formatting details. Since schema coverage is 100%, the baseline score of 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 clearly states the tool's purpose ('look up plain-English definitions of UK estate-planning terms') and distinguishes it from sibling tools (which are calculations, checks, and searches). The specific inclusion of example terms (IHT, trusts, LPAs, probate) provides concrete scope, and the note about omitting 'term' to list all adds further clarity.

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 implies usage for defining estate-planning terms but provides no explicit guidance on when to prefer this tool over siblings like 'get_faqs' or 'search_guides'. No 'when not to use' or alternative suggestions are given, leaving the agent to infer appropriateness.

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?

No annotations provided, so description carries full burden. It discloses the request is free, no-obligation, returns a reference ID, and that the team follows up. It also notes estate planning is not FCA-regulated. Minor missing details like potential confirmation email or error handling, but adequate for the tool's simplicity.

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, each serving a distinct purpose: purpose, usage guideline, and return/regulatory note. No wasted words, front-loaded with key 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?

Given the simple nature of the tool (form submission), no output schema, and no annotations, the description covers all necessary aspects: what it does, when to use, outcome, and regulatory note. Agent can correctly invoke the tool.

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?

Input schema has 100% description coverage, so baseline is 3. Description adds context about consent and real details but does not explain parameter meanings beyond schema. Adequate but no added 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?

Description clearly states 'Submit a request for a FREE, no-obligation estate-planning consultation', specifying verb and resource. It distinguishes itself from sibling tools (calculations, checks) by being the only one for requesting a consultation.

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?

Explicitly says 'Use only with the user's explicit consent and real contact details', providing clear context. However, it does not mention when not to use or offer alternative tools for similar purposes.

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?

With no annotations, the description discloses the core behavior: a read-only keyword search returning titles, URLs, and excerpts for citation. It does not mention authentication, rate limits, or result limits, but the behavior is clearly non-destructive and low-risk.

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, front-loaded with the verb 'Search', and no extraneous words. Every part is necessary and useful.

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 search tool with 1 parameter and no output schema, the description fully covers what the tool does and what it returns. It could mention pagination or result limits, but that is not critical for usability.

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 the parameter 'query' is described as 'Keywords to search guide titles, excerpts and tags'. The description's 'by keyword' adds no new semantic value, so the baseline score of 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 explicitly states the tool searches 'Simply Estate's estate-planning guides' by keyword, listing specific topics (wills, IHT, LPAs, trusts, probate) and details the output (titles, URLs, excerpts). This clearly distinguishes it from sibling tools like get_faqs or lookup_glossary.

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 implies usage for searching guides with keywords but does not specify when to use this tool versus alternatives like get_faqs or lookup_glossary. There is no explicit guidance on when-not-to-use or context for selection.

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?

With no annotations, the description carries full burden and discloses key behavioral traits: it always returns warnings, cohabiting partners inherit nothing, and jointly-owned assets are outside these rules. It does not cover all edge cases but adds significant context.

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, no fluff. The first sentence states the purpose and scope; the second emphasizes critical warnings. Information is front-loaded and efficient.

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?

The description covers key outputs (who inherits, warnings) but lacks details on handling foreign assets and partial wills. Given 6 parameters and no output schema, more context would be helpful.

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 covers 100% of parameters, and the description adds meaning by explaining that jointly-owned assets pass by survivorship and clarifying that maritalStatus only counts marriage/civil partnership, enriching the schema's descriptions.

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 clearly states the tool applies England & Wales intestacy rules to determine who inherits and how much, with a specific date cutoff. It distinguishes itself from sibling tools (e.g., calculate_iht) by focusing solely on intestacy.

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 implies when to use (intestacy scenarios) and warns about jointly-owned assets passing by survivorship, which guides exclusion. However, it does not explicitly state when not to use (e.g., if a valid will exists).

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?

With no annotations, the description carries full burden. It discloses that the tool returns a band (covered/gaps/urgent), how answers are evaluated, and lists item ids. It does not mention side effects or auth needs, but for a read-only scoring tool, this is sufficient.

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 sentences: first states purpose, second details inputs and output. Every sentence adds value with no wasted words. It is front-loaded with the main action.

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?

Given no output schema, the description fully explains the output format (band). It covers all three parameters, including the role of hasChildren and includeAdvanced. For a moderate-complexity tool, this is 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 the description adds significant meaning: it lists the checklist item ids, explains that hasChildren enables guardianship, and that includeAdvanced adds advanced items. This goes far beyond the schema's basic type descriptions.

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 clearly states the tool scores estate-planning readiness against a checklist, using specific verbs and resource. It distinguishes from sibling tools like calculate_iht or check_need_probate by focusing on a checklist-based readiness assessment.

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 explains when to use the tool (to score readiness) and what inputs are needed. It provides context for criteria (missing/false items count as gaps) but does not explicitly mention when not to use or suggest alternatives among siblings.

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