Skip to main content
Glama

search_jobs

Read-only

Search live, normalized job postings across 30+ sources by title, skill/tech, country, remote, seniority, employment type and recency. Returns real matching postings -- title, company, domain, location, salary range, tech stack and apply URL -- capped at 3 rows per call on this no-key server, with whether more match and the REST call that returns the rest (and the exact count).

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum rows to return.
remoteNoOnly remote roles when true.
city_orNoWhole city names, e.g. London, Munich. Case-insensitive; a metro wrapper on the stored value is ignored. Spellings and diacritics are normalised for cities we know (München finds Munich, Cracow finds Kraków); other cities match the stored value exactly.
region_orNoUS states and Canadian provinces as ISO 3166-2 codes, e.g. US-NY, CA-ON. Matches every spelling a job board publishes, so CA-ON finds both ON and Ontario. More precise than job_location_or for a state or province.
skills_orNoMatch jobs tagged with any of these skill slugs, e.g. python, kubernetes.
benefits_orNoMatch jobs advertising any of these benefit slugs, e.g. 401k, health insurance. Coverage is partial.
language_orNoLanguages the posting is written in, as lowercase ISO 639-1 codes, e.g. ["en"]. The language of the posting text, not the country: 18.3% of Swedish postings and 17.7% of German ones are in English. Unlabelled postings never match.
job_title_orYesMatch any of these job titles.
language_notNoExclude postings written in these languages, as lowercase ISO 639-1 codes, e.g. ["fr"]. Unlabelled postings are kept.
metro_code_orNoMatch any of these US CBSA metro codes, e.g. 35620 for New York. Non-US jobs never match.
description_orNoMatch any of these skills or technologies in the posting.
min_salary_usdNoOnly jobs whose posted salary reaches this annual USD amount. Jobs without a posted salary never match; estimated salaries are not consulted.
job_location_orNoMatch any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA). Terms of three characters or fewer are codes or exact names and match whole values (WA is Washington state, never Iowa); a country code or name matches the whole country. For a city by name, city_or is the precise filter.
max_ghost_scoreNoExclude jobs whose ghost-likelihood score (0-100) exceeds this. Unscored jobs always pass.
esco_skill_id_orNoMatch jobs tagged with any of these ESCO skill concept IDs (exact match).
isic_division_orNoISIC Rev.4 employer industry divisions (2-digit, e.g. 62).
job_seniority_orNoMatch any of these seniority levels.
employment_type_orNoMatch any of these employment types.
occupation_code_orNoISCO-08 occupation codes; 4-digit exact, 1-3 digit as hierarchy prefix.
has_recruiter_emailNotrue for only jobs with a recruiter contact email parsed from the posting, false for only jobs without one.
job_country_code_orNoMatch any of these ISO 3166-1 alpha-2 country codes.
max_applicant_countNoOnly jobs with at most this many applicants. Counts exist only where the source exposes them (LinkedIn), so this also drops every job without a count.
visa_sponsorship_orNoMatch any of these visa stances parsed from the posting text: offers, no, citizenship_required. Jobs that say nothing never match.
work_arrangement_orNoMatch any of remote, hybrid or onsite. Finer than remote, which answers false for hybrid and onsite alike. Jobs whose arrangement is unknown never match, and coverage is still backfilling, so this returns far fewer results than expected today; remote is the reliable filter for now.
posted_at_max_age_daysNoOnly postings published within this many days.
include_unlabeled_employment_typeNoAlso return jobs whose employment type is unknown. About 27% of postings do not state one, and employment_type_or excludes every one of them by default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / language_not
      Added value: +{
      +  "description": "Exclude postings written in these languages, as lowercase ISO 639-1 codes, e.g. [\"fr\"]. Unlabelled postings are kept.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / language_or
      Added value: +{
      +  "description": "Languages the posting is written in, as lowercase ISO 639-1 codes, e.g. [\"en\"]. The language of the posting text, not the country: 18.3% of Swedish postings and 17.7% of German ones are in English. Unlabelled postings never match.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / city_or
      Added value: +{
      +  "description": "Whole city names, e.g. London, Munich. Case-insensitive; a metro wrapper on the stored value is ignored. Spellings and diacritics are normalised for cities we know (München finds Munich, Cracow finds Kraków); other cities match the stored value exactly.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / job_location_or / description
      Previous value: -"Match any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA). Terms of three characters or fewer are codes or exact names and match whole values (WA is Washington state, never Iowa); a country code or name matches the whole country."New value: +"Match any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA). Terms of three characters or fewer are codes or exact names and match whole values (WA is Washington state, never Iowa); a country code or name matches the whole country. For a city by name, city_or is the precise filter."
  3. Changed1 schema field changed
    • changedInput schema / properties / job_location_or / description
      Previous value: -"Match any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA)."New value: +"Match any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA). Terms of three characters or fewer are codes or exact names and match whole values (WA is Washington state, never Iowa); a country code or name matches the whole country."
  4. Changed1 schema field changed
    • changedInput schema / properties / job_location_or / description
      Previous value: -"Match any of these cities or regions, e.g. Seattle, WA."New value: +"Match any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA)."
  5. Changed1 schema field changed
    • addedInput schema / properties / include_unlabeled_employment_type
      Added value: +{
      +  "description": "Also return jobs whose employment type is unknown. About 27% of postings do not state one, and employment_type_or excludes every one of them by default.",
      +  "type": "boolean"
      +}
  6. Changed8 schema fields changed
    • addedInput schema / properties / benefits_or
      Added value: +{
      +  "description": "Match jobs advertising any of these benefit slugs, e.g. 401k, health insurance. Coverage is partial.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / esco_skill_id_or
      Added value: +{
      +  "description": "Match jobs tagged with any of these ESCO skill concept IDs (exact match).",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / has_recruiter_email
      Added value: +{
      +  "description": "true for only jobs with a recruiter contact email parsed from the posting, false for only jobs without one.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / max_applicant_count
      Added value: +{
      +  "description": "Only jobs with at most this many applicants. Counts exist only where the source exposes them (LinkedIn), so this also drops every job without a count.",
      +  "type": "number"
      +}
    • addedInput schema / properties / max_ghost_score
      Added value: +{
      +  "description": "Exclude jobs whose ghost-likelihood score (0-100) exceeds this. Unscored jobs always pass.",
      +  "type": "number"
      +}
    • addedInput schema / properties / metro_code_or
      Added value: +{
      +  "description": "Match any of these US CBSA metro codes, e.g. 35620 for New York. Non-US jobs never match.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / min_salary_usd
      Added value: +{
      +  "description": "Only jobs whose posted salary reaches this annual USD amount. Jobs without a posted salary never match; estimated salaries are not consulted.",
      +  "type": "number"
      +}
    • addedInput schema / properties / visa_sponsorship_or
      Added value: +{
      +  "description": "Match any of these visa stances parsed from the posting text: offers, no, citizenship_required. Jobs that say nothing never match.",
      +  "items": {
      +    "enum": [
      +      "offers",
      +      "no",
      +      "citizenship_required"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  7. Changed1 schema field changed
    • addedInput schema / properties / region_or
      Added value: +{
      +  "description": "US states and Canadian provinces as ISO 3166-2 codes, e.g. US-NY, CA-ON. Matches every spelling a job board publishes, so CA-ON finds both ON and Ontario. More precise than job_location_or for a state or province.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  8. Changed1 schema field changed
    • addedInput schema / properties / work_arrangement_or
      Added value: +{
      +  "description": "Match any of remote, hybrid or onsite. Finer than remote, which answers false for hybrid and onsite alike. Jobs whose arrangement is unknown never match, and coverage is still backfilling, so this returns far fewer results than expected today; remote is the reliable filter for now.",
      +  "items": {
      +    "enum": [
      +      "remote",
      +      "hybrid",
      +      "onsite"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  9. Changed3 schema fields changed
    • addedInput schema / properties / isic_division_or
      Added value: +{
      +  "description": "ISIC Rev.4 employer industry divisions (2-digit, e.g. 62).",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / occupation_code_or
      Added value: +{
      +  "description": "ISCO-08 occupation codes; 4-digit exact, 1-3 digit as hierarchy prefix.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / skills_or
      Added value: +{
      +  "description": "Match jobs tagged with any of these skill slugs, e.g. python, kubernetes.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  10. Changed1 schema field changed
    • addedInput schema / properties / job_location_or
      Added value: +{
      +  "description": "Match any of these cities or regions, e.g. Seattle, WA.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  11. Changed1 schema field changed
    • changedInput schema / required
      Previous value: -[]New value: +[
      +  "job_title_or"
      +]
  12. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnly and openWorld, so the description adds the substantive behavioral facts itself: the hard 3-row cap per call, that results are real live postings rather than stubs, what fields come back, and that the response includes a 'more matches' signal, the exact count, and the REST call to fetch the remainder. That is exactly the escalation path an agent needs when the cap truncates a result set.

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

Conciseness5/5

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

Two sentences: purpose and filter axes first, then what comes back and the row cap. The long second sentence is dense but each clause carries information an agent cannot get elsewhere (row cap, returned fields, continuation path). No filler.

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

Completeness4/5

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

For a 26-parameter tool with full schema coverage, no output schema and only read-only annotations, the description covers purpose, effective return shape, truncation and how to get the rest. It does not say whether filters combine with AND or OR, which matters here given the many *_or arrays.

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 description coverage is 100% with 26 documented parameters, so the schema already carries the semantics. The description only names the headline filter dimensions, which maps to but does not enrich the schema. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (Search) and resource (live, normalized job postings) plus the scope it covers: 30+ sources and the main filter axes. The sibling tools list_job_sources and list_pricing_plans are metadata utilities, so an agent can tell immediately that this is the only one that actually retrieves postings.

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

Usage Guidelines4/5

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

Gives clear usage context: it is the retrieval tool, results are capped at 3 rows on this no-key server, and the response carries the REST call that returns the rest. It does not state explicit exclusions or when another tool should be preferred, but with these siblings there is little ambiguity to resolve.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources