estate-planning
Server Details
UK estate-planning calculators + knowledge (IHT, intestacy, trusts, wills). Read-only.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 16 of 16 tools scored. Lowest: 3.5/5.
Every tool has a clear, distinct purpose covering different aspects of UK estate planning (IHT, LPAs, probate, trusts, care costs, etc.). No two tools overlap in functionality; descriptions are detailed and unique.
All tools use snake_case with a verb-noun pattern (e.g., calculate_iht, check_need_probate). Minor variation like 'gift_7_year_timeline' (noun-heavy) and 'who_inherits_intestacy' (question form) slightly break the pattern, but overall consistency is high.
16 tools cover the broad domain of estate planning comprehensively without being excessive. Each tool serves a specific, necessary function, and the count is well-scoped for the server's purpose.
The tool set covers key areas: IHT calculations, probate, LPAs, trusts, care costs, intestacy, and educational resources. Minor gaps exist (e.g., no direct trust IHT calculation), but the consultation request tool fills service gaps, so overall coverage is strong.
Available Tools
16 toolscalculate_ihtAInspect
Estimate a UK Inheritance Tax bill (2025/26 England & Wales rules). Models the nil-rate band, residence nil-rate band and its £2m taper, spousal doubling, the 40% charge, the 2027 pension change, plus optional debts, charity rate (36% at 10%+), transferred allowances and business/agricultural relief. Illustrative only — excludes lifetime-gift history.
| Name | Required | Description | Default |
|---|---|---|---|
| married | Yes | Married or in a civil partnership (combined/doubled allowances) | |
| homeValue | No | Value of the main home (£) — caps the residence nil-rate band | |
| charityPct | No | Share of the net estate left to charity (%) | |
| debtsValue | No | Mortgage, loans and funeral costs (£) | |
| estateValue | Yes | Total estate value excluding any pension you add separately (£) | |
| includeDebts | No | Deduct debts/liabilities first | |
| pensionValue | No | Unused pension value to fold in (£) | |
| includeRelief | No | Qualifying business/agricultural assets get simplified relief | |
| includePension | No | Include unused pensions (the rules from 6 April 2027) | |
| transferredNrb | No | Late spouse's unused nil-rate band (£), capped £325,000 | |
| transferredRnrb | No | Late spouse's unused residence nil-rate band (£), capped £175,000 | |
| leavingToCharity | No | A share of the estate is left to charity (10%+ cuts the rate to 36%) | |
| reliefAssetsValue | No | Value of qualifying business/agricultural assets (£) | |
| transferredAllowance | No | Claim a late spouse's/civil partner's unused allowances | |
| leavingHomeToDescendants | Yes | Does a main home pass to children/grandchildren? Enables the residence nil-rate band |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool is illustrative and specifies the rule set, which is important for a calculation tool. No destructive behavior expected, so adequate transparency.
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: first states purpose, second lists features, third adds caveats. Each sentence is necessary and front-loaded with key information. 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 15 parameters, 3 required, and no output schema, the description covers the main capabilities and constraints. Lacks explicit mention of return value format but is otherwise comprehensive for the complexity.
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. Description adds overall context about how parameters relate to features (e.g., RNB taper, charity rate), but does not provide additional parameter-level details beyond the 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?
Clearly states the tool estimates a UK Inheritance Tax bill, listing specific rules modeled (nil-rate band, residence nil-rate band, taper, spousal doubling, etc.). Distinguishes from sibling tools like check_rnrb and compare_pension_2027 by focusing on comprehensive estimation.
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?
Provides clear context: works for 2025/26 England & Wales rules and is illustrative only, excluding lifetime-gift history. Implies when not to use (for gift planning), but lacks explicit alternative tool names or when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_lpa_costAInspect
Calculate the Office of the Public Guardian fees to register Lasting Powers of Attorney in England & Wales: £92 per LPA (applications received from 17 November 2025), with a 50% remission where the donor's gross annual income is under £12,000 and a full exemption on certain means-tested benefits (both claimed with form LPA120). Registration fees only — nothing about drafting costs or whether an LPA is right for someone.
| Name | Required | Description | Default |
|---|---|---|---|
| couple | Yes | A couple making the same LPAs each (doubles the document count) | |
| lpaTypes | Yes | Which LPA(s) — 'Both types' registers two documents per person | |
| incomeUnder12k | Yes | Donor's gross annual income below £12,000 (50% remission) | |
| qualifyingBenefits | Yes | Donor receives certain means-tested benefits (full exemption) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the tool's behavior: it calculates fees with specific conditions (income thresholds, benefits). Since annotations are absent, the description carries the burden and meets it well, with no hidden side effects or contradictions.
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 sentence that front-loads the purpose and packs all necessary details (fee amount, remission conditions, scope limitation) without any 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?
For a simple calculator tool with four parameters and no output schema, the description provides adequate information to use it correctly. It covers fee logic and conditions, though it could briefly note the output format (e.g., a number) for full completeness.
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 value by explaining how parameters affect the calculation (e.g., 'doubles the document count' for couple, 'Both types registers two documents per person'), which enriches 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 states the tool calculates Office of the Public Guardian fees for registering LPAs, specifies the fee amount (£92 per LPA), and clearly distinguishes from drafting costs or suitability advice. This leaves no ambiguity about what the tool does.
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 stating 'Registration fees only' and 'nothing about drafting costs or whether an LPA is right for someone.' It does not explicitly name alternative tools but implicitly guides usage by defining scope, which is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_deed_of_variationAInspect
Check whether a deed of variation is available — guidance-only eligibility against the s.142 IHTA 1984 conditions: the hard two-year window from the date of death (HMRC does not extend it), adult beneficiaries with capacity, and the agreement of everyone whose share would reduce. Returns yes / no / depends with blockers, goal-mapped possibilities, and an honest note that ALWAYS accompanies the result. No tax outcome is promised — whether it helps depends on the whole estate.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What the family wants the variation to achieve | |
| allAgree | Yes | Those affected beneficiaries all agree to the change | |
| allAdults | Yes | Every beneficiary whose share would reduce is an adult (18+) with capacity | |
| deathTiming | Yes | When the person died — the two-year window is the hard statutory gate |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently discloses that it is guidance-only, returns yes/no/depends with blockers, includes an always-present honest note, and promises no tax outcome.
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 purpose and conditions without unnecessary words. Every sentence adds 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?
Given the tool's complexity (4 required params, no output schema), the description adequately covers eligibility criteria and return behavior, though output structure is not detailed.
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, but the description adds meaningful context about the two-year window, adult capacity, and goal enum, going beyond the schema's basic 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 deed of variation eligibility against specific legal conditions (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 use for eligibility checks but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_need_probateAInspect
Check whether a grant of probate (or letters of administration) is LIKELY to be needed in England & Wales, from what the person owned and how they owned it. Returns a guidance verdict — likely / maybe / unlikely — with per-asset reasons and next steps. Indicative only: every bank and institution sets its OWN probate threshold and decides asset by asset, so the honest answer always includes asking each one directly.
| Name | Required | Description | Default |
|---|---|---|---|
| allToSpouse | Yes | Everything passes to a surviving spouse/civil partner who owned it jointly | |
| soleProperty | Yes | Property or land registered in the deceased's sole name | |
| jointProperty | Yes | Property owned jointly — held as joint tenants it passes by survivorship | |
| largestBalance | Yes | Largest single bank or building-society balance in their sole name | |
| soleInvestments | Yes | Shares or investments held in their sole name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns an indicative guidance verdict and does not replace institutional checks. It implies a read-only check, but doesn't explicitly state no side effects or mention authentication/rate limits.
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 sentence defines purpose and output, second adds a crucial limitation. No redundant words, and key information is 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 no output schema, the description explains the output format (verdict with per-asset reasons and next steps). It also covers the indicative nature and the need for institutional follow-up. Could mention how the verdict is derived but overall 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 coverage is 100%, so the description adds only marginal value beyond the schema. It contextualizes the parameters with 'from what the person owned and how they owned it' but doesn't elaborate on individual 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 clearly states the tool checks whether probate is likely needed, returning a verdict with reasons and next steps, and specifies jurisdiction (England & Wales). It distinguishes itself from sibling tools like calculate_iht or estimate_probate_cost by focusing on the need 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 includes an important caveat that each institution sets its own thresholds, advising users to ask directly. While it doesn't explicitly mention when not to use or reference specific alternatives, the context makes its use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_rnrbAInspect
Check residence nil-rate band eligibility and amount (England & Wales 2025/26): up to £175,000 per person where a home you own (or owned) passes to direct descendants, doubled for a married couple / civil partners, plus a late spouse's transferred allowance — capped at the home's value and tapered by £1 for every £2 the estate exceeds £2m. Illustrative check with plain-English reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| married | Yes | Married or in a civil partnership (combined/doubled allowance on the second death) | |
| ownsHome | Yes | You own (or owned) a home that is — or was — your residence | |
| homeValue | Yes | Value of the home (£) — caps the available allowance | |
| estateValue | Yes | Total estate value including the home (£) — drives the £2m taper | |
| transferredRnrb | No | Late spouse's unused residence nil-rate band (£), capped £175,000 | |
| passesToDescendants | Yes | The home passes to children/grandchildren (step, adopted and foster children count) | |
| transferredAllowance | No | Claim a late spouse's/civil partner's unused residence allowance | |
| downsizedAfterJuly2015 | No | Sold or downsized after 8 July 2015 — surfaces the downsizing-addition note (never changes the numbers) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains the calculation logic clearly (e.g., £175k allowance, doubling, taper). However, it does not explicitly state what the tool returns (e.g., eligibility boolean, amount, or plain-English reasons). The phrase 'Illustrative check with plain-English reasons' hints at output but is vague. This leaves some ambiguity for the agent.
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 sentence that packs key rules and purpose without fluff. Every segment earns its place: thresholds, conditions, caps, taper, and output nature. It is front-loaded with purpose and quickly communicates the tool's scope.
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 complexity of RNRB and the lack of an output schema, the description should specify the return format more clearly. While it mentions 'plain-English reasons', it does not state whether the tool returns a boolean eligibility, a numeric amount, or both. Also, it does not describe edge cases or error conditions. The description is useful but not 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?
All parameters have descriptions in the schema (100% coverage), but the tool description adds value by explaining how parameters like 'homeValue' and 'estateValue' affect the calculation (caps, taper). This goes beyond the schema descriptions, providing operational context that aids the agent in setting correct values.
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 identifies the tool's function: checking residence nil-rate band eligibility and amount, with specific details on thresholds, doubling, taper, and capped amount. It uses a specific verb ('check') and resource ('residence nil-rate band'), and distinguishes itself from sibling tools like 'calculate_iht' by focusing on this specific allowance.
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 no guidance on when to use this tool versus alternatives, such as 'calculate_iht'. It does not mention scenarios where the tool is inappropriate or when another sibling tool would be better suited. The usage context is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_pension_2027AInspect
Show the Inheritance Tax impact of the April 2027 change that brings most unused pensions into the estate: the IHT before vs after, and the extra tax. Exposure only — models nothing about pension products or what to do with a pension (that is FCA-regulated advice).
| Name | Required | Description | Default |
|---|---|---|---|
| married | Yes | Married or in a civil partnership | |
| homeValue | No | Main home value (£) — caps the residence nil-rate band | |
| estateValue | Yes | Estate value excluding pensions (£) | |
| pensionValue | Yes | Unused pension value (£) — counted only in the 'from 2027' scenario | |
| pensionToSpouse | No | Pension would pass to a spouse first (educational note only) | |
| leavingHomeToDescendants | Yes | Does a main home pass to children/grandchildren? |
Tool Definition Quality
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 is non-advisory and models only estate before/after the change. No contradictions or omissions about 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 with no wasted words. Front-loaded with key action and scope, then clear limitation.
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 and 6 parameters, the description adequately sets expectations for a simple exposure tool. It could mention return format briefly but not necessary.
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 nuance (e.g., pension counted only in 'from 2027') but not significantly beyond 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 it shows the IHT impact of the April 2027 change, comparing before/after and extra tax. It uses a specific verb and resource and distinguishes from sibling tools like calculate_iht by focusing on the 2027 change.
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 explicitly notes it is 'Exposure only — models nothing about pension products' and that advice is FCA-regulated, guiding users on scope. However, it does not explicitly compare to alternatives like calculate_iht.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_trustsAInspect
Recommend which UK trust types are worth discussing for a goal, with an HONEST note that always accompanies the recommendation (e.g. no trust simply avoids care fees — deliberate-deprivation rules apply with no time limit). Each trust lists what it does NOT do. 'No trust may be needed' is a valid answer.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What the person is trying to achieve |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the honest note, per-trust limitations, and the possibility of 'no trust needed', but lacks details on output format or number of recommendations.
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 short, front-loaded with the main action, and every sentence provides value 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?
The description covers the purpose and key output traits, but does not specify the structure or format of the recommendation, leaving some ambiguity for the agent.
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 context for the goal parameter but does not elaborate on individual enum values beyond the general purpose.
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 'Recommend' and the resource 'which UK trust types are worth discussing for a goal', making the purpose distinct from sibling tools like calculators 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?
No explicit guidance on when to use this tool versus alternatives; only implied through the goal parameter. No exclusions or alternative tool references provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_care_costAInspect
Project what care home fees could cost: typical self-funder weekly ranges (sourced 2026 estimates rounded from published averages) × 52 weeks × years, by region and care type. The educate-only means-test notes are ALWAYS included — England's capital limits and Wales's single limit are stated as facts for education; there is deliberately no 'how much could you protect' computation, because no arrangement simply avoids care fees.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | Whole years of care to project (e.g. 1, 2, 3 or 5) | |
| region | Yes | Where the care would be | |
| careType | Yes | Residential care or nursing care |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description carries full burden. It discloses data sources (2026 estimates, rounded averages), that means-test notes are always included, and that there is no computation for avoiding fees. This is transparent about limitations and what the tool does not do.
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 that efficiently conveys purpose, method, data source, and limitations. Every sentence adds value 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?
Despite no output schema, the description explains the calculation and data source. It does not explicitly state the output format (e.g., a single number, range, or breakdown), but the purpose is clear enough for most agents. Minor gap in specifying return structure.
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 meaning by explaining the calculation method (weekly × 52 × years) and that output varies by region and care type. This goes beyond schema descriptions, which only give basic enum explanations.
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: it projects care home fees using weekly ranges multiplied by 52 weeks and years, by region and care type. It distinguishes itself from sibling tools like estimate_probate_cost by focusing specifically on care cost projection.
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 tool is for self-funders and education purposes, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., for means-tested support). No exclusions or explicit context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_probate_costAInspect
Estimate the cost of probate in England & Wales: the HMCTS application fee (£300 where the estate is over £5,000; no fee at £5,000 or below — the same with or without a will), sealed-copy costs, and — on the professional route — typical fee ranges across the UK market (NOT the firm's fees; most professional fees attract VAT on top). Guidance, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| hasWill | Yes | A valid will exists (grant of probate); without one, letters of administration | |
| estateValue | Yes | Gross estate value (£) — home, savings, investments, minus debts | |
| includesProperty | Yes | Estate includes a house or flat (enables the IHT-instalments note) | |
| professionalRoute | Yes | true = with professional help (adds typical UK market fee ranges); false = applying yourself |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavioral traits: fee threshold (£5,000), VAT on professional fees, and the disclaimer 'guidance, not advice'. It is transparent about what the tool does and its limitations.
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 of 3-4 sentences. It is front-loaded with the main purpose and economically adds details 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?
The description explains what the tool estimates but does not describe the output format (e.g., a breakdown or total). Since there is no output schema, the description should clarify what the user receives, which 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?
Schema coverage is 100% (all 4 parameters described in schema). The description adds value by explaining how parameters affect the estimate (e.g., estateValue triggers fee condition, professionalRoute adds fee ranges), going beyond 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 estimates probate cost in England & Wales, listing specific components (HMCTS fee, sealed-copy costs, professional fees). It distinguishes from sibling tools like 'calculate_iht' by focusing on probate-specific 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 implies the tool is for cost estimation but does not explicitly state when to use it versus alternatives like 'calculate_iht' or 'estimate_care_cost'. It provides context (guidance, not advice) but lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_faqsAInspect
Return Simply Estate's frequently-asked questions and answers (fees, regulation, IHT, trusts, wills/LPAs/probate). Optional keyword filter.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional keyword to filter the FAQs |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as read-only, side effects, or constraints beyond basic functionality.
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, 15 words, efficient and 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?
Adequate for a simple retrieval tool with one optional parameter; could mention behavior when no keyword is given.
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 the parameter fully; description adds no new meaning beyond restating 'optional keyword filter'.
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?
Clearly states it returns FAQs with specific topics listed. Distinguishes from sibling tools like lookup_glossary and search_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?
Mentions optional keyword filter but provides no when-to-use or when-not-to-use guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gift_7_year_timelineAInspect
Map lifetime gifts onto the 7-year-rule timeline: which taper BAND each gift sits in and when it falls outside the estate. An EDUCATIONAL timeline of the bands and mechanics only — NOT a personal tax computation: taper relief reduces the rate of tax, never the gift's value, and it only matters where total gifts in the 7 years before death exceed the £325,000 nil-rate band (used up oldest gift first). No personal tax figures are computed.
| Name | Required | Description | Default |
|---|---|---|---|
| gifts | Yes | Up to 5 gifts to place on the timeline |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that taper relief reduces rate not value, that it only matters when gifts exceed nil-rate band, and that the oldest gift is used first. No contradictions.
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 concise and front-loaded with main purpose. All sentences add value, no fluff. Could be slightly shorter, but optimal for 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 the complexity of the 7-year rule and no output schema, the description explains what the tool does, its limitations, and key mechanics. Sufficient for an educational 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?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for the single 'gifts' parameter; it focuses on overall behavior.
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?
Clearly states it maps gifts onto the 7-year-rule timeline, showing taper bands and when gifts fall outside the estate. Distinguishes from siblings like 'calculate_iht' which computes tax, by explicitly noting it is educational and 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?
Provides context on when to use (educational timeline) and what it does not do (NOT a personal tax computation). Does not explicitly name alternative tools, but the exclusion is clear enough to guide selection from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_glossaryAInspect
Look up plain-English definitions of UK estate-planning terms (IHT, trusts, LPAs, probate). Omit term to list all.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | Term or partial term to match; omit to return the full glossary |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it returns definitions or full list, implying a read-only operation. However, it does not disclose output format, matching behavior, or any constraints like case sensitivity.
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 front-loads the action and resource, with no wasted words. Efficiently conveys purpose and key behavior.
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?
Adequate for a simple lookup tool, but lacks details on output format, matching behavior, and how it relates to sibling tools. Could be more complete given no output schema and no annotations.
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 reinforces the schema's note about omitting term to list all, and gives examples of terms. It adds marginal value beyond the 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 action ('Look up ... definitions') and resource ('UK estate-planning terms'), provides examples (IHT, trusts, LPAs, probate), and notes behavior when term is omitted. This distinguishes it from sibling tools like calculate_iht or get_faqs.
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: use when needing definitions of UK estate-planning terms. However, no explicit when-to-use or when-not-to-use guidance is provided, nor are alternatives mentioned among the 16 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_consultationAInspect
Submit a request for a FREE, no-obligation estate-planning consultation on the user's behalf. Use only with the user's explicit consent and real contact details. Returns a reference id; the Simply Estate team follows up. Estate planning here is not FCA-regulated.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The person's full name | |
| Yes | A real email address (required if no phone) | ||
| phone | No | Phone number (optional) | |
| county | No | County, if known | |
| message | No | Brief description of what they'd like help with | |
| service | No | Area of interest | estate-planning |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns a reference id and that the Simply Estate team follows up, and that the service is free and no-obligation. Lacks details on failure modes or rate limits, but sufficient for this type of 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?
Description is front-loaded with purpose, followed by consent, outcome, and regulatory note. Every sentence adds value; no 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 no output schema and no annotations, the description provides sufficient context for using the tool: consent, required inputs, expected outcome, and regulatory status. Could mention more about what happens after submission, but overall adequate.
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 all parameters. The description does not add meaning beyond what the schema provides, so baseline 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 submits a free, no-obligation estate-planning consultation request on the user's behalf, with a specific verb and resource. It distinguishes itself from sibling tools which are mostly calculations or 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?
Explicitly states the tool should only be used with the user's explicit consent and real contact details, providing clear when-not guidance. It also notes that estate planning here is not FCA-regulated, adding relevant context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_guidesAInspect
Search Simply Estate's estate-planning guides (wills, IHT, LPAs, trusts, probate) by keyword. Returns titles, URLs and excerpts to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keywords to search guide titles, excerpts and tags |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states the tool returns titles, URLs, and excerpts, and is a search operation. No mention of destructive actions or rate limits, but for a simple search 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?
Two sentences, front-loaded with verb and resource, no redundant information. Every word is necessary.
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 one-parameter search tool with no output schema, the description is complete: it explains what is searched and what is returned. Could mention pagination or limits but not required for basic completeness.
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 description in schema already mentions 'search guide titles, excerpts and tags'. The description adds no new information beyond the schema, so 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 clearly states the tool searches estate-planning guides by keyword, specifies the resource (guides), and lists return types (titles, URLs, excerpts). It distinguishes from sibling tools which are specific calculators or 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?
The description implies use for keyword search of guides, and sibling tools are all different (calculators, checks), providing context. However, it does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_inherits_intestacyAInspect
Apply the England & Wales intestacy rules (dying without a will, rules from 26 July 2023): who inherits and how much. ALWAYS returns the warnings — e.g. a cohabiting partner inherits nothing, and jointly-owned assets usually pass outside these rules by survivorship.
| Name | Required | Description | Default |
|---|---|---|---|
| estateValue | Yes | Estate passing under intestacy (£) — sole-name assets, minus debts | |
| hasChildren | Yes | Any biological or legally adopted children (stepchildren don't count unless adopted) | |
| maritalStatus | Yes | Legal status at death (only marriage/civil partnership counts) | |
| hasPartialWill | No | A valid will covers some assets (partial intestacy) | |
| hasForeignAssets | No | Property/accounts held abroad — local succession law applies | |
| jointlyOwnedValue | No | Approx value of jointly-owned assets (£) — passes by survivorship, outside these rules |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full transparency burden. It warns that the tool always returns warnings (e.g., cohabiting partner inherits nothing, jointly-owned assets pass by survivorship). This reveals behavioral outcomes beyond the input schema, though it omits details like error handling or idempotency.
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 concisely convey purpose and key behavioral warnings with no superfluous words. The critical warning about outcomes is front-loaded, optimizing for quick agent 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?
Given 6 parameters and no output schema, the description adequately covers core behavior and major warnings. However, it does not address partial wills, foreign assets, or jointly owned value specifics in its prose, though these are documented in the schema. Sufficient for a legal tool but could be slightly more comprehensive.
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, but the tool description adds valuable context: 'estateValue' is clarified as sole-name assets minus debts, 'hasChildren' specifies stepchildren exclusion, and 'maritalStatus' enum is explained with legal context. This significantly enhances the schema's values.
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 function: apply England & Wales intestacy rules to determine who inherits and how much, with a specific date and jurisdiction. This verb+resource combination is distinct from sibling tools, which cover other legal or financial computations.
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 does not explicitly specify when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. While it implies use for intestacy scenarios, it lacks direct comparison or exclusion criteria for sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
will_readiness_checkAInspect
Score estate-planning readiness against a checklist. Pass answers as a map of item id → true/false (ids: has_will, will_recent, executors_named, guardians_named, lpa_property, lpa_health, wishes_recorded, assets_listed; advanced: pension_nominations, digital_assets, business_succession, foreign_assets, life_insurance_trust). Missing or false items count as gaps. Returns a band: covered / gaps / urgent.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | Map of checklist item id → true (in place) / false | |
| hasChildren | Yes | Household includes children under 18 (enables the guardianship item) | |
| includeAdvanced | No | Include the advanced/often-forgotten items |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the scoring logic, input requirements, and output bands. It doesn't explicitly state read-only behavior, but the context implies it's a computation without 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?
Three sentences, front-loaded with purpose, then input details, then logic and output. No superfluous words; every sentence 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?
Given the tool's complexity (3 parameters, nested object, no output schema), the description is complete: explains input format, item ids, logic, effect of parameters, and output bands.
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?
Adds significant meaning beyond the input schema: lists specific item ids, explains effect of hasChildren (enables guardianship item), clarifies that missing/false items count as gaps, and describes return bands.
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 scores estate-planning readiness against a checklist, with a specific verb and resource. It distinguishes from sibling tools (all calculations, not checklist scoring).
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?
Provides clear context on when to use (assess readiness) and explains inputs and outputs. Lacks explicit exclusions or alternatives, but the tool's purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!