Check that the ApplyOps server is reachable.

Search LinkedIn for postings, newest first.

Use this when the user wants jobs found rather than handed a link. Defaults to Easy Apply only, because that is the route this server can actually finish; "Apply on company site" hands off to an ATS whose form we have never seen.

Returns the postings plus the exact search_url used, so a surprising result can be traced back to the query that produced it.

This applies to nothing. It only lists. Take a job_id or url from the result and run the normal preflight -> apply flow on it.

Open a URL in the automation browser.

The browser launches on first use with a persistent profile, so a LinkedIn session established once is reused on later runs.

Only one process may drive that profile at a time -- two Chromes on one profile delete each other's cookies, and the logged-in session cannot be rebuilt from here. If another driver (the scheduled loop, a batch run) has it, this returns browser_busy: true with the holder's name instead of opening a second browser. Do not retry in a loop; the holder is usually mid-application.

List the current page's form fields, buttons and tabs.

Every field carries a ref string. Pass that same ref back to fill_field / select_option / click_target; do not construct your own CSS selector, because the references are already chosen to survive the site's generated markup.

Fields with required: true must be filled before submitting. field_type tells you which action to use:

• text/email/tel/number/textarea/contenteditable -> fill_field

• select/combobox/listbox -> select_option

• radio/checkbox -> set_checkbox

• file -> upload_file

Save a screenshot of the visible viewport and return its path.

Use this when the field list looks wrong or empty: the DOM can be read literally, but only a picture shows whether the page is where you think it is.

List open tabs. A click may open a second tab (employer ATS sites).

Make another tab the active one, by index from browser_tabs.

Scroll the viewport. direction is 'down' or 'up'.

Type a value into a text-like field.

ref comes from browser_state. role names what the field is for (for example "phone", "first_name") and reason explains why this value is correct; both are recorded so the same field is faster to fill next time. There is no version of this tool without them, on purpose.

The value is typed character by character and then read back. If the read-back disagrees with what was typed, the tool reports a mismatch instead of pretending to have succeeded.

Choose an option in a dropdown.

Handles both a real <select> and a custom control that opens a popup, so the same call works on LinkedIn and on Workday-style forms.

Check or uncheck a checkbox or radio button.

Attach a local file to a file input (typically a resume).

Click a button or link, by visible/accessible name or by ref.

If the click opens a new tab, this follows it automatically and reports new_tab: true -- "Apply on company site" leads to the employer's own ATS in a new tab, and continuing to drive the old tab would lose the application entirely.

Look up a previously learned answer to an application question.

Call this for every question on a form before deciding to ask the user. When it answers, use the value as-is -- it is a stored fact, and paraphrasing it risks putting a wrong answer on a real application.

status meanings:

• "answered" -- confident match; use answer directly

• "suggestion" -- plausible but not yet proven; confirm with the user

• "need_human" -- nothing usable stored; ask the user, then call record_answer so the next run does not have to

Store a user-supplied answer so future applications reuse it.

Call this immediately after the user answers something, including the exact wording of the question as the form asked it.

Known-good element references for a platform, best first.

These are learned from real runs. Feed them back through browser_state refs where possible; the raw values are also useful when a form renders differently than expected.

What kind of application this job is, and what it will take.

Call this before browser_open. There is more than one way to apply, and the differences are structural: a LinkedIn Easy Apply lives entirely in a modal on the posting, while an "external" posting hands the browser to the employer's own account system, where a sign-in -- often an emailed one-time code -- stands before the first field.

Any step carrying human_required: true cannot be completed by the machine. Ask the user for those up front, in the same message as the profile questions, rather than walking into the gate and stopping there.

runs / success_rate / hardest_gate are what this route has actually done here before. A route with runs: 0 is a shape we know about but have never driven -- read its steps as a map, not as evidence.

Whether the user's profile is complete, and the questions to ask.

Call this before the first application and any time get_profile reports missing fields. If ready is false, ask the user the questions in questionnaire -- all of them in a single message, not one at a time -- then hand the answers back through save_profile.

Every field carries its current value, so a second run only needs to ask about what is still blank. Fields already answered are never re-asked; that is the whole point of the profile being a file.

Prefer save_profile over update_profile for this: it writes the whole set at once and reports validation problems together.

Store setup answers in the user's profile file.

answers maps field keys to values. Booleans accept yes/no, numbers are read leniently ("150k", "$150,000" and "150000" all mean 150000), paths are expanded to absolute. Empty values clear a field.

Check warnings in the reply: anything listed there was rejected and is not stored, so it must be re-asked rather than assumed. unknown_keys lists keys that are stored but not part of the spec, which usually means a typo in a key name.

The candidate's stored facts (name, email, phone, resume path, ...).

Treat these as authoritative for form fields, and use them verbatim -- do not reformat a phone number or round a salary. If a field an application needs is not here, call setup_status to get the question and ask the user; never infer an answer.

The values come from a markdown file the user may have edited by hand, so they are exactly what the user intends, not a normalized copy.

Change one or a few known profile fields mid-run.

For example after asking a single follow-up question. For initial setup prefer save_profile, which reports all validation problems at once.

Whether the memory is actually compounding.

Watch automation_rate (share of questions answered without asking) and selectors_suggested. A selectors_suggested of 0 after real runs means nothing is being recorded, and the memory is not learning.

Past applications, newest first.

Whether this posting was already applied to.

Matched on the job id, so the same posting reached through a different tracking link is still recognised.

Record that the DOM locator failed and vision had to resolve a field.

This is an adapter gap report, not bookkeeping: each entry names a field the platform adapter cannot address, which is exactly the rule that is missing. See flywheel_stats().adapter_gaps for the ranking.

Ask permission before starting an application. Call this first.

Checks the daily cap, the minimum spacing between applications, whether this posting was already applied to, and whether a previous run tripped the failure breaker.

If allowed is false, do not proceed -- the reason says why. If wait_seconds is greater than zero this call has already waited, so the pacing is enforced rather than merely suggested.

Current safety state: remaining quota today, failures, halted or not.

Request approval before submitting, and get a one-time token.

summary must list the fields and the exact values that will be sent, and call out anything the tool filled by itself. If the user has not seen a value, they are approving something they cannot see.

Show the returned summary_to_show to the user and get an explicit yes. Then call submit_application with confirmation_id and acknowledged: true. The token is single-use and expires, so a stale approval cannot be replayed onto a different job.

Record a submitted application. Call this only after clicking Submit.

Requires a confirmation_id from request_submit_confirmation. Without a valid, unused token this refuses -- the check is what makes "confirm before submitting" real rather than advisory.

When the client could not prompt the user directly, pass acknowledged: true only after you have shown the user the summary and they explicitly approved.

Report that the current application attempt failed.

Consecutive failures trip the breaker and stop the run. That is deliberate: a run that keeps failing is usually failing for one systemic reason, and continuing multiplies the damage instead of the results.

If the attempt died at a recognisable step, pass platform, route and blocked_at (a short description of that step). The failure is then filed against the route instead of merely counted, which is what turns "this kind of application is hard" into an adapter worth writing.

Clear a tripped failure breaker so a run may resume.

Close the automation browser and release the profile.