Documentation
findmynew.work runs as a server plus a local fmwork CLI. The server scores vacancies and drafts letters; the CLI opens your real browser to scrape and apply. Both pieces talk over a small WebSocket + REST protocol.
Shape of the system
The server is hosted at findmynew.work. It owns the database, runs the scorer, and drafts cover letters. The local CLI @findmynew/client holds the browser sessions — LinkedIn cookies, hh.ru cookies, etc. — and drives the scrape + apply loop. Selectors and pacing live on the server, so when a job board redesigns its DOM we update one file and your local CLI picks it up on the next run — no client upgrade needed.
Start here
The three commands you need to know:
# 1. Install + configure npm install -g @findmynew/client fmwork config set apiKey fmwork_xxxxx # 2. Log into a source (one-time per source) fmwork login linkedin # 3. Two ways to run: fmwork start # DAEMON — listens for dashboard commands over WebSocket fmwork run # BATCH — drains queued applies, exits fmwork search linkedin -q "senior typescript remote" --limit 5
Principles
- Job-board cookies never leave your machine.
- You review every application before it goes out.
- The server stores only what it needs to score and draft.
- Everything is exportable as JSON.
Alternative integrations
The legacy MCP integration (Claude Desktop / Cursor / Claude Code) is still wired up; the docs are kept for users who prefer that path. The CLI is the supported default.
Connect Claude Desktop, Cursor, or any MCP-compatible client instead of the CLI. Same backend; different transport.
Every MCP tool: input schema, output shape, side-effects. Useful when wiring a custom client.
How server / worker / CLI / web fit together. Where state lives, who can read what, what's per-user.