Live job openings from Workday, Greenhouse, Lever, Ashby, Workable and Personio career sites.
Scored across 6 tools
The two scraper tools (ats-jobs-scraper and workday-jobs-scraper) are nearly indistinguishable: both claim to auto-detect Workday, Greenhouse, Lever, Ashby, Workable, Recruitee, and Personio, differing mainly in price and filter fields. An agent cannot reliably pick which one to call for a given company, forcing arbitrary or duplicate selection. The four platform tools (abort/get run, dataset items, key-value record) are distinct from each other.
The platform tools follow a clean kebab-case verb-noun pattern (abort-actor-run, get-actor-run, get-dataset-items, get-key-value-store-record), but the two actor tools use a totally different vendor-prefixed convention (kadi_bence--ats-jobs-scraper) with underscores and a double dash. Readable, but two conventions coexist in one set.
Six tools is a small but reasonable set, yet the composition is lopsided: two domain-specific scrapers sit alongside four generic Apify plumbing tools, so the 'hiring signals' surface is thin. It leans toward borderline rather than well-scoped.
Core scraping plus reading dataset output is covered, but there are hard dead ends: get-key-value-store-record needs an exact key with no tool to list keys or stores, and there is no way to list actors or discover actor IDs. The hiring-signals workflow also lacks any resume/aggregate or field-selection support beyond dataset filtering.
Abort an Actor run that is currently starting or running. For runs with status SUCCEEDED, FAILED, ABORTING, ABORTED, or TIMED-OUT, this call has no effect. The results will include the updated run details after the abort request.
USAGE:
Use when you need to stop a run that is taking too long or misconfigured.
USAGE EXAMPLES:
user_input: Abort run y2h7sK3Wc
user_input: Gracefully abort run y2h7sK3Wc
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The ID of the Actor run to abort. | |
| gracefully | No | If true, the Actor run will abort gracefully with a 30-second timeout. |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the no-effect-on-terminal-states rule, which is exactly what makes the idempotent hint meaningful, plus the fact that updated run details come back. It omits auth/permission requirements and any rate-limit behavior.
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 and the state constraint, and every prose sentence earns its place. The 'USAGE EXAMPLES' block of raw user_input lines is mostly decorative and pads the definition slightly.
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 an output schema present, return values need not be spelled out, and the description still notes that updated run details are returned. For a two-parameter mutation with full annotation coverage, only auth requirements are unaddressed, which is a minor gap.
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 description coverage is 100%, so both parameters and the 30-second graceful-abort timeout are already documented in the schema. The description only gestures at 'gracefully' via an example, adding no syntax or semantic meaning beyond the schema. Baseline 3 applies.
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?
Specific verb (Abort) plus resource (Actor run) and a state qualifier ('currently starting or running'), which immediately distinguishes it from siblings like call-actor and get-actor-run. An agent can select it without opening the 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?
Explicit when-to-use ('stop a run that is taking too long or misconfigured') and an explicit no-op condition (terminal statuses such as SUCCEEDED, FAILED, ABORTED, TIMED-OUT). It does not name an alternative tool or describe prerequisites, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Actor run.
Returns run result: status, storages (datasets/keyValueStores alias map), stats, summary, nextStep.
summary describes the past (e.g. "SUCCEEDED in 22s. 47 items; 3 fields available.").
nextStep prescribes one primary follow-up action with identifiers interpolated (e.g. "Use get-dataset-items with datasetId=...").
waitSecs (0–45, default 30) waits up to that many seconds for terminal status before returning.
USAGE:
Use to check the status of a run started by any Actor-running tool.
Pass waitSecs > 0 to block until terminal (or until the cap elapses).
USAGE EXAMPLES:
user_input: Show details of run y2h7sK3Wc
user_input: Wait for run y2h7sK3Wc to finish
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The ID of the Actor run. | |
| waitSecs | No | Maximum seconds to wait for the run to reach a terminal state (SUCCEEDED, FAILED, ABORTED, TIMED-OUT). 0 returns immediately with the current status. Cap: 45. Default: 30. |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, but the description adds real behavioral context beyond them: the summary vs. nextStep semantics, and that waitSecs blocks for up to 45s (default 30) before returning the current state. This is substantive added value, though it doesn't cover error/failure modes.
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 purpose, then segmented into Returns/USAGE/EXAMPLES blocks. Every line carries information, though the two usage examples are somewhat redundant with the USAGE prose, adding minor length.
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 an output schema present and 100% parameter coverage, the description need only orient the agent, which it does fully: purpose, when to use, wait semantics, and concrete invocation examples. Nothing needed to call it 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%, so the baseline is 3, but the description goes further by framing waitSecs as a blocking/wait mechanism with its cap and default, and by describing what runId's run produces. Slight above-baseline value over the schema text.
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 and resource ('Get detailed information about a specific Actor run') and enumerates the returned result fields (status, storages, stats, summary, nextStep). It does not explicitly distinguish itself from siblings like call-actor or abort-actor-run, so it falls just short of the 5 benchmark.
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 USAGE block names the condition ('check the status of a run started by any Actor-running tool') and explains when to pass waitSecs > 0 to block until terminal. It gives clear context but stops short of explicit exclusions or naming the sibling to use for other run operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get items (rows) from a dataset — the output/results produced by an Actor run. Returns the rows themselves, not dataset metadata, counts, or a schema. When the user provides a datasetId and asks to retrieve results, output, data, or rows, call this tool directly. Default limit is 20. Use clean=true to skip empty items and hidden fields.
USAGE:
Use when you need to read data from a dataset (all items or only selected fields).
USAGE EXAMPLES:
user_input: Retrieve results from dataset abc123
user_input: Get only metadata.url and title from dataset username~my-dataset
| Name | Required | Description | Default |
|---|---|---|---|
| desc | No | If true, results are returned in reverse order (newest to oldest). | |
| omit | No | Comma-separated list of fields to exclude from results. | |
| clean | No | If true, returns only non-empty items and skips hidden fields (starting with #). Shortcut for skipHidden=true and skipEmpty=true. | |
| limit | No | Maximum number of items to return. Default is 20. | |
| fields | No | Comma-separated list of fields to include in results. Fields in output are sorted as specified. Use dot notation for nested objects (e.g. "metadata.url"); the server auto-flattens parent prefixes. | |
| offset | No | Number of items to skip at the start. Default is 0. | |
| flatten | No | Comma-separated list of fields to flatten (e.g. flatten="metadata" turns {"metadata":{"url":"x"}} into {"metadata.url":"x"}). Normally derived automatically from dot-notation in `fields`; specify only as a diagnostic override. | |
| datasetId | Yes | Dataset ID or username~dataset-name. |
| Name | Required | Description |
|---|---|---|
| items | Yes | Dataset items |
| limit | Yes | Limit used for pagination |
| offset | Yes | Offset used for pagination |
| summary | Yes | Summary of the result |
| nextStep | Yes | One follow-up action with tool name |
| datasetId | Yes | Dataset ID |
| itemCount | Yes | Number of items returned |
| totalItemCount | Yes | Total items in dataset |
| apifyConsoleUrl | No | Personalized Apify Console link to the dataset; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds valuable behavioral context: returns rows themselves, default limit of 20, and clean=true behavior. It also clarifies the nature of the return value beyond the schema.
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?
Well-structured with clear USAGE and USAGE EXAMPLES sections. Some redundancy ('Get items (rows)...' and 'Returns the rows themselves...') but overall efficient and front-loaded with purpose.
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 tool has 8 parameters, an output schema, and rich annotations, the description adequately covers key behaviors, usage triggers, and examples. It doesn't explain every parameter but relies on the schema for that, which is appropriate.
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 baseline is 3. The description adds extra meaning by explaining default limit (20) and the clean=true shortcut, which supplements the schema. It also provides examples for fields usage, though most parameter semantics are in the schema.
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?
Description clearly states the tool gets items (rows) from a dataset and explicitly distinguishes it from metadata, counts, or schema. It names the exact resource (dataset items) and the action (get), and provides direct trigger phrases for when to use it.
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 ('when the user provides a datasetId and asks to retrieve results...'), and clarifies what it is not for (metadata, counts, schema). However, it does not name alternative tools explicitly, only implies them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the value stored under a specific key in a key-value store — a single record, not a listing of all keys. Requires the exact key name. The response preserves the original Content-Encoding; most clients handle decompression automatically.
USAGE:
Use when you need to retrieve a specific record (JSON, text, or binary) from a store.
USAGE EXAMPLES:
user_input: Get record INPUT from store abc123
user_input: Get record data.json from store username~my-store
| Name | Required | Description | Default |
|---|---|---|---|
| recordKey | Yes | Key of the record to retrieve. | |
| keyValueStoreId | Yes | Key-value store ID or username~store-name. |
| Name | Required | Description |
|---|---|---|
| key | Yes | Record key |
| value | Yes | The stored value (JSON, text, or binary) |
| summary | Yes | Summary of the result |
| contentType | No | MIME type of the stored value |
| keyValueStoreId | Yes | Key-value store ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuine context beyond that: the exact key name is required, and the response preserves the original Content-Encoding with most clients decompressing automatically. That encoding note is real operational value an agent would otherwise not know.
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 and scope, then a short behavioral note, then usage. The USAGE line slightly overlaps the first sentence, but the examples earn their space by showing realistic inputs. No filler.
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 an output schema present there is no need to describe return values, and the annotations carry the safety profile. For a two-parameter read tool, the description supplies everything else an agent needs: exactness of the key, allowed value types, and the encoding caveat.
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 description coverage is 100%, so the baseline is 3. The description still adds a semantic constraint the schema omits — that the key must be an exact match — and the examples show the 'username~my-store' form of the store ID, gently reinforcing the ID format.
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?
Specific verb (get) + resource (value under a key in a key-value store) with an explicit scope boundary: 'a single record, not a listing of all keys.' None of the sibling tools overlap with this resource, and the anti-scope clause removes any ambiguity about whether it enumerates keys.
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 USAGE line gives a clear triggering condition — retrieving a specific record (JSON, text, or binary) — and two concrete examples anchor it. It lacks explicit when-not-to-use guidance or named alternatives, but no similar sibling exists to route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool calls the Actor "kadi_bence/ats-jobs-scraper" and retrieves its output results. Actor description: Get open jobs of any company by name: Stripe, Ramp (Greenhouse, Lever, Ashby, Workable, Recruitee, Personio) and NVIDIA, Salesforce (Workday) in one run, board auto-detected. Filters: title, location, remote. Returns per job: title, team, location, salary, date, URL. Default: 20/company. $1.25/1K.
| Name | Required | Description | Default |
|---|---|---|---|
| waitSecs | No | Max seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state. For long-running Actors the response returns at the cap with the current run status; follow `nextStep` to poll via get-actor-run. Set to 0 to fire-and-forget. | |
| companies | No | One per line, e.g. Stripe, ramp.com, Hugging Face, or a board URL like https://jobs.lever.co/spotify. The Actor detects which applicant tracking system (ATS) each company uses; the RUN_SUMMARY record shows the board it found. If a company is not found, open its careers page, click a job and paste the board URL (e.g. https://job-boards.greenhouse.io/stripe). Example values: ["Stripe","Ramp","Hugging Face"] | |
| locations | No | Keep jobs whose location text contains ANY of these as a whole word, e.g. London, Germany, US, Remote ('US' matches 'Remote - US' but not 'Austin'). A job with several locations is kept if any of them matches. Not case-sensitive. Leave empty for all. | |
| remoteOnly | No | Keep only jobs whose work mode is remote (from the ATS's workplace field, or 'remote' in the location or title). | |
| monitorName | No | Separate 'already seen' lists for different schedules, e.g. 'engineers' and 'sales'. Use a new name to start over with a fresh baseline. Example values: "default" | default |
| onlyNewJobs | No | Remember returned jobs and output only NEW ones on later runs. Ideal for a daily schedule (hiring signals, job alerts). The first run stores a baseline and returns everything. You only pay for new jobs. Jobs cut off by 'Max jobs per company' are not remembered, so they come in a later run. | |
| atsPlatforms | No | Which applicant systems to try when detecting a company's job board. Leave all selected unless you know the platform (fewer = faster). Workday is tried only when none of the others has the company (large employers like NVIDIA, Salesforce, Intel). Board URLs are always read directly. Example values: ["greenhouse","lever","ashby","workable","recruitee","personio","workday"] | |
| titleExcludes | No | Drop jobs whose title contains ANY of these words, e.g. intern, senior, manager. Not case-sensitive ('intern' also drops 'International'; use 'internship' to be precise). Filtered-out jobs are not charged. | |
| titleIncludes | No | Keep only jobs whose title contains ANY of these words, e.g. engineer, data scientist. Not case-sensitive. Leave empty for all titles. Filtered-out jobs are not saved and not charged. | |
| titleKeywords | No | Same as 'Job title must contain' above, as one comma-separated text, e.g. 'engineer, data'. Kept for existing tasks; both lists are combined. | |
| postedWithinDays | No | Only jobs posted in the last N days, e.g. 7. Use 1 for jobs posted in about the last day. Leave empty for any date. | |
| stripContactInfo | No | Removes e-mail addresses and phone numbers from descriptions. Recommended, so you don't store personal data (GDPR). Example values: true | |
| descriptionFormat | No | How to output the job description. Example values: "text" | text |
| maxJobsPerCompany | No | Stop after this many jobs per company. 0 = no limit (all open jobs). The default without input (API, MCP and AI-agent calls) is 20. Example values: 20 | |
| proxyConfiguration | No | Not needed for these public APIs. Enable only if you see blocking errors. Example values: {"useApifyProxy":false} |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=true and destructiveHint=true, so the agent knows this triggers an external, side-effecting run. The description adds genuinely useful non-schema context: pricing at $1.25/1K jobs and a default cap of 20 per company. It stops short of saying what gets written where (dataset vs. key-value store) or that repeated runs incur repeated charges.
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?
Roughly three sentences, front-loaded with the action and followed by a dense capability/cost summary; nothing is gratuitous. The opening 'This tool calls the Actor ... and retrieves its output results' is boilerplate wrapper text that could be dropped without loss, keeping it short of a 5.
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?
For a 15-parameter, zero-required wrapper with a full schema and an output schema, the description covers purpose, scope, defaults and cost adequately. It omits the one thing an agent most needs to choose between this and kadi_bence--workday-jobs-scraper, and says nothing about how to handle partial/failed company detection beyond the RUN_SUMMARY record mentioned in the schema.
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 description coverage is 100%, so every one of the 15 parameters is already documented in the schema, including waitSecs polling semantics and the ATS platform enum. The description only restates the filter dimensions (title, location, remote) and the returned fields, adding no syntax or format detail beyond the schema, so the baseline 3 applies.
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 concrete verb and resource: calls the kadi_bence/ats-jobs-scraper Actor, which gets open jobs of any company by name across Greenhouse, Lever, Ashby, Workable, Recruitee, Personio and Workday, with board auto-detection and title/location/remote filters. That is specific enough for an agent to know what it does. It never acknowledges the sibling kadi_bence--workday-jobs-scraper, so the boundary between the two (this one covers Workday 'only when none of the others has the company') is left for the agent to infer.
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 text describes capability ('Get open jobs of any company by name') but gives no when-to-use, when-not-to-use, or alternative-tool routing, even though a directly overlapping sibling (kadi_bence--workday-jobs-scraper) exists. The $1.25/1K and 20/company default hint at cost-sensitive use but are not framed as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool calls the Actor "kadi_bence/workday-jobs-scraper" and retrieves its output results. Actor description: Get open jobs of any company by name: NVIDIA, Salesforce, Intel (Workday) and Stripe, Ramp (Greenhouse, Lever, Ashby, Workable, Personio) in one run, system auto-detected. Filters: title, country, date. Returns per job: title, team, location, salary, date, URL. Default: 20/company. $0.90/1K.
| Name | Required | Description | Default |
|---|---|---|---|
| waitSecs | No | Max seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state. For long-running Actors the response returns at the cap with the current run status; follow `nextStep` to poll via get-actor-run. Set to 0 to fire-and-forget. | |
| companies | No | Easiest option: type company names or domains, one per line, e.g. NVIDIA, Salesforce, intel.com. The Actor finds their Workday career site(s) automatically; the RUN_SUMMARY record lists the boards it found. A domain is more precise than a common word (target.com instead of Target). Companies not on Workday (e.g. Stripe) are looked up on Greenhouse, Lever, Ashby, Workable, Recruitee and Personio automatically. If a company is still not found, paste its career site URL below. Example values: ["NVIDIA"] | |
| countries | No | Keep only jobs in these countries: names or ISO codes, e.g. US, Germany, GB. Jobs with several locations are kept if ANY location matches. Uses the career site's own country filter when it has one (faster). Other words (e.g. California) are matched as location text. Filtered-out jobs are not charged. | |
| startUrls | No | Or paste Workday career site URLs, e.g. https://nvidia.wd5.myworkdayjobs.com/NVIDIAExternalCareerSite. A URL with filters applied on the career site (location, category, search) keeps those filters. Single job URLs work too (the whole board is scraped). | |
| careerSites | No | Large companies often run several Workday boards (main, students, subsidiaries). 'All' scrapes every public board; 'Main only' picks the primary external board. Example values: "all" | all |
| monitorName | No | Use different names to keep separate 'already seen' lists for different schedules with the same URLs. Example values: "default" | default |
| onlyNewJobs | No | Remember which jobs were already returned and output only NEW postings on the next runs. Ideal for scheduled runs (daily alerts). The first run outputs everything and stores a baseline. You only pay for new jobs. | |
| titleExcludes | No | Drop jobs whose title contains ANY of these words, e.g. intern, senior, manager. Not case-sensitive ('intern' also drops 'International'; use 'internship' to be precise). Filtered-out jobs are not charged. | |
| titleIncludes | No | Keep only jobs whose title contains ANY of these words, e.g. engineer, data scientist. Not case-sensitive. Leave empty for all titles. Filtered-out jobs are not saved and not charged. | |
| includeDetails | No | Fetch each job's detail page: description, exact posted date, all locations, country, salary. Turn off for a faster, cheaper title/location-only list. Example values: true | |
| maxConcurrency | No | Parallel requests to the career site. Keep it low to be polite; 4 is fast enough for most boards. Example values: 4 | |
| maxJobsPerSite | No | Stop after this many jobs per career site. 0 = no limit (all jobs, even boards with 10,000+ postings). The Console prefill is 50 for a quick test run. The default without input (API, MCP and AI-agent calls) is 20. Example values: 50 | |
| searchKeywords | No | Optional full-text search, exactly like the search box on the career site (e.g. "data engineer"). Leave empty for all jobs. | |
| postedWithinDays | No | Only return jobs posted in the last N days (e.g. 7). Leave empty for any date. | |
| stripContactInfo | No | Recommended (GDPR). Some postings include a recruiter's personal contact details; this removes them. Example values: true | |
| descriptionFormat | No | How to output the job description. Example values: "text" | text |
| proxyConfiguration | No | Usually not needed: Workday career sites are public. Enable Apify Proxy only if you see many 403/429 errors. Example values: {"useApifyProxy":false} | |
| otherSystemsFallback | No | When a company name has no Workday career site, look for its Greenhouse, Lever, Ashby, Workable, Recruitee or Personio job board instead (e.g. Stripe, Ramp, Hugging Face), so one run covers big employers and startups. Same output fields; the 'ats' field shows the source. Example values: true |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the agent knows this triggers an open-world, potentially costly operation. The description adds genuinely useful non-annotation context: the cost model ('$0.90/1K'), the default volume (20/company), and that the tool invokes an Actor and retrieves its results. It does not, however, explain run lifecycle, the waitSecs/nextStep polling contract, or what 'destructive' actually means here, so it remains partial.
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?
Two sentences, front-loaded with the mechanism ('calls the Actor ... retrieves its output results') followed by the dense capability summary. The wrapper boilerplate is slightly redundant, but the size is proportionate to an 18-parameter tool and every clause carries information.
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?
An output schema exists, so return-value explanation is optional, yet the description still lists the key per-job fields. With all 18 parameters fully documented in the schema and the actor's scope, ATS coverage, defaults and pricing stated, an agent has enough to call this correctly.
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 description coverage is 100% across all 18 parameters, so the schema already documents every field in depth. The description only gestures at a subset (title/country/date filters), adding no syntax, format, or interaction detail beyond the schema. Baseline 3 is appropriate 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieve open jobs for named companies across Workday and other ATS platforms, with concrete filters (title, country, date) and return fields. It is unambiguous about what the tool does, but it never distinguishes itself from the very similar sibling kadi_bence--ats-jobs-scraper, leaving the agent to guess which job scraper to pick.
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 use case is clearly implied ('get open jobs of any company by name'), and the auto-detection behavior plus fallback to Greenhouse/Lever/etc. is noted. However, there is no explicit when-to-use/when-not guidance and no mention of the closely related ats-jobs-scraper sibling, so routing between the two job tools is left to inference.
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.
kadi_bence--ats-jobs-scraper2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / companyName / typePrevious value: -[
- "string",
- "null"
-]New value: +[
+ "null",
+ "string"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / updatedDate / typePrevious value: -[
- "string",
- "null"
-]New value: +[
+ "null",
+ "string"
+]kadi_bence--ats-jobs-scraper2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / companyName / typePrevious value: -[
- "null",
- "string"
-]New value: +[
+ "string",
+ "null"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / updatedDate / typePrevious value: -[
- "null",
- "string"
-]New value: +[
+ "string",
+ "null"
+]kadi_bence--ats-jobs-scraper2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / companyName / typePrevious value: -[
- "string",
- "null"
-]New value: +[
+ "null",
+ "string"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / updatedDate / typePrevious value: -[
- "string",
- "null"
-]New value: +[
+ "null",
+ "string"
+]kadi_bence--ats-jobs-scraper2 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / companyName / typePrevious value: -[
- "null",
- "string"
-]New value: +[
+ "string",
+ "null"
+]Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / updatedDate / typePrevious value: -[
- "null",
- "string"
-]New value: +[
+ "string",
+ "null"
+]Live job postings from company career pages on Greenhouse, Lever, Ashby and SmartRecruiters.
Live jobs from Greenhouse, Lever, Ashby, Workable, Recruitee and Teamtailor, with normalised salary.
Career-site jobs from Workday, Greenhouse, Lever, Ashby, iCIMS and more, with salaries where posted.
Open roles from public Greenhouse, Lever, Ashby, Workable job boards as clean data. Winters Works.
Add one secure layer between your agents and this server.