Indeed job listings by keyword and location, and full postings, as structured JSON.
Scored across 2 tools
The two tools are clearly distinct: one searches for job listings and the other fetches details for a specific job. There is no meaningful overlap in their purpose or output.
Both tools share the hasdata_indeed_ prefix and use a get* action pattern, but the resource nouns differ ('job' vs 'listing') and 'getJobDetails' vs 'getJobListings' is slightly inconsistent. Overall the naming is still predictable and readable.
With only two tools, the surface feels thin, but it covers the core Indeed job search and detail use cases. It sits at the low end of reasonable for a specialized job-data server.
The two operations—searching for job listings and retrieving full job details—form a complete read-only workflow for the domain. No obvious missing endpoints are indicated by the descriptions.
Get Indeed Job Details
Fetches a single Indeed job posting by its viewjob URL. Returns job title, company, location, salary/compensation, employment type, posted date, full description, requirements/benefits, and apply URL. 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?
With no annotations, the description carries the full burden. It states what is returned but does not mention side effects, error handling, rate limits, or any read-only guarantees. The 'Fetches' wording implies a safe GET, but transparency is limited.
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?
The description is two sentences: first states the core function, second lists return fields and use cases. It is concise, well-structured, and every sentence adds value.
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?
Given the simple tool (one parameter, no output schema), the description fully covers what the tool does, what it returns, and when to use it. The relationship to the listing sibling is clarified, and no 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?
The single parameter 'url' is clearly described in the schema as 'The URL of the job vacancy to retrieve details for.' The tool description reinforces this with 'viewjob URL,' leaving no ambiguity about what input is expected.
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?
Clearly states it fetches a single Indeed job posting by viewjob URL, lists the returned fields, and distinguishes itself from the listing sibling by focusing on a single posting. The verb 'Fetches' and resource 'Indeed job posting' are specific and unambiguous.
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?
Provides explicit use cases (ATS/CRM enrichment, compensation benchmarking, resume-to-JD matching, structured archival) and references the Indeed Listing endpoint as the discovery source, implying this tool is for postings already found. Does not explicitly contrast with Glassdoor job details, but the context is sufficient for most agents.
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, and offset-based pagination (start). Returns an array of jobs with title, company, location, salary, posted date, job URL, and jobKey for the requested page. 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only search operation (GET) but does not explicitly state side effects, rate limits, or authentication requirements. The behavior is mostly transparent but lacks explicit safety language.
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?
The description is well-structured and readable but contains slight redundancy, repeating the search criteria and return format in consecutive sentences. It remains concise and to the point.
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?
Since there is no output schema, the description adequately explains the return format (array of jobs with listed fields). It also covers pagination and domain selection, giving sufficient context for correct invocation.
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?
All five parameters have descriptions, covering required and optional fields. The description adds context by explaining sort options, domain examples, and offset-based pagination, which goes beyond the schema definitions.
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?
The description clearly states that the tool retrieves Indeed job listings by keyword and location, with sorting and pagination options. It also distinguishes from the sibling tool by mentioning generating URL lists for the Indeed Job endpoint, implying a listing vs. detail perspective.
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?
The description provides explicit use cases such as job-market dashboards, hiring-trend analysis, and sourcing pipelines. It doesn't explicitly contrast with the sibling tool, but the intended scenarios are clear enough to guide selection.
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_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
Live job postings from 30+ ATS feeds and job boards, one schema. Live results need a Bearer key.
Scrape job listings from Greenhouse, Workable, Reed, RemoteOK and other boards. Pay per row.
Add one secure layer between your agents and this server.
