ApplyWise

Ask the USER (MCP elicitation) to type the answer for a gap key from profile_questions. This tool takes no value: the answer comes only from the user's own input and is stored as user_written. If the client cannot elicit, nothing is stored; tell the user to run `job-apply-mcp profile ask`. Scope: global | company | role_family (+ scope_value, or 'company:Acme'). Demographics are never stored here.

Plan + submit many applications concurrently. Returns one compact status row per ref. Open profile questions are asked once, before the batch starts (never mid-batch).

Active consent windows (mode, scopes, seconds left, submissions left). Read-only: only a human can consent, in a terminal: `job-apply-mcp consent --for 24h` or `--per-run`.

Check a side-effecting action against the control layer. action: apply|submit|send_message| write_prose|merge. payload: ref, platform, company, dry_run, text, recipient, page_text, form_labels, attestations. Returns {decision: pass|block|needs_human, violations, warnings}.

Active mode, quotas used/remaining, enabled controls and recent blocks.

Draft the prose fields a plan left open (writing.mode="deferred", or ones that timed out): local writer + reviewer under writing.timeout_s. Returns the same shape as plan_application with a fresh approval_id, paged the same way (`cursor=next` pages the last draft from memory).

Resume-first fact precedence: counts, profile/resume conflicts, and user-letter facts excluded because they conflict with or are outdated relative to the resume (with the reason and the resume's version).

Return the application form schema (keys, labels, kinds, required, options).

Fetch one posting. Add 'description' to fields to include the (trimmed) description.

Feedback on a run (optionally on one `ref` of it), applied at the start of the next run. Structured: {"kind":"deny_company"|"deny_title", "pattern"?} (no pattern + ref = that item's company/title), {"kind":"answer","pattern","value"} for plain questions only; any authorization, demographic, consent, attestation, legal or AI-use question (or {"kind":"profile_answer","key"|"question","value","scope": "global|company|role_family","scope_value"}) goes to the profile builder's answer_profile_question. {"kind":"salary","salary_floor"|"base_salary"|"default_ask"|"expected"|"delta"|"percent"}: never below the configured floor, capped at intake.salary_max_multiple. {"kind":"run_size","value"|"delta"}. Free text is shown in the next run's plan_context. Answers given here (and pay changes in human approval mode) apply only after the USER confirms them on a terminal: `job-apply-mcp feedback --confirm <id>`.

Active human-issued grants (scope, seconds left, uses left). Read-only: only a human can create or revoke a grant, via `job-apply-mcp grant` in a terminal.

Report enabled platforms, LLM providers and which local models are reachable.

Ranked improvement proposals learned from recent run failures (compact). Page with `cursor` (= `next`).

Record the user's own application-confirmation emails so those jobs are never re-applied to. Pass message summaries from the user's mail tool: [{sender, subject, date, snippet}] (snippet = first ~500 chars, optional). Read-only on mail; the server stores only company, title and date. Returns counts plus up to a few new matches. preview=true parses without writing.

List recorded applications from the local store.

Run policy gates + duplicate check, fill answers from the profile and local LLMs, and list unresolved fields. Unresolved free-text fields come back as `client_tasks` for the calling agent to write. `src` names the source of every answer that is not "profile". A result too large for one response is paged: it carries `next` and `total`; call again with `cursor=next` to get the next page of the SAME plan (from memory, no re-plan) until `next` is null. Pages keep the shape (answers/src stay dicts) so they merge. The first call of a session may ask the user the top open profile questions (elicitation) before planning.

Top open profile gaps (questions the tool could not answer, or answered with a default), ranked by frequency x impact (blocked applications weigh most). Ask the user these, then call answer_profile_question.

Origin, model, prompt hash and ancestor chain for a text id.

The user types the code they received (email/SMS) for a submission in status `awaiting_code`. Ask the USER; never try to read their mail or guess. Only the format is checked; the code is typed into the open page, the page's verify button is clicked once, then the normal confirmation check runs. One attempt per code; the application is never resubmitted; after `verification.code_ttl_s` it becomes a `handoff`.

Match open submissions (submitted/unknown/submitting/handoff) to confirmation emails and mark confident matches `confirmed` (evidence = email subject/date; never bodies). Checks run at ingest.reconcile_delays_min after each submit; force=true checks now. With the default client mail source and no `messages`, returns a `client_task`: fetch recent confirmation-email summaries and pass them here or to ingest_confirmations. An unknown with no match after the last window stays unknown and is listed under `unresolved`. Read-only on mail; never resubmits.

Record provenance for a text artifact (kind: resume_bullet|cover_letter|answer|profile_fact). origin: user_written | llm_generated (llm_generated needs `model`). `context` = job/question the text answers.

Propose (and, if a coder backend is configured, implement as a PR for human review) a change to this tool. kind: platform_adapter | control | config | new_tool | bug (auto-detected if omitted).

Apply from any mix of sources in one run: explicit `links` (or `links_file`, one URL per line), job links the user emailed to themselves (read-only mail; sender, recipient and label come from config only; `mail` may only narrow with {query, since, since_days}), and discovery (`discovery` = search_jobs arguments). Priority: links, then mail, then discovery. `sources` subsets ["links","mail","discovery"]. `max_applications` (whole number >= 1; default intake.max_applications or run_size feedback, capped at intake.max_applications_cap) caps the eligible postings handled, the same in dry and live mode; skipped and ineligible ones do not count. Every URL goes through adapter detection, plan, gates, dedupe and submit. Prose is deferred: jobs needing unapproved prose are skipped, not blocking. With the client mail source pass `messages` [{id, from, to, subject, date, body}]. Pending feedback is applied first (see plan_context). Returns the run report: one status per posting, each with `why`: submitted, confirmed, dry_run_ok (a live run would submit it), needs_human (the owner must act: unresolved fields, review gate, awaiting approval), quota_blocked (a live quota refused it), skipped (policy, duplicate, prose not approved, max_applications reached), unsupported_site, unknown (verify by hand), failed. A dry run adds `live_preview` (would_submit, quota_blocked, warning) from the live quotas.

Report of a run (default: the latest): counts plus rows per status (submitted, confirmed, dry_run_ok, needs_human, quota_blocked, skipped, unsupported_site, unknown, failed; see run_applications), each with `why`. `category` shows one only (the old names handed_off and dry_run still work).

Search postings across enabled platforms in parallel. Returns compact rows: ref, co, title, loc, pay, flags. The first call runs the whole search once; pass the returned `next` as `cursor` for more pages (instant).

Progress of a search_jobs session: status, boards done/total, rows, elapsed. Accepts a session id or cursor.

Seed dedupe from confirmation-email history (default ingest.seed_since_days=180) before a run, so no side files are needed. mbox/imap sources are read directly; with the client source and no `messages` this returns a `client_task` to fetch summaries and call it again with them.

Submit using the best available path (platform API, else browser driver). Honors global dry_run; a per-call dry_run can only make it safer. `approval_id` is the server-issued id from plan_application. With approval_mode=human a person must approve (dialog, or `job-apply-mcp approve <id>`).

Pull confirmation emails from the configured read-only source (ingest.source: mbox or imap) for the last `since_days` days and record them as already applied. Never sends, moves, flags or deletes mail.

Train a LoRA on the user's own texts, gate it against the incumbent, promote only if better. trigger: manual | new_data (skips below the configured threshold) | rollback (restore previous adapter). wait=False starts in the background; poll tune_status.

Local style-tuning state: backend, promoted/previous adapter, new user texts vs threshold, last run.

Which ATS hosts have a stored login (host and count only, never a username's password), whether the credentials consent window is open, accounts awaiting email verification, and this run's login flags (lockout, wrong_password, captcha). Read-only: logins are added by a human with `job-apply-mcp vault add`.

User approves LLM text. Without edited_text -> user_verified; with it -> user_edited child plus diff.