Work Abroad Check

Warning signs to check a job or visa offer abroad against

abroad.check_offer

Read-only

Use this when someone shares, or describes, a job offer, a recruiter's message or a visa offer for work abroad (for example in the UK, Canada, the US, the Gulf, Europe or Asia) and wants to know whether it could be a scam. It returns the warning signs of recruitment and visa fraud that the governments concerned describe for an offer of that kind and place (such as paying for a certificate of sponsorship, a fee to be given the job, a UK care-worker visa from abroad, a "guaranteed" visa or a green card lottery "win"), GOV.UK's own list of warning signs, who pays what, the checks to make and where to report, each with its source, so that the offer can be compared with them. It does not judge the message itself. Do not use it to tell someone an offer is genuine or safe, for jobs in their own country, or as legal advice on a visa case. Leave passport, ID and bank numbers out of the message.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "message": "<message>"
    },
    "name": "abroad.check_offer"
  }
}

Input Schema

Name	Required	Description	Default
`message`	Yes	The offer or message as received, or a short account of it. Leave out passport, ID and bank numbers.
`home_country`	No	Where the person lives, for the reporting channels at home: ghana, nigeria, kenya, south_africa or zimbabwe.

Output Schema

Name	Required	Description	Default
`checks`	Yes
`limits`	Yes
`who_pays`	No
`report_to`	Yes
`explore_url`	No
`signs_to_check`	Yes
`sources_read_on`	Yes
`standing_advice`	Yes
`job_seems_to_be_in`	Yes
`govuk_warning_signs`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, non-destructive and closed-world, and the description adds real value beyond them: the output consists of sourced government-published warning signs, and the tool deliberately does not render a judgement on the message. It does not cover limits such as which jurisdictions are in the corpus beyond the examples, or how results behave when the place is unknown.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The trigger condition is front-loaded and every sentence carries a distinct job: what it does, why the output is comparable, and what it must not be used for. It is dense and slightly overlong, with a long parenthetical example list and privacy advice that partly duplicates the schema field description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and annotations covering the safety profile, the description supplies everything else an agent needs: when to call it, the scope of jurisdictions, the sourced nature of results, privacy handling, and the fact that no verdict on the offer is produced.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented, including the enum for home_country and its purpose of supplying home reporting channels. The description reinforces that message may be a verbatim offer or a 'short account' of it, but adds no syntax or format guidance beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns the warning signs of recruitment and visa fraud that governments describe for an offer of a given kind and place, with sources, so the offer can be compared against them. It also draws a sharp boundary ('It does not judge the message itself'), distinguishing it from anything that would give a verdict on an offer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit trigger conditions (someone shares or describes a job offer, recruiter message or visa offer for work abroad) and explicit exclusions (not for declaring an offer genuine or safe, not for domestic jobs, not as legal advice on a visa case). It also states a privacy precondition about omitting passport, ID and bank numbers.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Work Abroad Check tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?