A.X.E.L Filing (public tools)

estimate_uk_self_assessment

Read-only

Estimate one person's UK Self Assessment for one tax year (2025-26 or 2026-27): income tax on salary, dividends, self-employment and interest, Class 4, student loans, payments on account, and Class 1 National Insurance on a salary from the person's own company. Uses the same engine as A.X.E.L Filing's returns, which matches HMRC's own test cases. An estimate only: nothing is saved or filed. Never ask for a UTR or National Insurance number.

Input Schema

Name	Required	Description
`income`	No	Income in ONE personal tax year (6 April to 5 April), all in POUNDS. Ask; do not guess.
`region`	Yes	Where the person lives for income tax: rUK (England or Northern Ireland), scotland or wales. Scottish rates differ. Ask.
`payroll`	No	For the Employment Allowance (up to £10,500 of employer NI). HMRC: a company with only one director cannot claim if that director is the only employee liable for employer NI. Ask both.
`taxYear`	Yes
`dividends`	No	Total dividends received in the tax year, from any company
`eligibility`	No	Answer true for any that apply; each is refused as out of scope (refer to an accountant).
`postgraduateLoan`	No
`studentLoanPlans`	No	Undergraduate student loan plans being repaid
`overStatePensionAge`	No	Over State Pension age: no employee National Insurance on salary (the company still pays employer NI)
`becameDirectorDuringYear`	No	Became a director part-way through the tax year. Refused: a shorter NI earnings period needs HMRC's directors' calculator.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 12, 2026

addedInput schema / properties / becameDirectorDuringYear

Added value: +{
+  "description": "Became a director part-way through the tax year. Refused: a shorter NI earnings period needs HMRC's directors' calculator.",
+  "type": "boolean"
+}

addedInput schema / properties / overStatePensionAge

Added value: +{
+  "description": "Over State Pension age: no employee National Insurance on salary (the company still pays employer NI)",
+  "type": "boolean"
+}

addedInput schema / properties / payroll

Added value: +{
+  "description": "For the Employment Allowance (up to £10,500 of employer NI). HMRC: a company with only one director cannot claim if that director is the only employee liable for employer NI. Ask both.",
+  "properties": {
+    "directors": {
+      "description": "How many directors the company has",
+      "type": "number"
+    },
+    "othersLiableForEmployerNi": {
+      "description": "Is anyone else on the payroll paid more than £5,000 a year?",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

AddedOct 12, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the readOnlyHint/non-destructive annotations, it discloses substantive traits: no persistence or filing side effects, use of the same engine as HMRC-matched returns, an explicit prohibition on requesting a UTR or NI number, and refusal semantics for edge cases. These are non-obvious constraints an agent must honour.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and scope are front-loaded in the first clause, followed by the computation list and the safety constraints. It is dense but each sentence carries information; only the HMRC-engine credibility claim is somewhat expendable.

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

Completeness3/5

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

For a 10-parameter, nested-object tool with no output schema, the description is strong on inputs, scope, and side effects, but says nothing about the shape of the returned estimate (line items, totals, breakdown). An agent knows what it must supply but not what it will get back.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80%, so most parameters are already documented in the schema, including currency, region enum meaning, and eligibility refusal behaviour; the description largely restates these. It reinforces context (one personal tax year, all in pounds) but adds little parameter-level detail beyond what the schema provides.

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

Purpose5/5

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

States a specific verb (Estimate), a specific resource (one person's UK Self Assessment), and a bounded scope (one tax year, 2025-26 or 2026-27), then enumerates exactly what is computed: income tax on salary/dividends/self-employment/interest, Class 4, student loans, payments on account, Class 1 NI. This clearly separates it from the CT600/corporation-tax siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when this applies (personal self-assessment for one individual, one tax year) and a strong behavioural boundary: 'An estimate only: nothing is saved or filed.' It also routes out-of-scope cases (partnership, capital gains, foreign income, etc.) elsewhere, though it doesn't explicitly name a sibling tool as the alternative for those referrals.

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

All A.X.E.L Filing (public tools) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?