Indeed job listings by keyword and location, and full postings, as structured JSON.
Scored across 2 tools
The two tools are cleanly separated: one searches/lists jobs by keyword and location, the other fetches a single posting's full detail by URL. There is no overlap in purpose or inputs, and the discovery-to-enrichment workflow is explicitly described.
Both names follow the same provider-prefixed pattern (hasdata_indeed_…) with consistent camelCase verb_noun structure: getJobDetails and getJobListings. The convention is uniform and predictable.
Two tools is thin for a job-market data surface, even though list+detail is a coherent minimal pair. The server feels like a narrow slice of an API rather than a well-scoped toolset.
List and detail cover the core read workflow for job postings, which is the stated purpose, and no write operations are expected. Minor gaps exist, such as lookup by jobKey rather than only a viewjob URL, and no company- or salary-facet tools.
Get Indeed Job Details
Fetches a single Indeed job posting by its viewjob URL. Returns job title, company, location, salary/compensation, employment type, full description, and benefits. Use for ATS/CRM enrichment, compensation benchmarking, resume-to-JD matching with LLMs, and structured archival of postings discovered via the Indeed Listing endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the job vacancy to retrieve details for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral value by enumerating what is returned (title, company, location, salary, employment type, description, benefits) and noting it works on a single posting. No rate-limit or auth detail, but nothing contradicts the annotations.
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?
Front-loaded with the core action, followed by return payload and use cases. Every sentence earns its place, though the use-case list is slightly long and not all items are equally informative.
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 and only one required parameter, the description carries the return-value burden itself and does so by enumerating returned fields. Nothing an agent needs in order to call this correctly 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% for the single parameter, giving a baseline of 3. The description goes beyond the generic schema text ('URL of the job vacancy') by specifying it must be a 'viewjob URL', which constrains the expected input format meaningfully.
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+resource ('Fetches a single Indeed job posting by its viewjob URL') and explicitly distinguishes itself from the sibling listing endpoint. An agent can tell it apart from hasdata_indeed_listing_getJobListings and hasdata_glassdoor_job_getJobDetails 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?
Gives concrete usage contexts (ATS/CRM enrichment, compensation benchmarking, resume-to-JD matching, archival) and names the Listing endpoint as the discovery counterpart. It doesn't state exclusions or prerequisites, but the context is clear enough to select the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, and offset-based pagination (start). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | The sorting option for the search results. | |
| start | No | The starting index of the results to retrieve (optional). | |
| domain | No | The domain of the Indeed site (optional). Provide one exact documented value (62 allowed), e.g. `ar.indeed.com`, `au.indeed.com`. | |
| keyword | Yes | The keyword used to search for job listings. | |
| location | Yes | The location to search for job listings. | |
| datePosted | No | Returns only jobs posted within the given number of days. | |
| remoteType | No | 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. | |
| sponsoredOnly | No | When enabled, the request is made in a way that returns more sponsored listings. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/open-world, and the description layers on genuinely useful behavior: the returned field set, the warning that jobKey is the only reliable dedup key for sponsored postings, and the sponsoredOnly quirk where requests exit from the domain's country (Canadian results served as sponsored). These are non-obvious traits not derivable from annotations.
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 front-loaded paragraph that leads with purpose then progresses through filters, return shape, edge cases, and use cases. Dense but each clause carries information; slight overload on return-field enumeration.
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?
No output schema exists, so the description correctly compensates by listing the returned job fields and the stable jobKey. For an 8-parameter read tool with full annotation coverage, no call-critical information 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 the baseline is 3, but the description adds real semantic value beyond the schema: it clarifies jobKey's dedup role and the sponsoredOnly country-domain behavior. The remoteType country-vs-city nuance largely restates the schema description.
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 a specific verb+resource ('Searches Indeed job listings by keyword and location') and enumerates the filter scope. It also distinguishes itself from the sibling hasdata_indeed_job_getJobDetails by framing its output as URL lists to feed into the Indeed Job endpoint.
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?
Gives concrete application contexts (job-market dashboards, hiring-trend analysis, sourcing pipelines, URL-list generation for the Job endpoint). Clear when-to-use, but no explicit exclusions or statement of when the sibling detail endpoint should be preferred instead.
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.
hasdata_indeed_listing_getJobListings3 fields changedInput schema / properties / datePostedAdded value: +{
+ "description": "Returns only jobs posted within the given number of days.",
+ "enum": [
+ 1,
+ 3,
+ 7,
+ 14
+ ],
+ "type": "number"
+}Input schema / properties / remoteTypeAdded 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"
+}Input schema / properties / sponsoredOnlyAdded value: +{
+ "description": "When enabled, the request is made in a way that returns more sponsored listings. Defaults to false.",
+ "type": "boolean"
+}hasdata_indeed_job_getJobDetailshasdata_indeed_listing_getJobListingsGlassdoor job listings and full postings with company ratings and salary estimates, as JSON.
DISCONTINUED 2026-05-23. Indeed.com Cloudflare + DataDome anti-bot returns HTTP 403 on all scraping
Search job postings across Indeed, LinkedIn, and more from one request - titles, companies
LinkedIn job listings as JSON: salary, recruiter, applicants, company data. No login. From $0.40/1k
Add one secure layer between your agents and this server.
