Free UK CIS tax refund estimates for self-employed construction subcontractors, from S+ Money (Sovereign Plus Tax Ltd, trading as S+ Money; company registration in progress). Two read-only tools: estimate_cis_refund (2025-26, 2026-27 and 2027-28 with Budget 2026 rules) and get_cis_tax_rates, with GOV.UK sources. No sign-in, nothing stored. An estimate, not tax advice.
Scored across 2 tools
The two tools have clearly separate jobs: one performs a full refund/liability calculation, the other is a static rate reference lookup. There is no realistic way to confuse them, and the descriptions reinforce the boundary by both noting they are read-only and not tax advice.
Both names follow a clean verb_noun pattern (estimate_cis_refund, get_cis_tax_rates) and share a consistent 'cis' domain prefix. Snake_case is used uniformly with no drift into camelCase or alternate verb styles.
Two tools is on the thin side even for a narrow calculator domain; the surface is essentially one action plus a supporting reference. It is defensible because the scope is deliberately tight, but there is little toolset depth to evaluate.
The core lifecycle is covered: an agent can look up the applicable rates and then run a full multi-year estimate with breakdown, PAYE offset, and expenses. Minor gaps exist around comparative or multi-year scenario modelling, but nothing that would block the primary workflow.
Estimate a UK CIS subcontractor's tax refund (or amount to pay) for tax year 2025-26, 2026-27 or 2027-28 (Budget 2026 rules for 2027-28). Takes the year's gross CIS income, the CIS deducted (the statement total, or the 20%/30% rate), allowable expenses (materials, tools, van mileage at HMRC simplified rates, parking and travel, phone, protective clothing, training and site cards, insurance, accountant) and optional other PAYE/pension income. Calculates taxable profit (or the trading allowance if better: £1,000, or £3,000 from 2027-28), income tax (England/Wales/NI or Scottish bands, Personal Allowance taper), Class 4 NIC and the Class 2 position, then compares the bill with the CIS already deducted. Returns the working line by line, payments-on-account warning, commonly missed expenses, rates used with GOV.UK sources and a result card. For self-employed sole traders under CIS, not limited companies. Read-only: stores and sends nothing. An estimate, not tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Where the person lives for income tax: 'england_wales_ni' or 'scotland' (Scottish bands). Default england_wales_ni. | |
| vehicle | No | Vehicle for business_miles. Default car_or_van. | |
| cis_rate | No | Deduction rate used when cis_deducted_gbp is not given: '20' (registered for CIS) or '30' (not registered). Default '20'. | |
| tax_year | No | UK tax year: '2025-26' (6 Apr 2025 to 5 Apr 2026, return due 31 Jan 2027), '2026-27' or '2027-28' (Budget 2026 rules; Scottish 2027-28 bands not yet set, 2026-27 ones used). Default '2025-26'. | |
| insurance_gbp | No | Public liability and tool insurance. Default 0. | |
| materials_gbp | No | Cost of materials the subcontractor bought and invoiced to contractors (CIS is not deducted from these; they are an expense). Default 0. | |
| business_miles | No | Business miles driven in own van/car (between sites, to merchants). Claimed at HMRC flat rates: 45p (2025-26) or 55p (2026-27 on) for the first 10,000; 25p after (35p from 2027-28, Budget 2026); 24p motorcycles. Default 0. | |
| cis_deducted_gbp | No | Total CIS deducted in the year, from the monthly CIS payment and deduction statements, GBP. If omitted it is worked out from cis_rate on the labour part. | |
| other_income_gbp | No | Other taxable income in the same year from a PAYE job or pension (gross), GBP. Default 0. | |
| workwear_ppe_gbp | No | Protective clothing, PPE and branded workwear (not everyday clothes). Default 0. | |
| vehicle_costs_gbp | No | Business share of actual van/car costs, ONLY if not using mileage for that vehicle. Default 0. | |
| other_expenses_gbp | No | Any other allowable business expenses. Default 0. | |
| phone_internet_gbp | No | Business share of phone and data. Default 0. | |
| training_cards_gbp | No | CSCS/CPCS cards and training that updates existing trade skills. Default 0. | |
| tools_equipment_gbp | No | Tools and equipment bought for work in the year. Default 0. | |
| gross_cis_income_gbp | Yes | Total paid by contractors in the tax year BEFORE CIS deductions (labour plus any materials invoiced), GBP. Required. | |
| accountancy_other_gbp | No | Accountant fees, business bank charges, trade subscriptions, stationery. Default 0. | |
| parking_tolls_travel_gbp | No | Parking, tolls, congestion/ULEZ charges for work trips, public transport and work-away accommodation. Default 0. | |
| tax_paid_on_other_income_gbp | No | Income tax already paid on that other income (from the P60/P45). Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by spelling out the calculation chain (trading allowance comparison, income tax bands, PA taper, Class 4/Class 2), the return contents (line-by-line working, payments-on-account warning, missed expenses, rates with GOV.UK sources, result card) and a caveat that it is an estimate, not tax advice. The annotations already cover safety, and the description reinforces it with "Read-only: stores and sends nothing" plus non-obvious behavior like Budget 2026 rules for 2027-28.
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?
Purpose and tax-year scope are front-loaded before the input list and the return description, and no sentence is pure filler. The single dense block of parentheticals is justified by a 19-parameter tax calculation, though it could be broken into shorter clauses for scanning.
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 complex, high-parameter tax estimator with no output schema, the description covers inputs to collect, the computation performed, the shape of the returned working and the legal disclaimer. An agent can decide whether to call it and how to populate it without opening anything else.
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 the schema already explains every one of the 19 parameters, including defaults, enums and the mileage rates. The description mirrors those expense categories (materials, tools, mileage, parking, phone, PPE, training, insurance, accountant) rather than adding new semantics, and only the trading allowance thresholds add genuine extra information for parameter interpretation. 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?
Opens with a specific verb+resource ("Estimate a UK CIS subcontractor's tax refund") and bounds the scope tightly with tax years, inputs and the sole-trader/not-limited-company restriction. It does not, however, contrast itself with the sibling get_cis_tax_rates, leaving the boundary between "estimating a refund" and "getting rates" to be inferred.
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?
Gives clear usage context (self-employed sole traders under CIS, explicitly not limited companies) and names the required inputs as a checklist, which is effectively a prerequisite list. It stops short of saying when to reach for get_cis_tax_rates instead, so the alternative-routing guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the UK rates a self-employed CIS subcontractor's tax bill uses for 2025-26, 2026-27 or 2027-28, each with its GOV.UK source: Personal Allowance and taper, income tax bands (England/Wales/NI or Scotland), Class 4 NIC limits and rates, the Class 2 position (treated as paid above the Small Profits Threshold, voluntary below), HMRC simplified mileage rates, the trading allowance (£1,000; £3,000 from 2027-28), the Making Tax Digital start dates and the 20%/30% CIS deduction rates. Read-only. Not tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Income tax bands to show. Default england_wales_ni. | |
| tax_year | No | '2025-26', '2026-27' or '2027-28'. Default '2025-26'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description does not need to repeat that. It adds meaningful behavioral context by enumerating exactly which rate categories and thresholds are returned, including the Class 2 treatment, MTD dates, and deduction rates, and by adding the important caveat 'Not tax advice.'
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 key purpose and scope are front-loaded in the opening clause, and the long enumerated list is substantive rather than filler. However, the description is a single run-on sentence with many clauses, which makes it denser than necessary for quick scanning.
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 only two optional enum parameters, and the description compensates by fully enumerating the returned rate categories, years, regions, and source attribution. Combined with annotations covering safety, an agent has enough context to call this lookup 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?
Schema coverage is 100% and both enum parameters are documented in the schema itself, including defaults and region meaning. The description reinforces the available tax years and mentions region-specific income tax bands, but it adds little beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: list UK CIS subcontractor tax rates for specified tax years with GOV.UK sources. The enumerated contents make it clearly a reference-rate lookup rather than a refund estimate, so an agent can distinguish it from the sibling estimate_cis_refund tool.
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 by explaining what the tool lists and which tax years and regions are available, but it never explicitly says when to use this tool instead of estimate_cis_refund or when each is appropriate. It also lacks exclusion guidance beyond the note that it is not tax advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
estimate_cis_refundget_cis_tax_rates
Add one secure layer between your agents and this server.