Skip to main content
Glama
fairquery

company-jobs-feed

Official

Search and monitor jobs across many companies (paid Apify Actor)

jobs_search_companies
Read-only

Search and monitor job postings across multiple company boards, tracking new, updated, closed, and reposted roles with filters for titles, locations, and departments.

Instructions

WHAT: Run the Fairquery Apify Actor fairquery/company-jobs-feed over many companies or boards: board discovery, search filters, per-board history (first_seen/last_seen, new/updated/closed, repost detection), optional per-job re-checks and descriptions. WHEN: Monitoring a company list ("what is new since yesterday?"), searching the verified starter list, or anything that needs history, closed/repost signals or more than a few boards. WHEN NOT: One board right now (jobs_get_board, free) or one job (jobs_check_open, free). BEHAVIOR: Read-only on job sites; requires APIFY_TOKEN and runs in YOUR Apify account (waits up to 300 s; history is kept in a named key-value store there). Same politeness rules as the free tools: documented ATS APIs only, 403/429 kill switch, robots.txt on careers pages. COST: Paid, pay-per-event, billed to your Apify account: $0.00099 per job row, $0.0005 per board scanned, $0.00029 per re-check (confirmOpen), $0.0019 per company found by discovery; no start fee. Error, closed and merged rows are free. Example: 3 boards, 300 jobs = about $0.30. maxJobs caps the job rows. RETURNS: Paged dataset rows: "job" rows (as jobs_get_board plus first_seen_at, last_seen_at, change, reposted, repost_of, stale_signal, duplicate_of), one "board" row per board (jobs_total, new, updated, closed), "company" rows for discovery, "error" rows (code, message, retryable). PARAMETERS: companies, boards and useSeedList: at least one is required although the schema marks all optional (none -> INPUT_EMPTY, not billed). onlyNew implies history and compares with the last run that used the same stateStoreName, so use one name per saved search; the first run returns everything as new. limit/offset page the returned rows locally; every call starts a new billed run, so fetch the pages you need from one result instead of re-calling. EXAMPLE: {"companies":["stripe.com","ramp.com"],"titleIncludes":["engineer"],"countries":["US"],"onlyNew":true}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoOptional page size, integer 1-500, default 50
boardsNoOptional. 0-500 exact boards. Example: [{"ats":"lever","slug":"palantir"}]
offsetNoOptional items to skip, integer >= 0, default 0; pass nextOffset from the previous response
remoteNoOptional, default "any"
maxJobsNoOptional integer 1-50000, default 5000: spend cap on billed job rows
onlyNewNoOptional boolean, default false: only new/changed jobs since the last tracked run (plus free closed rows)
companiesNoOptional (see PARAMETERS). 0-200 names, domains or board URLs. Example: ["stripe.com","Ramp","https://jobs.lever.co/palantir"]
countriesNoOptional ISO-2 codes, any-of. Example: ["US","GB"]
locationsNoOptional, 0-50 strings, any-of. Location substring match. Example: ["london"]
confirmOpenNoOptional boolean, default false: re-check each emitted job on its detail endpoint ($0.00029 each, max 200 per run)
departmentsNoOptional, 0-50 strings, any-of. Department/team substring match. Example: ["engineering"]
useSeedListNoOptional boolean, default false: also scan all verified starter boards (each billed as a board)
excludeStaleNoOptional boolean, default false: drop long_open and reposted rows
titleExcludesNoOptional, 0-50 strings, any-of. Whole-word title exclusion. Example: ["intern"]
titleIncludesNoOptional, 0-50 strings, any-of. Whole-word title match. Example: ["engineer"]
stateStoreNameNoOptional, default "fairquery-jobs-feed-state": named key-value store for history in your Apify account
postedWithinDaysNoOptional integer 1-3650 (ATS publish date). Example: 7
includeDescriptionNoOptional boolean, default false: add plain-text descriptions (PII-scrubbed)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaNoTool-specific context: board totals, request counts, cost notes
countYesNumber of items in this page
itemsYesResult rows. Each has "type": "job" (job_key, title, company, locations, countries, remote, posted_at, verified_open_at, age_days, long_open, apply_url, source_url, ...), "board", "company", "seed_board", "open_check" or "error" (code, message, retryable)
totalYesTotal items after filters, before paging
offsetYesOffset of the first item in this page
hasMoreYesTrue if more items exist after this page
nextOffsetYesOffset to pass for the next page, or null when done

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only provide readOnlyHint/openWorldHint/idempotentHint/destructiveHint, but the description adds a lot beyond them: requires APIFY_TOKEN, runs in the user's own Apify account, waits up to 300 s, persists history in a named key-value store, and documents politeness controls (ATS APIs only, 403/429 kill switch, robots.txt). Detailed pay-per-event cost breakdown and the 'each call starts a new billed run' caveat are disclosed. Nothing here 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded labeled sections (WHAT/WHEN/WHEN NOT/BEHAVIOR/COST/RETURNS/PARAMETERS/EXAMPLE) make it skimmable, and for an 18-parameter paid tool every section earns its place. The cost and 'one run, fetch your pages' guidance prevent classic misuse.

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?

Given the complexity (18 params, paid per-event billing, external Actor run), the description covers purpose, routing, auth, cost, behavior, return-row types, and a concrete example. An output schema exists, yet the RETURNS section still usefully summarizes row kinds. Nothing an agent needs 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so 3 is the baseline, but the description adds cross-parameter semantics the schema cannot express: at least one of companies/boards/useSeedList is required even though all are marked optional (else INPUT_EMPTY, unbilled), onlyNew depends on stateStoreName matching the prior run, and limit/offset page rows locally while every call incurs a new billed run. These are meaningful additions, though several per-parameter details (remote, postedWithinDays, excludeStale) are left to the schema.

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?

States a precise verb+resource: running the fairquery/company-jobs-feed Actor over many companies or boards, including discovery, filters, and history. It explicitly contrasts scope with siblings jobs_get_board (single board) and jobs_check_open (single job), so an agent can distinguish it 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN and WHEN NOT sections name the exact conditions and the free alternatives: use it for monitoring a company list, history/closed/repost signals, or many boards; avoid it for one board (jobs_get_board, free) or one job (jobs_check_open, free). No inference is required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.