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 the total match count and the REST call that returns the rest.

Input Schema

TableJSON 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.5/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the 3-row cap per call on the no-key server, the total match count, and the REST call that returns the remaining results. It also states that results are real postings and lists the returned fields, which is valuable operational context an agent needs before invoking.

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 front-load the core purpose and then state the key operational limitation. Every clause earns its place: source scale, normalization, filter categories, return fields, row cap, total count, and continuation REST call.

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?

For a 26-parameter tool with no output schema, the description provides the essential return contract: fields returned, 3-row cap, total match count, and the REST call to retrieve the rest. The schema covers every parameter, and the sibling distinction is clear from names, so nothing required for correct invocation is missing.

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?

The input schema already provides full 100% per-parameter documentation, so the description correctly avoids repeating it. It adds only a high-level categorization of filter dimensions (title, skill/tech, country, remote, seniority, employment type, recency), which is useful orientation but no new semantic detail; 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 opens with a specific verb ('Search') and a clearly bounded resource ('live, normalized job postings across 30+ sources'), and it lists the main filter dimensions. This is plainly distinct from the siblings list_job_sources and list_pricing_plans, so no explicit differentiation is needed.

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?

The description clearly states what kind of query the tool serves and enumerates its filter dimensions, giving an agent the trigger conditions for use. It does not spell out explicit when-not-to-use exclusions, but the sibling tools are not competing search entry points, so the context is sufficient.

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