ApplyWise MCP server

Read from the package source without running it. The installed server may list more.

• answer_profile_question

  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.

• apply_batch

  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).

• consent_status

  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`.

• control_check

  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}.

• control_status

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

• draft_answers

  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).

• facts_report

  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).

• get_form

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

• get_job

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

• give_feedback

  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"

• grants_status

  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.

• health

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

• improvement_report

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

• ingest_confirmations

  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_applications

  List recorded applications from the local store.

• plan_applicationwrite action

  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

• profile_questions

  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.

• provenance

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

• provide_verification_code

  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

• reconcile_submissions

  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 t

• record_text

  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.

• request_feature

  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).

• resolve_submission

  Inspect (no outcome) or resolve a submission stuck in submitting/unknown. outcome: submitted|failed| handoff. Requires `evidence` = the evidence folder path reported for the ref. Audit-logged.

• run_applicationswrite action

  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","discov

• run_reportwrite action

  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_jobs

  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).

• search_status

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

• seed_from_confirmations

  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_applicationwrite action

  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>`).

• sync_confirmations

  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.

• tune_runwrite action

  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.

• tune_status

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

• vault_status

  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`.

• verify_text

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

• Code scan145 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 1 days ago15/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

92/100

higher than 90% of 3,470 Web search servers

Tools

34

the typical Web search server has 5

Tools that change things

15%

typical: 0%. Fewer write tools means less an agent can break

Downloads a week

93

more than 55% of 827 Web search servers with a package

ApplyWise: common questions

Is ApplyWise MCP server safe?

Yes, by our scan: it is graded A (92/100). Read the ApplyWise safety report

How do I install ApplyWise?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does ApplyWise need an API key?

Not as far as the registry entry and our scan can tell: no credentials are declared or required.

Is ApplyWise maintained?

The last commit was 11 days ago (2026-10-23). The latest release is v0.1.0.

What can I use instead of ApplyWise?

Servers from other publishers that do the same job: Jobseek MCP server and Workopia — Job Search MCP server.

How does ApplyWise compare with other Web search MCP servers?

safety score 92/100 (higher than 90% of 3,470 Web search servers); tools 34 (the typical Web search server has 5); tools that change things 15% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.