ats_sweep_boards
Sweep multiple ATS job boards in one call to fetch postings, detect per-board failures, and track changes since a previous sweep.
Instructions
Sweep many job boards in one call — the watchlist sweep, batched.
boards is a list of up to 50 objects, each {"company": "Arize AI", "platform": "greenhouse", "slug": "arizeai"}. company is both
echoed back on that board's result and compared against the board's own
reported name, so a slug that has drifted to a different company shows up
as NAME_MISMATCH rather than as plausible-looking jobs. The other
arguments work exactly as in ats_fetch_board and apply to every
board; limit_per_board caps postings returned per board (default 25).
include_descriptions defaults off here because it multiplies the
size of every Greenhouse request in the sweep — turn it on when you are
passing keywords and the hits need to see description text. There is
deliberately no full_descriptions here: a sweep is for breadth, and
untruncated postings across many boards would not fit in a context
window. Go deep on one board with ats_fetch_board.
One board failing never fails the sweep. Every board comes back with
its own status and detail; the ones that failed carry an empty
jobs list and an explanation, and results stay in the order you
passed them so they line up with your roster. The summary counts
boards read versus failed and total matching postings — check it against
the number of boards you sent before drawing conclusions from the
results, and never fill in a board that reported a failure.
Boards are fetched a few at a time with polite pacing, so a large sweep takes tens of seconds rather than being instant.
Seen-state. Every sweep returns a state snapshot — boards keyed
platform:slug, each with its postings keyed by stable job id (with
first_seen dates) and a running history of board totals. Save it
(e.g. as a JSON file next to your other career records) and pass it back
as previous_state on the next sweep to get changes: new_jobs
and gone_jobs since that run, board_status_changes,
total_deltas (a per-company hiring-velocity signal), and
new_boards for roster additions (whose postings are deliberately not
counted as new jobs). A board that fails to read carries its previous
jobs forward rather than reporting them all gone, and boards in
previous_state that this sweep didn't include ride along verbatim —
so a roster split into batches (e.g. to fit a time limit) can write
each batch's returned state straight back without erasing the others;
retire a board by deleting its key from the saved state file, not just
by dropping it from the roster. State is relative to
the filters used — keep filters stable between runs, or expect
filter_changed: true warning that the diff reflects the filter, not
the market. Use response_format="json" when round-tripping state;
the markdown rendering shows the changes but not the snapshot.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| boards | Yes | ||
| keywords | No | ||
| title_filter | No | ||
| updated_since | No | ||
| previous_state | No | ||
| limit_per_board | No | ||
| response_format | No | markdown | |
| include_compensation | No | ||
| include_descriptions | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |