Does a UK business have to right-to-work check a subcontractor or gig worker from 1 Oct 2026? Free.
Scored across 2 tools
The two tools target clearly separate questions: one determines whether a right-to-work duty applies to a subcontractor/gig/platform worker, the other explains the accepted methods and record-keeping for performing a check. An agent can trivially tell them apart from the descriptions, with no overlap in purpose.
Both names use snake_case and share the 'right_to_work_check' phrase, giving a clear family resemblance. However, the second uses a question-style 'how_to_do_a_' form rather than the imperative verb_noun pattern of the first ('check_...'), a minor deviation.
Two tools is on the thin side for a standalone server; the 'how to do a check' information could plausibly be folded into the duty tool or expanded (e.g. per-worker-type guidance). It is nonetheless a coherent, defensible scope for a narrow informational domain.
The set covers the two core user questions — does a duty apply, and how to perform/record a check — including fines and retention periods. Minor gaps remain, such as verifying a specific worker's documents or guidance for other worker categories (e.g. direct employees).
UK only. Says whether a business must do a right to work check on a subcontractor, gig worker or platform worker under the rule in force from 1 October 2026 (Border Security, Asylum and Immigration Act 2025, s48), and what to do. Free. General information, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | Who is asking: a business taking on self-employed people for its jobs, an app or platform matching workers to customers, an employment agency, or a homeowner hiring a tradesperson. | |
| start_date | No | Date the contract or arrangement with the worker was agreed (entered into), YYYY-MM-DD. Optional. | |
| contract_holder | No | Who has the contract with the worker: the asking business directly, or one of its subcontractors. | |
| work_arrangement | No | How the worker works: as an individual (sole trader or worker's contract), through their own limited company, or as an independent business with many customers of its own. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description adds genuinely useful context beyond them: the fixed rule date (1 October 2026) with statute reference, that the tool is free, and the 'general information, not legal advice' disclaimer. It does not state whether answers differ for start dates before the 2026 rule, which would have been a valuable boundary to flag.
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?
Roughly four short sentences, with the jurisdiction constraint front-loaded first and the scope of the answer immediately after. No filler; every clause (UK only, statute, date, free, not legal advice) carries 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?
For a single-required-parameter advisory tool with no output schema, the description covers scope, legal basis, effective date, and disclaimer adequately. It could be tighter about what the response actually contains (a yes/no plus guidance) and about the role of the optional start_date and contract_holder inputs.
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% and three of four parameters have enums with per-value explanations, so the schema already carries the parameter semantics. The description only echoes the covered roles (subcontractor, gig worker, platform worker) without adding format or dependency detail 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?
The description names a specific decision ('whether a business must do a right to work check on a subcontractor, gig worker or platform worker'), the jurisdiction (UK only), and the legal basis and effective date, so the agent knows exactly what question the tool answers. It stops short of naming the sibling tool, so it does not explicitly separate itself from how_to_do_a_right_to_work_check, and the trailing 'and what to do' overlaps that sibling's territory.
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?
'UK only' gives a clear geographic exclusion and the legal-rule framing implies the applicable scenario, but there is no explicit when-to-use versus how_to_do_a_right_to_work_check guidance. An agent must infer that this tool answers 'is a check required' while the sibling answers 'how do I perform one'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK only. Returns the three accepted ways to check someone's right to work, what records to keep and for how long, and the fines. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context beyond that: it enumerates what the answer contains (three accepted ways, retention periods, fines) and notes the call is free, which helps an agent decide it is a zero-cost knowledge lookup.
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?
A single tight sentence, front-loaded with the applicability constraint ('UK only') and then the payload. Every clause carries information; nothing is redundant with the title or annotations.
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?
With no output schema, the description carries the burden of describing the return value, and it does so concretely (three accepted ways, records to keep and for how long, fines). Format and length of the response are unspecified, but for a static guidance tool that omission is minor.
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 tool takes zero parameters and the schema is empty, so the baseline of 4 applies. There is nothing for the description to disambiguate on the input side.
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: it returns the accepted methods for a UK right-to-work check plus record-keeping rules and fines. The 'UK only' scoping is useful, but it never names or distinguishes itself from the sibling check_subcontractor_right_to_work_duty, so an agent must infer the boundary from the name alone.
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?
'UK only' is an explicit applicability condition, but there is no statement of when to reach for this tool versus the sibling subcontractor-duty tool, nor any prerequisites. Usage is implied (call it when you need procedural guidance) rather than spelled out.
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.
check_subcontractor_right_to_work_duty1 field changedInput schema / properties / start_date / descriptionPrevious value: -"Date the work or engagement starts, YYYY-MM-DD. Optional."New value: +"Date the contract or arrangement with the worker was agreed (entered into), YYYY-MM-DD. Optional."check_subcontractor_right_to_work_dutyhow_to_do_a_right_to_work_checkUK immigration tools: going rates by SOC, sponsor licence check, visa fees, employer right to work.
UK sanctions, export controls, Companies House owners, FCA register and property checks.
Free UK sole-trader tools: VAT & MTD checks, tax set-aside, expense categories, bookkeeper requests.
Inspect GOV.UK guidance, check quotations, and monitor recorded HMRC changes. Free agent trial.
Add one secure layer between your agents and this server.