UK immigration tools: going rates by SOC, sponsor licence check, visa fees, employer right to work.
Scored across 5 tools
Each tool targets a clearly distinct task: salary rate lookup, right-to-work assessment, right-to-work question gathering, sponsor licence search, and fee estimation. The two right_to_work_* tools share a prefix and are coupled, but their descriptions clearly delineate gathering answers versus running the assessment, so misselection is unlikely.
All names use snake_case, but the structural convention is mixed: going_rate has no verb, right_to_work_assess and sponsor_licence_check end in verbs, right_to_work_questions and visa_cost_estimate end in nouns. Still readable and domain-intuitive, but not a predictable verb_noun pattern.
Five tools is well-scoped for a focused visa data reference server, and each tool covers a distinct, non-redundant slice of the domain. Nothing feels padded or missing at the count level.
Coverage spans key employer compliance (right to work, sponsor licence) and applicant economics (going rate, visa fees), which is strong for the domain. Gaps remain (no visa eligibility/route determination, processing times, or document checklist), though agents can work around these.
Look up the UK Skilled Worker visa going rate for a job by title or SOC 2020 occupation code, and the minimum salary a sponsored worker must be paid on each salary option (standard, new entrant, PhD, Immigration Salary List, Health & Care). Covers 412 codes: 270 with published rates, 38 paid on national pay scales, 104 not eligible. Source: GOV.UK, updated 22 July 2025. Information, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| soc | No | Exact 4-digit SOC 2020 occupation code, e.g. '2134'. | |
| limit | No | Maximum matches to return (default 5). | |
| query | No | Job title, profession or keywords, e.g. 'software developer', 'care worker', 'nurse'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds valuable context beyond that: coverage specifics (412 codes, 270 with published rates, 38 national pay scales, 104 not eligible), the authoritative source, the update date, and a 'not advice' caveat. This gives the agent a good sense of data scope and limitations.
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 description is compact and front-loaded with the primary purpose, then adds only high-value details: coverage counts, source, update date, and a caveat. Every sentence earns its place, and there is no repetition of schema or annotation 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 read-only lookup tool with well-documented parameters and no required inputs, the description covers the key context an agent needs: what the tool returns information about, the acceptable lookup keys, and data coverage. It does not explicitly describe the output shape, but the absence of an output schema is partly mitigated by the clear domain scope.
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 baseline is 3. The description reinforces that queries use job titles and SOC codes, which mirrors the schema, but it adds no extra parameter-level detail such as formatting rules, precedence between query and soc, or how limit behaves beyond what the schema already supplies.
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 verb ('look up'), a precise resource (UK Skilled Worker visa going rate and minimum salary), and the lookup keys (job title or SOC 2020 code). It clearly identifies what the tool does and is readily distinguishable from the sibling tools, which cover licence checks and visa cost estimation.
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 clearly implies when to use this tool: whenever the goal is to find the going rate or minimum sponsored salary for a UK Skilled Worker role by job title or SOC code. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the employer Right to Work assessment over answers gathered with right_to_work_questions. Returns every finding (urgent problems, critical uncertainties, missing safeguards, review items, duties reported complete, possible exclusions, sponsor duties), the facts not established, the modules not assessed, the statutory basis (Immigration, Asylum and Nationality Act 2006 s.15 with ss.14A/15A; SI 2026/683; SI 2026/700 art.5B) and the sources. If the walk is incomplete it returns the next screen to ask. Never confirms compliance or a statutory excuse; records nothing; issues no document. Information, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | Answers keyed by field id from right_to_work_questions: a single-choice field takes the option id, a multi-choice field an array of option ids, a checklist an object of item id to option id, a date field 'YYYY-MM-DD'. Send only fields that were asked; the tool tells you which screen comes next when the walk is incomplete. | |
| assessmentDate | No | Date of the assessment, YYYY-MM-DD. Defaults to today in London. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true; the description goes beyond by stating it 'records nothing', 'issues no document', 'never confirms compliance or a statutory excuse', and is 'Information, not advice'. These are significant behavioral caveats not captured by annotations, adding real value for an agent.
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 description is a single, information-dense paragraph that front-loads the primary action. It lists many result categories but each is relevant for an agent to understand the output. No wasted words; the length is justified by the tool's complexity.
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 compensates by enumerating the returned findings (urgent problems, critical uncertainties, etc.) and the statutory basis, plus the incomplete-walk handling. It does not detail a response structure, but for a tool with this complexity the coverage is adequate for an agent to invoke it 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 includes detailed descriptions of the answers object (single-choice, multi-choice, checklist, date formats) and the assessmentDate pattern. The description only adds a reference to the source tool and the incomplete-walk behavior, which is a minor enhancement; it does not substantially expand on parameter meaning beyond what the schema 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?
The description clearly states the action ('Run the employer Right to Work assessment') and the specific input source (answers from right_to_work_questions). It enumerates the categories of results, distinguishing it from siblings like sponsor_licence_check or visa_cost_estimate, which address different workflows.
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?
It explicitly ties usage to prior collection of answers via right_to_work_questions and explains the incomplete-walk behavior ('returns the next screen to ask'). While it doesn't name alternatives for exclusion, the context makes the intended use obvious and the sibling list reinforces the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The screens, fields and option ids of the employer Right to Work checker for the rules extended on 1 October 2026 (section 48 of the Border Security, Asylum and Immigration Act 2025: workers, individual sub-contractors, supply chains, online matching services). Up to twenty screens; the routing note says which apply. Gather the employer's answers as option ids and call right_to_work_assess. Information, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| module | No | Return only the screens of one module. Omit for the whole catalogue. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, so the risk profile is covered. The description adds meaningful behavioral context: it is a routing-based catalogue ('the routing note says which apply'), limited to a specific statutory version, and explicitly non-advisory. No contradiction with annotations.
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?
Every sentence earns its place: scope, legal version, size, routing behavior, usage instruction, and disclaimer. It is front-loaded with what the tool returns, and the downstream call is stated in one short sentence.
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 read-only catalogue with no output schema, the description covers the object type, legal scope, routing behavior, the parameter module's effect, and the next step. It falls just short of full completeness because it assumes some knowledge of what a 'routing note' is and does not enumerate the output structure beyond screens/fields/option ids.
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 only parameter, module, is fully specified in the schema with an enum and description explaining that omitting it returns all screens. The tool description does not need to add more, and it doesn't. Baseline of 3 applies because schema coverage is 100%.
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 clearly identifies the tool as a catalogue of 'screens, fields and option ids' for the Employer Right to Work checker, scoped to the rules extended on 1 October 2026. It also frames the tool's role in the workflow: gather the employer's answers and call right_to_work_assess. This is specific and distinguishes it from the sibling assessment 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 gives concrete usage direction: collect answers as option ids and pass them to right_to_work_assess, and clarifies this is 'information, not advice.' It does not explicitly contrast with siblings like going_rate or sponsor_licence_check, but the workflow guidance is strong enough for an agent to select it for question-gathering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a UK employer holds a sponsor licence: searches the Home Office register of licensed sponsors by organisation name (and optionally town) and returns matching organisations with their sponsorship routes and rating. Presence on the register does not mean the employer will sponsor a given job. Information, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Employer name or part of it, e.g. 'Deloitte'. | |
| town | No | Town or city to narrow the search, e.g. 'Manchester'. | |
| limit | No | Maximum organisations to return (default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and idempotent behavior. The description adds meaningful context beyond this: it clarifies the legal/interpretive meaning of a register match ('does not mean the employer will sponsor a given job') and explicitly labels the output as information, not advice. This goes beyond the structured hints.
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 tightly written sentences with the core action front-loaded and no wasted words; each sentence adds a distinct point: what it does, what the results mean, and a disclaimer. It is appropriately sized for the tool's complexity.
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 simple read-only lookup with no output schema, the description covers what it returns (matching organisations, sponsorship routes, rating) and warns about false positives. Combined with the rich parameter descriptions in the schema and the readOnly/idempotent hints, an agent has enough to invoke it 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%, so the baseline is 3 and the description need not repeat parameter details. It does echo the name/town search semantics ('by organisation name (and optionally town)') without adding format or syntax details, so it adds no significant value 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?
States a specific verb (Check) and resource (Home Office register of licensed sponsors), and explicitly describes what it searches by and returns. This clearly differentiates it from siblings (going_rate, visa_cost_estimate) without needing to open their schemas.
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 makes the primary use case evident—checking whether a UK employer holds a sponsor licence—and adds an interpretive caveat about register presence. However, it does not explicitly state when to prefer this tool over siblings or when not to use it, leaving the routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the Home Office fees for a UK visa or citizenship application: application fee per applicant, Immigration Health Surcharge for the length of leave (adult and child rates, Home Office part-year rounding), priority or super-priority service, and route extras such as the citizenship ceremony. Routes: visitor, student, graduate, skilled3, skilled5, skilled3_in, skilled5_in, health, health5, fiance, spouse_ec, spouse_flr, ilr, nat, registration. Fee schedule 8 April 2026. Government fees only — no legal fees. Information, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| route | Yes | Visa route id. One of: visitor (Standard Visitor visa (6 months)); student (Student visa); graduate (Graduate visa); skilled3 (Skilled Worker visa — applying from outside the UK (up to 3 years)); skilled5 (Skilled Worker visa — applying from outside the UK (over 3 years)); skilled3_in (Skilled Worker — extension or switch inside the UK (up to 3 years)); skilled5_in (Skilled Worker — extension or switch inside the UK (over 3 years)); health (Health & Care Worker visa (up to 3 years)); health5 (Health & Care Worker visa (over 3 years)); fiance (Fiancé(e) visa (6 months)); spouse_ec (Spouse / Partner visa (entry clearance)); spouse_flr (Spouse / Partner extension — FLR(M)); ilr (Indefinite Leave to Remain (ILR)); nat (Naturalisation (British citizenship)); registration (Registration as British (child)). | |
| priority | No | Processing: none (standard), priority (~5 working days, £500 each), super (next working day, £1,000 each). Not available on citizenship routes; entry clearance offers priority only. | |
| lengthMonths | No | Length of leave in months where the route offers a choice (e.g. Skilled Worker 12/24/36); the route's first published length when omitted or not offered. | |
| adultDependants | No | Adult dependants (partner / 18+) applying with the main applicant. Ignored on routes where it does not apply (partner, citizenship). | |
| childDependants | No | Child dependants under 18. For child registration this is simply the number of children. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the description is free to add the non-obvious behavior: a pinned fee schedule (8 April 2026), Home Office part-year rounding on the IHS, adult vs child rates, and a clear disclaimer that output is information, not advice. That scoping and staleness disclosure is real value beyond the annotations; it stops short of describing the response shape.
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 purpose and pricing components are front-loaded in the first sentence, with the route enum, fee-schedule date, and exclusions following as scannable qualifiers. No filler sentences; the route list is arguably redundant with the schema but is compactly presented.
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 a full-coverage schema and no output schema, the description carries the return-value burden and does so by enumerating the cost components an agent can expect. It omits currency of the returned figures (only implied by £ in the schema) and any indication of whether results are itemized or a single total, which are minor gaps for this complexity.
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 both enums are exhaustively documented in the schema, so the baseline is 3. The description largely restates the route list already in the schema; its only additive parameter context is the note about Home Office part-year rounding for IHS length calculations.
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 ("Estimate") and resource (Home Office fees for a UK visa/citizenship application), then enumerates exactly what is priced: application fee, IHS, priority service, and route extras. The enum of supported routes and the sibling set (going_rate, right_to_work_assess) make the tool's scope unambiguous.
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?
Usage is implied by "Estimate the Home Office fees..." and bounded by "Government fees only — no legal fees" plus "Information, not advice," which quietly rules out legal-cost or advice use cases. However, it never names an alternative tool or states the condition under which another sibling (e.g. going_rate) should be used instead, so the when-to-use guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK Global Talent Visa handbook, endorser criteria, cost calculator, draft scoring. Free, no auth.
Check whether a company holds a UK or Netherlands work-visa sponsorship licence.
H1B visa salary disclosures + compensation benchmarks — real numbers, not estimates.
Over 200 free UK-focused calculators, converters and generators as MCP tools: take-home pay and National Insurance for 2026/27, VAT, stamp duty, mortgages, loans, savings, inflation since 1988, currency with live rates, dates and working days with bank holidays, unit conversions, health calculators, colour and text utilities, encoding, hashing, JWT and TOTP, and validators for IBANs and Bitcoin and Ethereum addresses. Every tool is read-only, stateless and computes on the spot; nothing you send is stored. Each result links to its source page on hopi.co.uk.
Add one secure layer between your agents and this server.
