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 address clearly distinct questions: whether a duty applies versus how to perform a check. There is no overlap, so an agent can easily select the right one.
Both names use snake_case and are descriptive, but the first follows an imperative verb_noun pattern while the second uses a question-style phrase. This is a minor deviation in convention.
Two tools for this narrow domain is borderline thin. While each tool earns its place, a bit more granularity (e.g., document verification) could help.
The surface covers the core informational needs: whether a check is required and how to conduct one, including records and fines. Minor gaps remain, such as validating specific documents or handling edge cases.
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 work or engagement starts, 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?
With no annotations, the description carries the full burden and does well: it discloses jurisdiction (UK), legal basis (Act, s48), effective date, cost ('Free'), and the liability caveat (not legal advice). It omits nothing critical for an advisory lookup tool, though it says nothing about return format or precision of the determination.
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 tightly packed sentences with no filler; the jurisdiction and effective-date qualifiers are front-loaded before the outcome description.
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?
No output schema exists, and the description hints at the return ('says whether... and what to do'), which is adequate for an advisory tool. Minor gap: it does not describe the shape or confidence of the answer.
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% with three enums fully documented in-schema, so the schema already carries parameter meaning. The description adds no format or interpretation detail beyond what the schema provides, which is the baseline case for a 3.
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 precise verb and resource: determines whether a right-to-work check duty applies to a subcontractor/gig/platform worker under a named statute and section. Clearly distinct from the sibling how_to_do_a_right_to_work_check, which covers procedure rather than the threshold question.
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?
Explicit scoping: 'UK only', tied to the rule in force from 1 October 2026, and flagged as 'General information, not legal advice'. It does not explicitly name the sibling tool as the alternative for procedural steps, but the jurisdiction and effective-date context make the applicable situation clear.
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?
With no annotations, the description carries the full burden, and it does reasonably well: it discloses the content returned, the jurisdictional scope, and that the tool is free (cost context). It does not state side effects, freshness of the guidance, or auth needs, but for a zero-parameter informational lookup the risk profile is fully conveyed.
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 short clauses, front-loaded with the scope constraint and content summary, with zero wasted text. 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?
For a zero-param tool with no output schema, the description lists the return contents, which is the key thing an agent needs to decide whether to call it. Lacking an output schema, more detail on the format of the returned guidance would be nice, but it is largely 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?
The tool takes no parameters, so there is nothing to document and the baseline is 4. The description has no parameter burden to compensate for.
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 resource (right-to-work check guidance) and enumerates what it returns: the three accepted ways, record-keeping rules, and fines. It's clearly distinguishable from the sibling check_subcontractor_right_to_work_duty, though that differentiation is implied by the sibling's name rather than stated in the description.
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 jurisdictional scoping condition, which is useful, but there is no explicit when-to-use or when-not guidance, nor a pointer to the sibling tool for the subcontractor case. Usage is implied rather than stated.
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_dutyhow_to_do_a_right_to_work_checkUK immigration tools: going rates by SOC, sponsor licence check, visa fees, employer right to work.
UK compliance documentation for the EU AI Act, Worker Protection Act 2024, and UK GDPR.
Check whether a company holds a UK or Netherlands work-visa sponsorship licence.
UK Global Talent Visa handbook, endorser criteria, cost calculator, draft scoring. Free, no auth.
Add one secure layer between your agents and this server.
