UK sponsor licence checks, Skilled Worker going rates by SOC code and live visa-sponsored jobs.
Scored across 6 tools
Most tools target clearly different questions: check_sponsor for a named organisation, search_sponsors for filtered discovery, search_jobs for live vacancies, going_rate for SOC code rules, register_changes for add/remove diffs, site_stats for coverage numbers. The only real overlap is check_sponsor vs search_sponsors, since both accept name text and can return sponsor rows, though the descriptions distinguish a best-match lookup from a paginated filtered search.
All names are lowercase snake_case and the verb_noun pattern (check_sponsor, search_jobs, search_sponsors, register_changes) dominates. going_rate and site_stats are noun phrases rather than verb-led, which is a minor stylistic deviation but still readable and predictable.
Six tools is well-scoped for a niche domain: one lookup, one search per resource, one policy-data tool, one change feed and one stats tool. Each tool earns its place with no filler endpoints.
The surface covers the full lifecycle of the stated purpose: finding sponsors, verifying a specific one, browsing changes, checking SOC/going-rate eligibility, and searching live jobs, plus stats. The main gap is fetching a single job's detail by id/URL (agents must follow job page links), and there is no bulk export beyond CSV links, but core workflows are workable.
Is this organisation on the UK Home Office Register of Licensed Sponsors? Returns the best match (null when nothing resembles the name), its routes, rating, town, Companies House number, live sponsored jobs on Tarve, and up to 5 alternative matches.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The organisation's name as the person wrote it, e.g. "Revolut" or "Tesco Stores Limited". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds genuinely useful behavior: it performs fuzzy matching (null when nothing 'resembles the name') and caps alternatives at 5, which tells the agent how to interpret an empty or partial result.
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 sentences, zero padding, and the core question is front-loaded before the return-shape enumeration. Every clause carries information an agent would otherwise have to guess.
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, so the description must carry the return contract — and it does, listing each returned field plus the null and alternative-matches cases. For a one-parameter, read-only lookup this is complete enough to call correctly and interpret the result.
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?
Only one parameter and schema coverage is 100%, so the baseline is already a 3. The description contributes one extra signal beyond the schema: because it returns the 'best match' and null on weak resemblance, the agent learns that a rough, human-written name is acceptable input rather than an exact legal string.
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 the exact question the tool answers (is this organisation on the Home Office Register of Licensed Sponsors) and enumerates what comes back (routes, rating, town, Companies House number, live jobs, alternatives). The 'best match + up to 5 alternatives' framing implicitly distinguishes it from the sibling search_sponsors, but never names that sibling, so an agent must infer the split.
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 only implied by the framing: a single-organisation lookup rather than a broad search. There is no explicit when-to-use, when-not-to-use, or pointer to search_sponsors for exhaustive results, which is the obvious alternative among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Home Office going rate, lower rate, general and lower thresholds, gov.uk skill level, Immigration Salary List and Temporary Shortage List status (with end dates) and whether a NEW Skilled Worker application can be made in a SOC 2020 code. Give a four-digit code, or search text to find codes by occupation.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Occupation text to find codes, e.g. "software developer" (optional). | |
| soc_code | No | A SOC 2020 code, e.g. "2134" (optional when search is given). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent lookup. The description adds meaningful behavioral context beyond annotations by enumerating the returned fields, including statuses with end dates and the specific question of whether a NEW application can be made.
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 two sentences and front-loads the substantive returned data before explaining the input mode. The first sentence is dense and list-heavy but every element corresponds to actual output information an agent needs.
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?
Because there is no output schema, the description reasonably covers the return values by listing going rate, thresholds, skill level, shortage-list status, and new-application eligibility. It does not explain behavior when no matching code is found or when search text matches multiple occupations, leaving a minor gap.
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 parameters are documented with examples, so the schema already carries the parameter semantics. The description adds only a minimal clarification that either a four-digit code or search text can be used, which is consistent with the schema but not substantially beyond it.
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 resource and the specific data returned: Home Office going rate, thresholds, skill level, shortage-list status, and whether a new Skilled Worker application is possible for a SOC 2020 code. It does not explicitly differentiate itself from sibling tools such as check_sponsor, but the resource is 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?
The description gives invocation guidance ('Give a four-digit code, or search text'), implying use for looking up a specific occupation by code or text. It does not state when to prefer this tool over siblings or what to do if neither input is supplied, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Organisations added to and removed from the Register of Licensed Sponsors between two dates (yyyy-MM-dd, at most 93 days apart): counts, the first 500 rows each, and the monthly CSV links on tarve.co.uk.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End date, yyyy-MM-dd. | |
| from | Yes | Start date, yyyy-MM-dd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world behaviour, so the bar is lower. The description still adds real operational detail beyond them: results are counts plus only the first 500 rows each, and monthly CSV links live on tarve.co.uk. It does not say what happens if the 93-day limit is exceeded.
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 sentence with no filler; scope, return shape, row cap and date-window limit are all packed in and front-loaded. Every clause carries information the agent needs.
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 takes on the return-value burden and does so reasonably: counts, capped row lists, and CSV link location. Minor gaps remain (what the 500-row truncation implies for completeness, error behaviour), but nothing essential is missing.
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 date formats are already documented. The description contributes the non-obvious rule that the two dates must be at most 93 days apart, a constraint absent from the schema and important for a valid call.
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 concrete resource (organisations added to/removed from the Register of Licensed Sponsors) and a concrete scope (between two dates), which an agent can distinguish from search_sponsors or check_sponsor. It does not explicitly name a sibling or say what it is not, so it stops short of a 5.
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 only implied: an agent infers this is the tool for change-over-time queries, but the description never says when to prefer it over search_sponsors or site_stats. The 93-day window is a hard constraint rather than routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live UK jobs from employers that hold a Skilled Worker sponsor licence, in SOC codes open to new applicants. Filter by text, city, SOC code and a minimum salary. Returns titles, employers, pay, codes and the job page URLs (the first 20 and the total); applying goes through the page.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Title or employer text (optional). | |
| city | No | City, e.g. "Manchester" (optional). | |
| soc_code | No | SOC 2020 code, e.g. "2134" (optional). | |
| min_salary | No | Minimum annual salary in GBP (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive, so the bar is lower; the description still adds genuinely new behavior by disclosing that only the first 20 results plus a total are returned and that applications happen off-tool. That result-cap disclosure is exactly the kind of thing an agent needs and cannot get from the schema.
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 sentences, no filler, and the eligibility constraint is front-loaded before the filter and return information. Every clause carries information an agent would otherwise have to guess.
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 correctly takes on the return contract: titles, employers, pay, codes, page URLs, first 20 plus a total. What's missing is how to reach results beyond the first 20 — no cursor or page parameter is mentioned, leaving an agent unable to plan for broader retrieval.
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 each parameter already carries its own description with an example, so the schema does the heavy lifting. The description only restates the filter set without adding matching semantics, case handling, or whether filters combine as AND.
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 (search live UK jobs) and narrows scope precisely: employers holding a Skilled Worker sponsor licence, in SOC codes open to new applicants. That scope sentence alone separates it from search_sponsors and check_sponsor without opening any schema.
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 four available filters are named and 'applying goes through the page' tells the agent this tool is discovery-only, not an application path. It never explicitly contrasts itself with going_rate or search_sponsors, so the agent must infer which sibling holds salary benchmarks versus live listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search licensed sponsors by name text, town, visa route and whether they have live jobs on Tarve. Returns the first page (20) with the total.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name text (optional). | |
| town | No | Town as on the register, e.g. "London" (optional). | |
| route | No | Visa route, e.g. "Skilled Worker" (optional). | |
| has_jobs | No | Only sponsors with live sponsored jobs on Tarve (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context by stating the return shape: the first page of 20 plus a total. It does not cover ordering or how to retrieve subsequent pages.
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 sentences, zero filler, with the capabilities first and the result shape second. Nothing is redundant with the title or restated unnecessarily.
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, all-optional-filter search with no output schema, the description supplies the one thing an agent cannot infer: result size and total. Missing is any hint about pagination beyond page one or what fields a sponsor record contains, which matters more given there is no output schema.
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 every parameter has its own description, so the description can only add marginal value. It does clarify that has_jobs means live jobs on Tarve specifically, which is slightly beyond the schema, but contributes nothing about matching semantics for q (prefix vs substring) or town normalization.
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 (search) and resource (licensed sponsors) and enumerates the four filter dimensions. It does not name or differentiate itself from siblings like check_sponsor or register_changes, so an agent must infer that this is the multi-result lookup while check_sponsor is the single-record lookup.
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 only implied by the word "Search"; there is no explicit when-to-use, no mention of when to prefer check_sponsor for a known name, and no note that all filters are optional and combinable. The agent can reasonably guess, but the definition leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many live sponsored jobs and employers Tarve lists right now, how many are in codes open to new applicants, and when the register was last checked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description does add two useful behavioural details: 'right now' signals a live snapshot, and 'when the register was last checked' warns the counts may be stale and gives a freshness field. That is genuinely extra context, so it scores above baseline, but it is thin.
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?
It is a single dense sentence that front-loads the main counts and adds the freshness note last. Every clause earns its place, though the sentence is slightly run-on.
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 has to explain the return values, and it does so reasonably well: job count, employer count, count of codes open to applicants, and the last-checked timestamp. Exact field names and whether the two counts share one filtering window are left unspecified, but there are no parameters to mis-set.
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 clarify; the calm baseline of 4 applies. The description spends no words on parameters, which is correct.
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 exactly what the tool reports: counts of live sponsored jobs and employers, how many are in codes open to applicants, and the register's last-checked time. The verb is implicit (it 'reports counts' rather than 'returns counts'), and no sibling is named, but an agent can still tell this aggregate-snapshot tool apart from the record-oriented siblings search_jobs and search_sponsors.
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 only implied: the description's emphasis on totals and 'right now' suggests it is for an overview rather than for finding individual listings, which is the search_* tools' job. There is no explicit when-to-use clause and no mention of when not to use it instead of check_sponsor or going_rate.
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_sponsorgoing_rateregister_changessearch_jobssearch_sponsorssite_statsUK immigration tools: going rates by SOC, sponsor licence check, visa fees, employer right to work.
Home Office licensed visa sponsors register search and lead lists.
Check whether a company holds a UK or Netherlands work-visa sponsorship licence.
Search jobs with sponsorship evidence, read your profile and queue, and prepare application packs.
Add one secure layer between your agents and this server.
