Skip to main content
Glama

Xearno Tools

UK Self-Assessment First-Year Bill Calculator (payments on account)

uk_first_year_self_assessment
Read-only

Your real first-January Self Assessment bill — the year’s tax PLUS 50% of next year’s, due the same day — with the exact dated payment schedule. Computes a UK sole trader’s 2025-26 Self Assessment bill (income tax stacked on top of any PAYE income, plus Class 4 National Insurance) and then the part general AI reliably misses: payments on account. First-time filers owe 150% of their bill on 31 January 2027 — the full year’s tax plus the first half of next year’s, in one payment, for income earned up to ~22 months earlier. The tool applies the exact boundary tests (POAs are waived when the bill is under £1,000 or when more than 80% of your tax was collected at source through PAYE), the post-April-2025 late-payment interest formula (Bank rate + 4%, currently 7.75% — models still quote the old + 2.5%), and flags whether Making Tax Digital’s quarterly reporting catches you from April 2026.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
profitNoSelf-employment profit for 2025-26 (£) Tax year 6 Apr 2025 – 5 Apr 2026: revenue minus allowable expenses (your taxable profit, not turnover).
firstYearNoIs this your FIRST Self Assessment year? First-timers get the 150% shock: the whole year’s bill plus the first payment on account land on the same day. Returning filers have already part-paid via last year’s payments on account.yes
priorBillNoLast year’s total Self Assessment bill (£) Only used when this is NOT your first year: it set the two payments on account (50% each) you have already made toward this year.
payeIncomeNoEmployment (PAYE) income in the same year (£) Salary taxed through payroll. It uses up your personal allowance and basic-rate band BEFORE your profit — and because its tax is collected at source, it feeds the 80% test that can spare you payments on account entirely.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations are minimal (readOnlyHint=true, openWorldHint=false), but the description adds substantial behavioral context: it details the 150% payment shock, boundary tests for waiving POAs (under £1,000 or >80% PAYE), the late-payment interest formula, and MTD flag. This goes far beyond annotations and fully discloses the tool's logic and edge cases.

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?

Description is front-loaded with the core purpose in the first sentence, but it is relatively long and includes some extraneous phrasing (e.g., 'the part general AI reliably misses'). While every sentence adds value, the overall length could be trimmed slightly without losing information. Still, it remains focused and structured.

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

Completeness5/5

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

Despite no output schema, the description fully explains what the tool returns (the exact dated payment schedule) and covers all key aspects: calculation logic, POA rules, interest formula, and MTD flag. With four parameters and a specialized use case, the description is comprehensive and leaves no important gaps.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant meaning beyond the schema. For example, it explains why 'profit' is taxable profit (not turnover), how 'payeIncome' feeds the 80% test to waive POAs, and the role of 'firstYear' and 'priorBill' in the payment schedule. This enriches the schema definitions with practical context.

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?

Description clearly identifies the tool as computing a UK sole trader's first-year Self Assessment bill with payments on account, specifying the exact tax year and distinguishing it from generic tax calculators. The verb 'Computes' and specific resource 'UK sole trader’s 2025-26 Self Assessment bill' make the purpose explicit and unique among 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?

Description implies usage for first-time UK self-assessment filers by focusing on first-year scenarios and mentioning 'First-time filers'. While it provides context for when to use, it lacks explicit when-not-to-use guidance or alternatives. The clarity of the scenario compensates for the absence of negative examples.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Each tool targets a distinct niche (e.g., specific country tax rules, loan types, or legal calculations), with detailed descriptions that clarify boundaries. However, the large number of tools (66) could cause some confusion for an agent trying to select the right one for a general query, especially when multiple tools relate to the same country.

Naming Consistency4/5

Tool names follow a mostly predictable pattern: lowercase words separated by underscores, often starting with a country name (e.g., 'uk_stamp_duty_sdlt') or a topic (e.g., 'compound_growth'). There are minor deviations, such as abbreviations ('npv_irr', 'sip') and varying use of verbs, but overall the naming is clear and consistent.

Tool Count3/5

At 66 tools, the server is unusually large and covers an extensive range of financial and legal calculators. While each tool justifies its existence, the count exceeds the typical well-scoped range (3–15), making the server feel bloated. A more modular design might improve coherence.

Completeness4/5

The tool set covers a wide array of domains: personal income taxes, property taxes, loan calculations, investment returns, and specific country regulations. Minor gaps exist (e.g., missing tools for corporate taxes, general retirement planning, or insurance), but the overall coverage is thorough and addresses many niche scenarios that general AI handles poorly.

Resources