Skip to main content
Glama

indeed_listing: GET /

hasdata_indeed_listing_getJobListings
Read-only

Get Indeed Job Listings

Searches Indeed job listings by keyword and location with sort (relevance/date), country domain targeting, date-posted (1/3/7/14 days) and remote/hybrid filters. For pagination, pass the pagination.nextPage returned by the previous page back as the nextPage parameter. Indeed reranks a query differently on each request, so continuing by nextPage keeps the same ranking and returns a page that does not repeat or skip jobs, whereas the offset-based start parameter can return duplicates or miss jobs across pages. Returns an array of jobs with title, company, location, salary, posted date, job URL, sponsored flag, and jobKey (Indeed's stable job id, the only reliable dedup key for sponsored postings) for the requested page. With sponsoredOnly the request exits from the domain's country, where Indeed serves Canadian searches as sponsored postings. Use for job-market dashboards, role/geo hiring-trend analysis, sourcing pipelines, and generating URL lists to feed into the Indeed Job endpoint.

Input Schema

NameRequiredDescriptionDefault
sortNoThe sorting option for the search results.
startNoThe starting index of the results to retrieve from a single page. For ranked data spanning multiple pages, we recommend using only `nextPage`.
domainNoThe domain of the Indeed site (optional). Provide one exact documented value (62 allowed), e.g. `ar.indeed.com`, `au.indeed.com`.
keywordYesThe keyword used to search for job listings.
locationYesThe location to search for job listings.
nextPageNoThe recommended way to paginate. To fetch the next page, pass the `pagination.nextPage` value from the previous response to preserve the ranking order of the search results. When `nextPage` is passed, the `start` parameter is ignored.
datePostedNoReturns only jobs posted within the given number of days.
remoteTypeNoReturns only remote (`remote`) or hybrid (`hybrid`) jobs. In the US, Indeed ties fully remote jobs to the country rather than a city, so use a country-wide location such as `United States`: with a city, Indeed returns few or no remote jobs.
sponsoredOnlyNoWhen enabled, the request is made in a way that returns more sponsored listings. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / nextPage
      Added value: +{
      +  "description": "The recommended way to paginate. To fetch the next page, pass the `pagination.nextPage` value from the previous response to preserve the ranking order of the search results. When `nextPage` is passed, the `start` parameter is ignored.",
      +  "type": "string"
      +}
    • changedInput schema / properties / start / description
      Previous value: -"The starting index of the results to retrieve (optional)."New value: +"The starting index of the results to retrieve from a single page. For ranked data spanning multiple pages, we recommend using only `nextPage`."
  2. Changed3 schema fields changed
    • addedInput schema / properties / datePosted
      Added value: +{
      +  "description": "Returns only jobs posted within the given number of days.",
      +  "enum": [
      +    1,
      +    3,
      +    7,
      +    14
      +  ],
      +  "type": "number"
      +}
    • addedInput schema / properties / remoteType
      Added value: +{
      +  "description": "Returns only remote (`remote`) or hybrid (`hybrid`) jobs. In the US, Indeed ties fully remote jobs to the country rather than a city, so use a country-wide location such as `United States`: with a city, Indeed returns few or no remote jobs.",
      +  "enum": [
      +    "remote",
      +    "hybrid"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / sponsoredOnly
      Added value: +{
      +  "description": "When enabled, the request is made in a way that returns more sponsored listings. Defaults to false.",
      +  "type": "boolean"
      +}
  3. Changed2 schema fields changed
    • changedInput schema / properties / domain / description
      Previous value: -"The domain of the Indeed site (optional)."New value: +"The domain of the Indeed site (optional). Provide one exact documented value (62 allowed), e.g. `ar.indeed.com`, `au.indeed.com`."
    • removedInput schema / properties / domain / enum
      Removed value: -[
      -  "ar.indeed.com",
      -  "au.indeed.com",
      -  "at.indeed.com",
      -  "bh.indeed.com",
      -  "be.indeed.com",
      -  "br.indeed.com",
      -  "ca.indeed.com",
      -  "cl.indeed.com",
      -  "cn.indeed.com",
      -  "co.indeed.com",
      -  "cr.indeed.com",
      -  "cz.indeed.com",
      -  "dk.indeed.com",
      -  "ec.indeed.com",
      -  "eg.indeed.com",
      -  "fi.indeed.com",
      -  "fr.indeed.com",
      -  "de.indeed.com",
      -  "gr.indeed.com",
      -  "hk.indeed.com",
      -  "hu.indeed.com",
      -  "in.indeed.com",
      -  "id.indeed.com",
      -  "ie.indeed.com",
      -  "il.indeed.com",
      -  "it.indeed.com",
      -  "jp.indeed.com",
      -  "kw.indeed.com",
      -  "lu.indeed.com",
      -  "malaysia.indeed.com",
      -  "mx.indeed.com",
      -  "ma.indeed.com",
      -  "nl.indeed.com",
      -  "nz.indeed.com",
      -  "ng.indeed.com",
      -  "no.indeed.com",
      -  "om.indeed.com",
      -  "pk.indeed.com",
      -  "pa.indeed.com",
      -  "pe.indeed.com",
      -  "ph.indeed.com",
      -  "pl.indeed.com",
      -  "pt.indeed.com",
      -  "qa.indeed.com",
      -  "ro.indeed.com",
      -  "sa.indeed.com",
      -  "sg.indeed.com",
      -  "za.indeed.com",
      -  "kr.indeed.com",
      -  "es.indeed.com",
      -  "se.indeed.com",
      -  "ch.indeed.com",
      -  "tw.indeed.com",
      -  "th.indeed.com",
      -  "tr.indeed.com",
      -  "ua.indeed.com",
      -  "ae.indeed.com",
      -  "uk.indeed.com",
      -  "www.indeed.com",
      -  "uy.indeed.com",
      -  "ve.indeed.com",
      -  "vn.indeed.com"
      -]
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), so the description's value is the added context it supplies: Indeed reranks per request, offset pagination can duplicate or skip jobs, and jobKey is the only stable dedup key for sponsored postings. The sponsoredOnly/Canada sentence is dense and somewhat ambiguous about what actually changes geographically, which keeps this below a 5.

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?

Purpose is front-loaded in the first line and the pagination rule follows immediately, which is the right priority order. The prose is dense and the sponsoredOnly sentence is grammatically tangled ("exits from the domain's country"), costing a little clarity without adding bulk.

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 9-parameter search tool with no output schema, the description closes the important gaps: it defines the return array's fields (title, company, salary, posted date, URL, sponsored flag, jobKey) and prescribes the pagination contract end-to-end. Nothing an agent needs to call it correctly or chain it into the job-details sibling is missing.

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

Parameters4/5

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, but the description adds real meaning beyond the schema by explaining *why* nextPage outranks start (ranking preservation, no duplicates/skips) and by describing the returned fields the filters affect. The sponsoredOnly explanation is the weakest link, partly restating and partly obfuscating the schema's own wording.

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?

Opens with a specific verb+resource ("Get Indeed Job Listings") and immediately enumerates its distinguishing scope: keyword+location search with sort, domain, date-posted and remote filters. It also differentiates from the only sibling by positioning its output as URL lists to "feed into the Indeed Job endpoint", so an agent can separate this from hasdata_indeed_job_getJobDetails without opening a schema.

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?

States concrete use cases (job-market dashboards, role/geo hiring trends, sourcing pipelines, URL-list generation) and gives an explicit either/or rule between the two pagination options, warning that `start` is offset-based while `nextPage` preserves ranking. It further conditions `remoteType` on country-wide locations in the US and explains the sponsoredOnly domain behavior, so the agent knows when each parameter applies.

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