# Jobably — the full site for language models

> Jobably is a job-search platform built for the user's OWN agent ("bring your own agent"). It scans job boards on a schedule, scores every posting against the user's own rubric with a written rationale, builds a daily short list, tailors resumes under a guard that never invents a figure, and tracks applications. The user's assistant — ChatGPT, Claude, Codex, GitHub Copilot, Cursor or any MCP client — connects to it and works the search with them. The user applies; the agent records it.

Short version: https://jobably.com/llms.txt · Docs for language models: https://docs.jobably.com/llms-full.txt

Key facts:
- MCP endpoint: https://mcp.jobably.com/mcp (Streamable HTTP; protocol 2025-11-25, 2025-06-18 or 2025-03-26).
- Chat agents (ChatGPT, claude.ai, Claude Desktop) connect with OAuth 2.1: add the endpoint as a connector and the owner approves it in Jobably. CLI agents (Claude Code, Codex, GitHub Copilot, Cursor) use a personal access token.
- 64 MCP tools. Start a daily check-in with get_shortlist; on a new account, start with get_started (resume → proposed profile and first search → apply_setup). Link the owner to reviewUrl for any draft, never to a raw file.
- Plans: Free ($0), Pro ($30/month), Executive ($100/month); 7-day free trial on paid plans; agent access on every account.
- Company: Jobably, 131 Continental Dr Ste 305, Newark, DE 19713, US · support@jobably.com

## Bring your own agent

### 01. Connect

Add Jobably to ChatGPT or Claude as a connector and sign in, or paste one command into Codex, Copilot or Cursor. You approve it in Jobably — read-only if you like. New here? Hand it your resume: it proposes your profile and first search, you say yes, and your first scored matches arrive within minutes.

### 02. Every morning, a short list

Jobably scans and scores overnight. Your agent opens the day with the best new matches that clear your bar, each with the reason it scored what it did.

### 03. Tailor, and see it

Ask for a tailored resume and your agent shows you the draft right in the conversation. Every figure comes from your own history — the guard does not bend for anyone.

### 04. You apply

You send the ones that matter; your agent marks them applied, tracks follow-ups, and builds you reports and lists that stay live in your account.

### What the agent can do

- **Set up from your resume.** Hand your agent your resume. Jobably proposes your profile and a first search from it, your agent asks what a resume cannot say, and one yes starts the first scan.
- **A short list every morning.** The best new matches that cleared your bar overnight, best first, each with its score and the written reason. The same list your agent reads is in the app.
- **Search the live market.** One-off searches, saved searches that scan on a schedule, and a free count to size any query before a credit is spent.
- **Tailor — and show you.** Your agent tailors a resume and shows you the draft in the conversation, then links you to review and download it. No figure is ever invented.
- **Keep the record straight.** Tell your agent what you applied to and it moves the job, tracks follow-ups, and lists everything you have sent.
- **Reports, dashboards, lists.** Ask for a weekly pipeline review and it saves one to your account. Reports stay live — every number is read fresh each time you open it.
- **Set you up from the chat.** A new account can be set up in the conversation: your resume, what you are looking for, and how you want to hear about matches.

### The trust model

- **You approve every agent.** Connecting sends you to Jobably to sign in and approve it. A token or another agent can never approve one.
- **Read-only is one checkbox away.** Untick "act on it for you" and the agent can look but never change anything.
- **Everything is on the record.** Every change — and everything a token or agent reads — is recorded before it happens, with the agent’s name on it. A change that cannot be recorded is not made.
- **Spending is deliberate.** Anything that uses plan credits or changes your account needs explicit confirmation, and every tool declares its cost up front.
- **You apply, always.** Your agent finds, ranks, tailors and records. It never submits an application for you.
- **Disconnect any time.** Settings → Connected agents. Its access ends on its next request.

## How Jobably works

### Scan

On your search’s cadence — hourly on Executive, every six hours on Pro — Jobably sweeps ATS boards most aggregators miss — Greenhouse, Lever, Workday and more — and pulls only what is new since the last pass. Reposts get caught and deduped — under a new ID, or under a parent or subsidiary’s name.

### Score

Your targeting questionnaire becomes a scoring rubric: seniority floor, scope, location rules, compensation, dealbreakers. Every posting is judged against it with a written rationale, not a keyword count.

### Tailor

One click produces a resume tailored to the posting — with a provenance guard. Every figure in the output exists verbatim in your master resume or accomplishment bank, or the draft does not ship.

### Track

A kanban board from Matched to Closed, with status history, interview prep packets, and follow-up nudges when an application has sat quiet for five days.

## Pricing

### Pro — $30/month (7-day free trial)

- Automatic scans every 6 hours across ATS-direct sources
- Personal scoring rubric built from your questionnaire
- Stated pay, key skills, role summaries, and company facts on every posting
- Written rationale on every score — never a bare number
- Email alerts the moment a new match scores at your bar
- Provenance-guarded resume tailoring (docx output)
- Interview prep packets with draft-only outreach
- Kanban pipeline with status history and follow-up nudges
- Chrome extension: tailor from any job page you visit
- Bring your own agent: ChatGPT, Claude, Codex, Copilot or any MCP client
- A daily short list, and live reports your agent builds
- Bring-your-own-key for Anthropic, OpenAI, Google, xAI, or Ollama Cloud models
- Email and SSO sign-in (Google, Microsoft)

### Executive — $100/month (7-day free trial)

- Everything in Pro
- Hourly scans — see a role the hour it is indexed, not the day after
- New matches scored automatically as they arrive
- ~5× the monthly credits: scoring, tailoring, prep, and Finder pulls
- 25 active searches for wide, quiet market surveillance
- Built for Director-to-C-suite searches where timing decides

### Pricing questions

**Is there a free plan?**
Yes. A free account needs no card: save postings with the Chrome extension, build your scoring rubric, score up to 4 matches a day, and track everything on the pipeline board. Your first search scans and scores automatically so you see the product work before paying. Scheduled scanning, automatic scoring, tailoring, and prep packets are what the paid plans add.

**What happens after the 7-day trial?**
Your card is charged for the plan you chose — $30/mo on Pro, $100/mo on Executive. Cancel any time during the trial and you pay nothing; the trial is fully featured either way.

**What does Executive actually add?**
The same engine, run harder: scans every hour instead of every 6, new matches scored automatically as they land, roughly five times the monthly credits, and 25 concurrent searches. If your search is senior and timing-sensitive, Executive is built for it.

**Are there usage limits?**
Each plan includes monthly credit pools for scoring, tailoring, prep packets, and market pulls — visible on your dashboard at all times. If you bring your own model keys, that AI usage runs on your keys instead of our pools.

**Can I switch plans or cancel from the app?**
Yes — Billing → Manage subscription opens the Stripe customer portal for plan changes and cancellation. Cancellation takes effect at the end of the paid period; your data stays exportable.

**Do you offer teams or annual plans?**
Jobably for Teams — seats for outplacement firms, executive coaches, and career centers, with a coach workspace over the cohort — is in the works. We are looking for agency partners to shape it with: see jobably.com/teams or write partners@jobably.com.

## Frequently asked questions

### Billing

**How does the free trial work?**
Seven days, fully featured. Checkout collects a card up front through Stripe; cancel before day seven and nothing is charged.

**How do I cancel?**
Billing → Manage subscription in the app opens the Stripe customer portal. Cancellation applies at the end of the current period.

**What happens if a payment fails?**
You get a 3-day grace period with full access. If payment still fails after that, the account drops to read-only — nothing is deleted, and paying again restores everything.

### Bring your own keys (BYOK)

**Which providers can I bring?**
Anthropic, OpenAI, and Google. Add a key in Settings; scoring, tailoring, and prep then run against your key.

**How are my keys stored?**
Envelope-encrypted at rest: each key gets its own AES-256-GCM data key, wrapped by a master key. Keys are write-only — the UI and API can show the last four characters, never the key itself.

**Can I remove a key?**
Yes, instantly, from Settings. Work in flight falls back to platform models within your plan quotas.

### Data handling

**What do you store?**
Your resume versions and accomplishment bank, targeting questionnaire, matched postings with scores and rationales, pipeline history, and generated artifacts. All of it scoped to your account.

**Do you train models on my data?**
No. Your data is used to serve you — scoring, tailoring, prep — and for nothing else.

**Can I delete my account?**
Yes. Account deletion erases your data with a verified cascade — postings, artifacts, history, and stored keys included.

### Bring your own agent

**Which agents work with Jobably?**
Any agent that speaks MCP. ChatGPT, claude.ai and Claude Desktop connect by signing in: add https://mcp.jobably.com/mcp as a connector and approve it in Jobably. Claude Code, Codex, GitHub Copilot and Cursor connect with one command from Settings → Integrations. Step-by-step guides are in the docs.

**Does my agent apply to jobs for me?**
No, by design. It finds and ranks jobs, tailors resumes, shows you the drafts, and records what you applied to. You read the draft and send it yourself.

**Does connecting an agent cost extra?**
No. Agent access is part of every account. Work your agent asks for — tailoring a resume, a prep packet — uses your plan’s credits exactly as it would from the app, and runs on Jobably’s models or your own model keys, not on your agent’s subscription.

**What can a connected agent see and do, and how do I stop it?**
You choose when you approve it: read only, or read and act. Everything it does is listed under its name in Settings → Activity, and you can disconnect it there at any time — its access ends on its next request. It can never sign in as you, create tokens, approve other agents, touch billing, or delete your account.

### Chrome extension

**What permissions does it need and why?**
Access to the page you invoke it on — to read the job posting you are viewing and send it to your Jobably account. It reads nothing in the background and has no access to other tabs.

**How does it authenticate?**
With a personal access token you create in Settings, scoped to posting ingestion. It cannot read your pipeline, billing, or keys — and you can revoke it any time.

### Cancellation & data export

**What happens to my data when I cancel?**
Read-only access continues so you can reference your pipeline and artifacts. Deleting the account removes everything permanently.

**Can I export my tailored resumes?**
Yes — every tailored resume is downloadable as .docx from the app at any time, including while read-only.

## MCP tools (64)

Every description declares its cost class; tools that spend credits or change state require `confirm: true`. Full argument reference with a correct example per tool: https://docs.jobably.com/mcp/tools/

- `search_jobs` — [metered: one source query per pool] Run a ONE-OFF job search. Results are raw postings and are NEVER scored against the owner's profile. The owner's exclusion lists and stated country are applied to the results unless forSomeoneElse is true. Set forSomeoneElse: true when searching on behalf of somebody else — it turns the owner's standing filters off. Nothing is saved. Prefer create_search when the user wants this run repeatedly. The response reports `truncated` and (when it can) `totalAvailable` — never present a truncated list as the whole market. A one-off is capped at 100 per pool and has no memory, so on a high-volume query it is a SAMPLE; create_search is what keeps up with one over time. count_jobs sizes a query for free.
- `count_jobs` — [free — costs NO job credits] How many postings match, without fetching any of them. Use this to size or debug a query before spending on it: it returns the same compiled expression, the same filter warnings and a total, but buys no rows. Iterate here first, then run search_jobs or create_search once the query looks right.
- `list_matches` — [free] Scored postings from the owner's pipeline with score + written rationale. Filters: status, minScore, source. By default, matched postings scoring below their search's score threshold are omitted and COUNTED in hiddenBelowThreshold — when that count is non-zero, the list is not the whole pipeline. Pass includeBelowThreshold: true to see them, each marked belowThreshold. view: "pursuing" returns instead the Pursuing screen: every job between Pursue and Applied with its `stage` (queued → drafted → reviewed → final → applied, derived from the studio session and the documents), its one primary `action`, and its `artifacts`.
- `get_job` — [free] Full posting detail: JD, score+rationale (with `flags.lean` — leader/doer/analyst shares of what the posting is buying, read from the responsibilities; it never moves the score), history, notes, artifacts.
- `set_job_status` — [free, state-changing — requires confirm: true] Move a posting through the pipeline (matched→pursuing→tailored→applied→screening→interviewing→offer→closed_*, dismissed↔matched). screening = a recruiter screen or phone call; it is optional (applied→interviewing is legal). Two axes, one column: closed_lost = rejected, closed_withdrawn = withdrawn, closed_won = accepted, and the stage reached before closing is read from the history (get_board returns it as `reached`). Illegal transitions are rejected by the server; closed stays closed.
- `rate_job` — [free] Rate a posting with a reason code AND a free-text note — the note tunes future scoring. Reasons: wrong_location, wrong_level, wrong_industry, comp_too_low, reputation, not_interested, good_fit, other.
- `tailor_resume` — [metered: tailor quota — requires confirm: true] Queue a ONE-SHOT provenance-guarded tailored resume for a posting: the whole document is rewritten in the background and the artifact lands in the app. Returns an operation id; poll get_operation. When the user wants to see and decide each change, use the STUDIO instead: open_tailoring_session → review_tailoring_session → get_tailoring_session (read the proposals) → decide_tailoring → build_tailored_resume. The studio and this tool produce the same artifacts under the same guards; the studio applies nothing the user did not accept.
- `revise_tailored` — [metered: tailor quota — requires confirm: true] Apply the author’s review decisions to the latest tailored draft (approve-and-decline). A finished tailor’s get_operation result carries `triage`: posting phrases the draft does not use, each verdict-sorted (supported / judgement / unsupported) with evidence from the record, a suggestion, and — when there is a real limit — a `caution` naming what must NOT be claimed (show it beside the item; it binds the revision too). Pass one decision per item id — approve or decline, optionally with the author’s own wording. Only supported/judgement items can be approved; unsupported items are the honest gap list and cannot be worked in. Returns an operation id; poll get_operation. The result lists `declined` (changes refused as untruthful — a correct outcome), `unauthorizedChanges` (model edits outside the approved scope, reverted), and `changedLines` (what actually changed). Every unchanged line ships byte-identical.
- `list_tailoring_sessions` — [free] Every tailoring-studio session on the account, newest first: job, status (new | reviewing | reviewed | built), master version, decided/proposal counts, and the built artifact id when there is one.
- `open_tailoring_session` — [free] Open (or return) the tailoring-studio session for a job. Starts from the master version marked exemplar, else the latest; pass resumeId (from list_resumes) to start from another version — that REPLACES an existing session on a different version, discarding its proposals and decisions. Returns the session: sections as numbered lines (index, text, role), proposals (empty until reviewed), decisions, the job, and the master. Refuses (409) a job with no stored description or an account with no master. Next: review_tailoring_session.
- `get_tailoring_session` — [free] The full studio session for a job: `session.sections[]` each with `lines[]` ({index, text, role}) and `suggestions[]` ({id, kind: reword|add, lineIndex, original, proposed, reason, postingTerms, source, guard: {ok, reason}, styleNotes}) — a suggestion with guard.ok false was HELD BACK by the no-fabrication guards and cannot be accepted; show it with its reason. Also `session.analysis` (posting signal, verified terminology aliases, `headline.proposed`, `layout[]` recommendations — only a section-order one can be applied for the user), `session.decisions`, `session.lineOverrides`, `session.build` after a build, `progress`, `activeOperation` while a review or build runs, and `latestOperation`. Read this after review_tailoring_session finishes, then walk the proposals WITH the user before calling decide_tailoring.
- `review_tailoring_session` — [metered: tailor quota — requires confirm: true] Queue the studio review: one posting analysis (key terms, requirements, verified terminology aliases; on the user’s own model also layout recommendations and a headline), then every section reviewed line by line and role by role, each proposal checked against the record before it is shown. Returns an operation id; poll get_operation until done, then get_tailoring_session. Optional `sections` (indexes) re-reviews only those; `force` re-runs the posting analysis too. Refuses (409) while a review or build is already running.
- `decide_tailoring` — [free] Save the user’s decisions on a reviewed session. `decisions`: one per proposal id — accept, decline, or edit with the user’s own `text`. `lineOverrides`: the user’s own wording (`text`) for ANY line, or `omit: true` to leave a line out of this draft (the master is never changed). `headline`: original | proposed | custom (+ text). `sectionOrder`: every section title exactly once, or null to restore the master’s order. `layoutDecisions`: accept/decline a recommendation id (accepting a section-order one applies it). Every piece of user wording is checked against the record as it lands — dates, figures, every number on the line, traceability — and anything refused comes back in `rejected` with the reason and is NOT saved; tell the user why. A proposal the user does not decide is not applied. Refuses (409) while a review is running. Returns the updated session and progress.
- `build_tailored_resume` — [metered: tailor quota — requires confirm: true] Build the document from the session’s decisions: composed by code (undecided proposals are NOT applied), every changed line re-verified, rendered into the user’s own Word file when the master is a .docx, stored as the same artifacts a one-shot tailor produces (tailored resume + optional cover letter), scored, and the job moved to Tailored. Refuses (422) with `problems` naming any line that cannot be traced to the record — fix those with decide_tailoring first. Returns an operation id; poll get_operation (kind tailor_build); the artifact ids are in its result and get_tailored_document reads them back as text.
- `discard_tailoring_session` — [free, state-changing — requires confirm: true] Start over: delete a job’s studio session (its proposals and decisions). Documents already built stay on the job.
- `get_prep_packet` — [metered: prep quota — requires confirm: true] Queue an interview prep packet (research brief, themes, STAR stories, draft-only outreach).
- `get_board` — [free] Kanban board snapshot: cards per live status; applied cards carry days-since-applied aging (followUp.due at 5+ days with nothing back). Closed applications are NOT in the columns — `closed` lists them with `outcome` (rejected | withdrawn | accepted) and `reached` (the stage before closing: applied | screening | interviewing | offer), and `outcomes` is the tally (stillOpen, rejected, withdrawn, accepted, daysToHearBack, answeredShare, appliedEver).
- `move_card` — [free, state-changing — requires confirm: true] Move a board card to another column. Identical to set_job_status; provided so board-centric agents find it.
- `list_searches` — [free] Saved searches with stored query translation and warnings.
- `create_search` — [metered: recurring scans every cadence — requires confirm: true] Create a saved search that scans automatically from now on, scores every result against the owner's rubric, and applies their exclusion lists. This — not search_jobs — is the tool that carries the full filter set. Set location and a level filter unless the user genuinely wants worldwide, all-levels results — an unfiltered saved search spends money on every run for roles the candidate cannot take. COVERAGE: each run fetches up to 100 postings per source (career sites and job boards separately), and only those added since the previous run — so a saved search keeps up with a busy query over time rather than sampling it, which a single one-off search cannot do. Use count_jobs to size a query first: if it matches far more per run than the cap, narrow it or shorten the cadence.
- `pause_search` — [free, state-changing — requires confirm: true] Pause or resume a saved search. Pausing preserves the scan watermark; searches are never deleted.
- `get_operation` — [free] The outcome of something you queued — tailor_resume, get_prep_packet or a score. Those tools return an operation id and nothing else, so without this an agent can START work it can never observe: no way to tell finished from failed, and no way to read the result. Poll this until status is `done` or `error`. A finished TAILOR returns `unevidenced` — what the posting asks for that the record does not evidence. Show that list to the user: the draft never claims those things, and they are the fastest guide to what is worth adding to the accomplishment bank. A finished tailor also names its `renderer`: `into-master` means the .docx was rendered into the user’s own Word file (their fonts, margins, numbering); `mirrored` means the generic layout, with `rendererFallbackReason` saying why — tell the user when `masterIsDocx` is true, because their formatting was not applied. A finished tailor also carries `triage` (feed revise_tailored), `verbatimSections` with `verbatimReasons` (which sections kept the user’s own words and WHY — a deliberate skip, the time budget, or the failure; tell the user the reason, not just the name), the tally `tailoredSections` / `skippedSections` / `failedSections` with `degraded: true` whenever any section failed (a partly-tailored draft must never be presented as fully tailored; a run where nothing could be tailored is an `error`, retryable, not a `done`), `styleNotes` (advisory style observations, never blocking), `orientation` (what the posting is buying — leader / doer / analyst — vs what the draft reads as; order and emphasis only, a mismatch is a flag not a defect), and `strategy` (`single-pass` = one whole-resume call on the user’s own model; `chunked` = per-section, with `strategyFallbackReason` when a single pass fell back). A finished REVISE carries `declined`, `unauthorizedChanges`, and `changedLines` — show `declined` to the user: those are changes refused as untruthful, which is the guard working. A finished STUDIO REVIEW (kind tailor_review) carries the tally `reviewed` / `suggestions` / `heldBack` / `layout` and `layoutSkipped` when layout advice did not run; the proposals themselves are read with get_tailoring_session. A finished STUDIO BUILD (kind tailor_build) carries `artifactId`, `coverLetterArtifactId`, `changedLines` (the receipt of what the author accepted), `unevidenced`, `triage`, `scorecard`, `renderer`, and `studio: true`.
- `list_accomplishments` — [free] The accomplishment bank: the record tailoring draws on ALONGSIDE the master resume. A tailored resume may only use figures that appear here or in the master, verbatim — so this is also the list of figures that can legally appear in a draft.
- `add_accomplishments` — [free] Add accomplishments to the bank. APPENDS — existing entries are never replaced, and duplicates are skipped, so this is safe to call repeatedly. Widening the bank is the single most effective way to improve tailored resumes: tailoring can only rearrange what it has been given, and a master resume is one compressed snapshot of a career. Keep figures EXACTLY as the user states them ($4.8M stays $4.8M) — a reworded number is unusable, because the provenance guard matches verbatim. One accomplishment per entry. The response reports what was added, skipped and dropped. For a whole LinkedIn history, the app takes the export zip directly under Profile.
- `update_search` — [free, state-changing — requires confirm: true] Edit a saved search: its query, cadence, threshold, or any filter. Send ONLY what you want to change — every filter you do not mention is preserved. (The underlying API replaces the filter object wholesale, so this tool reads the stored search and merges; a client that rebuilt that object from its own inputs would silently DELETE every filter it did not know about.) Use pause_search to stop or resume one; this is for changing what it seeks.
- `run_search_now` — [metered: one source query per pool — requires confirm: true] Run a saved search immediately instead of waiting for its cadence. Optionally reach further back than the watermark with backfillHours (max 168 = 7 days) to pick up postings from before the search existed. A paused search is refused — resume it first.
- `get_search_health` — [free] Why is a search returning nothing? Per search and per source: the last run, how many postings came back, how many were new, whether the run failed and why, and the COMPILED query the supplier actually received. This is the tool for diagnosing a quiet search — an empty result and an impossible query look identical from outside, and the compiled expression is what tells them apart.
- `rescore_job` — [metered: score quota — requires confirm: true] Re-score ONE posting against the current rubric. Use after the questionnaire or exclusion lists change, or when a score looks wrong. Returns an operation id — poll get_operation.
- `add_job_note` — [free] Attach a note to a posting — a recruiter conversation, a referral, why it was interesting. Notes are first-class: they are what the owner reads later, when the score has stopped being the interesting part.
- `declare_applied` — [free, state-changing — requires confirm: true] Record an application made OUTSIDE Jobably — through a recruiter, a referral, or a company site. Creates the board card if the posting is not already tracked. Idempotent: declaring the same role twice does not duplicate it.
- `get_exclusions` — [free] The two standing exclusion lists: `fit` (poor-fit employers, which the rubric could in principle learn) and `reputation` (vetoes that apply regardless of role). These shape every search and every score, so read them before concluding a search is behaving oddly.
- `set_exclusions` — [free, state-changing — requires confirm: true] REPLACES both exclusion lists. Call get_exclusions first and send the complete lists including everything being kept — a partial call silently drops the rest. The two are different: `fit` is about match quality, `reputation` is a veto that applies whatever the role.
- `list_resumes` — [free] Master resume versions and every tailored artifact produced so far, with the job each belongs to. Use it to tell the owner what already exists before spending tailor quota producing it again.
- `list_operations` — [free] Everything queued or recently finished — tailoring, prep packets, scoring — with status and any failure reason. Check here before starting metered work: what the user asked for may already be running.
- `get_tailored_document` — [free] READ a tailored resume, cover letter or prep packet as text. list_resumes gives you the artifact ids. This is what makes a draft reviewable: without it you can hand the owner a download link but cannot see what was produced, so you can neither critique it nor help them check it. ALWAYS read the draft before telling anyone it is ready — and read the gap list from get_operation alongside it. The guards stop the draft inventing figures; they cannot stop it being badly aimed, or carrying a credential from another industry onto this application.
- `get_master_resume` — [free] The parsed master resume: name, headline, contact and every section, as stored. This is the record tailoring mirrors — sections come out in this order, under these titles — so read it to understand why a draft is shaped the way it is, and to see what the record does NOT contain before promising it can.
- `mark_exemplar` — [free, state-changing — requires confirm: true] Mark a resume version as an EXEMPLAR, or unmark it. Exemplars are loaded into the tailoring prompt as a style reference, so this is the direct lever on how future drafts read. Mark the versions the owner considers their best work, not the most recent — and only ones they have actually reviewed.
- `delete_tailored_document` — [free, state-changing — requires confirm: true] Delete a tailored artifact. The posting, its score and its history are untouched — only the generated document goes. Use it to clear a draft the owner rejected so the next one is unambiguous.
- `get_usage` — [free] What has this cost me? Cycle usage vs plan quotas + estimated spend.
- `get_shortlist` — [free] TODAY'S SHORT LIST — the jobs worth the owner's time today, best first. Start every daily check-in here. Built each morning from new scored matches that clear the owner's bar (the same bar Matches uses), held stable for the day, and returned LIVE: each item carries its current status, score and written rationale, its stage if being pursued, any tailored documents, `appUrl` (the job in Jobably) and `reviewUrl` (where a draft is reviewed and downloaded). `carried: true` marks a match from an earlier list the owner has not acted on. `criteria.awaitingScore` counts recent matches not scored yet — they cannot make the list until they are, so an empty list with a non-zero awaitingScore means "scoring in progress", not "nothing fits". Pass `day` (YYYY-MM-DD) to read a past list.
- `regenerate_shortlist` — [free, state-changing — requires confirm: true] Rebuild TODAY'S short list from the current matches — after the owner changed their floor or exclusions, or new matches were scored since this morning. Replaces the list everyone sees today.
- `list_applications` — [free] Everything the owner has applied to, newest first: status, date applied, whether a follow-up is due, the documents (including the final they sent), `appUrl` and `reviewUrl`. Record a new application with move_card (toStatus "applied") for a tracked job, or declare_applied for one found elsewhere.
- `show_tailored_resume` — [free] Show what the tailored resume for a job LOOKS like: the newest draft as text, its version, every other document for the job (cover letter, prep packet, the final the owner sent), and `reviewUrl` — where the owner reviews, finalizes and downloads it. Present the text to the owner; link reviewUrl for the formatted document. If no draft exists yet, says so (tailor_resume or the studio tools make one).
- `query_jobs` — [free] The flexible read for building the owner a table, report or list: any mix of statuses, a score range, found within N days, applied within N days, one search, one list, a company or a title/company text match, sorted by score, newest found or newest applied. Light columns (title, company, location, status, score, rationale, dates, appUrl) — use get_job for a full posting.
- `get_insights` — [free] The numbers for a report or dashboard: jobs by status, the score histogram, found and applied per week (12 weeks), the funnel from seen to closed, hit rate by search, median days from found to applied, open applications by age, and which agents acted on the account in the last 30 days.
- `get_activity` — [free] The activity record: who — the owner in the app, a personal access token, or a connected agent like you — did what, newest first, with the tool, the target and the outcome. Every change to the account is recorded before it is made. Filter by `via` (session | pat | oauth) or `client` (an agent or token name). Page with `before` set to the previous page’s nextBefore.
- `list_lists` — [free] The owner’s named job lists ("Dream companies", "Apply this week") with item counts. Lists are where an agent keeps a working set for the owner; they appear in the app and can be embedded in a report.
- `create_list` — [free, state-changing] Create a named list of jobs for the owner. Add jobs with add_to_list. Name it the way the owner would.
- `get_list` — [free] One list with its jobs: title, company, status, score, note, appUrl.
- `update_list` — [free, state-changing] Rename a list or change its description.
- `delete_list` — [free, state-changing — requires confirm: true] Delete a list. The jobs on it are untouched — only the list goes.
- `add_to_list` — [free, state-changing] Add jobs to a list, optionally with a note (why they are there). Adding a job already on the list just updates its note.
- `remove_from_list` — [free, state-changing] Take one job off a list. The job itself is untouched.
- `list_reports` — [free] Reports and dashboards saved to the owner’s account — by the owner or by an agent — with their widget types and `appUrl` (where the owner opens it in Jobably).
- `get_report` — [free] One saved report. With render (the default) every widget comes back with its LIVE data — the same numbers the owner sees when they open it.
- `save_report` — [free, state-changing] Save a report or dashboard to the owner’s account, where it stays LIVE: widgets are queries, not snapshots, so it is still true next week. Pass `reportId` to replace an existing one. Widget types: markdown {body} (your written analysis — headings, lists, tables, links); stats {} (insights); funnel {}; jobs {query: the query_jobs fields, limit ≤ 50}; list {listId}; shortlist {}; activity {via?, limit?}. Each takes an optional title. Up to 20 widgets. Returns `appUrl` — give it to the owner.
- `delete_report` — [free, state-changing — requires confirm: true] Delete a saved report.
- `get_profile` — [free] The owner’s profile: the questionnaire their scoring rubric is built from (seniority floor, locations, arrangements, comp floor, industries, title keywords), notification preferences, and whether a master resume exists. Read it before set_questionnaire or set_preferences.
- `set_questionnaire` — [free, state-changing — requires confirm: true] Set what the owner wants — the questionnaire every posting is scored against. MERGES: send only the fields that change; everything else is kept. Scoring needs this AND a master resume. Ask the owner rather than guessing — a wrong floor hides good jobs.
- `set_preferences` — [free, state-changing — requires confirm: true] Notification and display preferences. MERGES over the stored ones. matchAlertFrequency: instant | daily | off (emails when a match clears alertThreshold); digestFrequency: daily | weekly | off; matchesMinScore: one floor for every search on Matches and the short list (useSearchThresholds: true goes back to each search’s own threshold).
- `upload_master_resume` — [free, state-changing — requires confirm: true] Upload the owner’s master resume — what every score and every tailored draft is built from. Send `text` (the resume as plain text or Markdown, exactly as written — never rewritten or summarized) or `fileBase64` + `filename` for a .docx or .pdf. A Word file keeps its formatting in tailored drafts; text does not, so prefer the file when the owner has one. Creates a new master version; earlier ones are kept.
- `get_started` — [free] START HERE on a new account, or whenever the owner says "set me up" / "find me jobs". Returns where the account stands (`status`: resume, profile, searches, first scan, matches, scored), the NEXT step in words (`next.step`, `next.say`), and — once a master resume is uploaded and until the account is set up — a `proposal` drawn from it: a profile (`questionnaire`) and a first search, every value copied from the resume with its source in `basis`, plus `ask`: the questions only the owner can answer (pay floor, remote/hybrid/on-site, industries). Show the proposal, ask those questions, fold the answers into it, then call apply_setup. Steps: upload_resume → upload_master_resume; apply_setup → apply_setup; first_scan / scoring → wait a few minutes and call this again; score_matches → score_new_matches; ready → get_shortlist.
- `apply_setup` — [metered: recurring scans every cadence — requires confirm: true] Set the owner up in ONE call, after they approved the proposal from get_started: saves the profile (`questionnaire`, which builds the scoring rubric) and creates each search, and the first scan runs immediately. Matches arrive within minutes; on a new account they are scored automatically (`scoring: "automatic"`), otherwise call score_new_matches. Send the proposal back with the owner’s answers folded in — `questionnaire` is the WHOLE profile (seniorityFloor required), `searches` is a list of {name, query, filters, scoreThreshold, cadenceHours} exactly as the proposal shapes them (filters takes the create_search filter names, e.g. location, experienceLevel, remoteOnly). Every search is checked before anything is saved: one that could never match refuses the whole call, naming it. Needs a master resume (upload_master_resume).
- `score_new_matches` — [metered: scores every unscored match against the rubric — requires confirm: true] Score the owner’s unscored matches now, newest first. Subscribers’ new matches are scored automatically and so are a new account’s first; use this when get_started says `score_matches`. One run per account: asking again while one runs returns that run. Poll it with get_operation; scores appear on list_matches as they land.

## Authentication guide (https://jobably.com/auth.md)

Jobably is built for the account owner's OWN agent. There are two ways an
agent authenticates, and both end at the same record of what it did.

1. **OAuth 2.1 (chat apps and any OAuth-capable MCP client).** The agent
   discovers the flow on its own, sends the owner to Jobably to approve it,
   and receives short-lived tokens. Nothing is pasted.
2. **Personal access token (clients that send a fixed header).** The owner
   mints a token in the app and gives it to the agent.

## OAuth 2.1

| What | Where |
| --- | --- |
| Protected resource metadata (RFC 9728) | https://mcp.jobably.com/.well-known/oauth-protected-resource and https://api.jobably.com/.well-known/oauth-protected-resource |
| Authorization server metadata (RFC 8414) | https://api.jobably.com/.well-known/oauth-authorization-server |
| Authorization endpoint | https://api.jobably.com/oauth/authorize |
| Token endpoint | https://api.jobably.com/oauth/token |
| Dynamic client registration (RFC 7591) | https://api.jobably.com/oauth/register |
| Token revocation (RFC 7009) | https://api.jobably.com/oauth/revoke |

- **PKCE is required** (`code_challenge_method=S256`). The authorization
  code grant and the refresh token grant are supported.
- **Clients** register dynamically, or use a **Client ID Metadata Document**:
  an `https` URL as the `client_id` that serves a JSON document naming
  itself (`client_id` equal to the URL) and its `redirect_uris`. Such
  clients are shown to the owner with their verified domain.
- **Redirect URIs** must match exactly. `https` anywhere; `http` only on
  loopback (any port, per RFC 8252); private-use schemes for native apps.
- **Consent** happens in a signed-in Jobably session. The owner sees the
  agent's name, where they will be returned, and what it may do, and may
  narrow `read write` to `read`. A token can never approve another agent.
- **Tokens**: access tokens (`jbly_oat_…`) last one hour; refresh tokens
  (`jbly_ort_…`) last 30 days and rotate on every use. Presenting a rotated
  refresh token again revokes the whole connection, as does replaying an
  authorization code.
- **Resource indicators** (RFC 8707): `resource` may be
  `https://mcp.jobably.com/mcp` or `https://api.jobably.com`.
- An unauthenticated or expired request to the MCP server returns HTTP 401
  with `WWW-Authenticate: Bearer resource_metadata="…"`, which is how a
  client starts the flow.
- The owner disconnects an agent at any time in Settings → Connected agents;
  its tokens stop working on the next request.

## Personal access tokens

1. Sign in at https://app.jobably.com (Google, Microsoft, or email code).
2. Go to **Settings → Integrations → Personal access tokens**.
3. Create a token with the scopes your agent needs. The full token is shown
   exactly once; store it securely.

Tokens look like `jbly_pat_…`, are stored server-side only as hashes, and can
be revoked from the same screen at any time.

## Using a token

Send it as a bearer token on every request:

    Authorization: Bearer <token>

- **MCP**: https://mcp.jobably.com/mcp (Streamable HTTP; protocol versions
  2025-11-25, 2025-06-18 and 2025-03-26).
- **REST**: https://api.jobably.com — every route the MCP tools call.

## Scopes

| Scope    | Grants                                                                 |
| -------- | ---------------------------------------------------------------------- |
| `read`   | Matches, the short list, searches, the board, resumes and drafts, reports, lists, insights, the activity record, usage. |
| `write`  | Move jobs, record applications, run searches, tailor (spends plan credits), prep, lists, reports, profile and preferences. |
| `ingest` | Save postings captured from web pages (browser extension; tokens only). |

Session-only surfaces — sign-in, token management, approving agents, model
keys, billing and account deletion — are **never** available to a token or a
connected agent.

## The activity record

Every change to the account, from anyone, and every request made with a
token or by a connected agent, is recorded before it runs — with the agent's
name, the tool it used, what it acted on and the outcome. If the record
cannot be written, the change is not made. The owner reads it in Settings →
Activity; an agent reads it with the `get_activity` tool.

## Trust model

- Jobably never applies to a job. The owner applies; an agent records it.
- Tools that spend money (tailoring, prep packets) or change state require
  `confirm: true` — agents cannot spend silently. Tool annotations mark
  which tools only read.
- Tailored resumes are built only from the owner's own history: figures are
  never invented, whatever the agent asks for.
- One-off searches run for an agent are never scored against the owner's
  private rubric and are not saved.

Questions: https://jobably.com/contact

## Blog

### Bring your own agent: your AI works the search, you apply

https://jobably.com/blog/bring-your-own-agent · 2026-10-30 · The Jobably team

You probably already have an AI assistant you trust. It knows how you write,
it is open in a tab all day, and it is good at exactly the work a job search is
full of: reading, comparing, drafting, keeping track.

What it does not have is a job search. Ask a chat assistant to "find me VP of
Engineering roles" and it improvises from whatever it can reach: no live feed of
new postings, no memory of what you consider a good fit, no record of what you
already applied to, and nothing stopping it from rounding your team of 38 up to
"40+" in a cover letter.

Jobably is now built to be the system your agent works. **Bring your own
agent** — ChatGPT, Claude, Codex, GitHub Copilot, Cursor, or any client that
speaks the [Model Context Protocol](https://modelcontextprotocol.io) — and it
gets the whole of Jobably to work with. You keep the part that should stay
yours: deciding, and applying.

## Connect it in a minute

How you connect depends on the agent:

- **Chat apps — ChatGPT, claude.ai, Claude Desktop.** Add
  `https://mcp.jobably.com/mcp` as a connector. Your agent sends you to
  Jobably, you sign in, and you see exactly who is asking and what it may do.
  Choose **Allow** — or allow it to read only. Nothing to copy or paste.
- **Coding and command-line agents — Claude Code, Codex, Copilot, Cursor.**
  Create a token in Settings → Integrations and paste the one command shown
  there; your token is already in it.

Step-by-step for each agent is in the
[docs](https://docs.jobably.com/mcp/connect/).

## A morning with your agent

Jobably keeps scanning the boards on your schedule and scoring every new
posting against the bar you set, with the reasoning written out. Each morning
it builds your **short list**: the best new matches that cleared that bar, best
first, held steady for the day. So the first thing to ask is simple:

> **"What's on my Jobably short list today?"**
>
> Three new roles cleared your bar overnight. The strongest is VP of
> Engineering at a Series C fintech — remote, comp above your floor, and the
> platform scope you ranked first. Two more are below; one is hybrid two days a
> week, which your rules rank lower. Want a tailored resume for the first?

> **"Yes — and show me the draft."**
>
> Here it is. Every figure comes from your own resume. Review it and download
> the formatted version in Jobably — and tell me once you've applied.

The draft comes back as text right in the conversation, so you can read it and
push back on it there. When you are happy, the link takes you to Jobably to
review and download the Word file — that review step is yours, and an agent
cannot skip it for you.

> **"I applied to the fintech role this morning."**
>
> Marked as applied. If it goes quiet, I'll remind you to follow up.

And at the end of the week:

> **"Build me a pipeline review: what's new, what I applied to, and where
> things stand."**

Your agent saves it to your account as a **report** — written notes alongside
today's short list, a table of your strongest matches, and your funnel from
postings seen to applications sent. Reports stay live: every number is read
fresh when you open one under Reports, so Monday's review is still true on
Friday. Ask for a **list** — "Apply this week", "Dream companies" — and it
keeps one of those too.

## What Jobably adds that a chat agent can't

- **A live market, not a memory.** Scheduled scans of job boards and company
  career sites, deduplicated and filtered by what you excluded, so your agent
  works from what was posted this week, not from what it remembers.
- **Your bar, applied the same way every time.** A scoring rubric built from
  your own answers, with a written rationale on every score — the same reasons
  you see in the app.
- **A tailoring guard that does not bend.** Tailored resumes are built only from
  your verified history: a figure that is not in your own record stops the
  draft. That holds whoever is asking — you in the app, or your agent at
  midnight.
- **One pipeline for both of you.** The short list, the board, your
  applications and your reports are the same in the app and in the
  conversation. Nobody keeps a second spreadsheet.

## Trust is the feature

Giving an agent access to your job search should feel like hiring a careful
assistant, not handing over your password. So the rules are built in:

- **You approve every agent,** in Jobably, signed in as you. An agent can never
  approve another agent, create tokens, touch billing or delete your account.
- **Read-only is one checkbox away.** Untick "act on it for you" and your agent
  can look at everything and change nothing.
- **Everything is on the record.** Every change to your account — and
  everything a connected agent reads — is recorded before it happens, under the
  agent's name, in Settings → Activity. A change that cannot be recorded is not
  made.
- **Spending is deliberate.** Anything that uses your plan's credits, like
  tailoring, needs an explicit confirmation, and every tool says up front what
  it costs.
- **You apply. Always.** Your agent finds, ranks, tailors and keeps track. It
  never submits an application for you.
- **Disconnect any time** in Settings → Connected agents; its access ends on its
  next request.

One honest note on cost: bringing your own *agent* is not bringing your own
*model*. Scoring and tailoring run on Jobably's models — or on your own model
keys, if you add them — and use your plan's credits exactly as they would from
the app. Your agent directs the work; it does not pay for it.

## For the builders

The details, for anyone wiring Jobably into their own tooling:

- **OAuth 2.1 with PKCE** for agents that sign in, with dynamic client
  registration and Client ID Metadata Documents; protected-resource metadata on
  the MCP server tells a client where to authenticate. Personal access tokens
  remain for clients that send a fixed header.
- **More than sixty tools**, each declaring its cost class, with annotations
  that tell a client which ones only read — and a correct example call for
  every tool in the [reference](https://docs.jobably.com/mcp/tools/).
- **Discoverable without a human:** [llms.txt](https://jobably.com/llms.txt)
  and [llms-full.txt](https://jobably.com/llms-full.txt), an MCP server card,
  an [auth guide](https://jobably.com/auth.md), and the MCP server and agent
  sign-in on the [status page](https://jobably.com/status).

## Getting started

Connect the agent you already use, ask for your short list, and let it do the
reading, comparing and drafting. The deciding — and the applying — stay with
you.

[Connect your agent →](https://jobably.com/agents)

### Your AI assistant can run your job search now

https://jobably.com/blog/your-ai-assistant-runs-your-job-search · 2026-08-06 · The Jobably team

Somewhere in the last year, the question changed. It used to be *"which job board
should I check?"* Now, for a growing number of serious candidates, it's *"what
did my assistant find overnight?"*

Jobably was built for the second question. It is, as far as we know, the first
career platform designed **agent-native**: every capability the web app has —
searching, scoring, tailoring, pipeline tracking — is also a tool your AI
assistant can drive directly, through a full [MCP](https://docs.jobably.com/mcp/connect/)
surface. Not a chatbot bolted onto a product. The product itself, operable by
an agent.

## What that looks like in practice

You connect Jobably to your assistant once — Claude, or anything else that
speaks MCP — with a personal access token you mint in Settings. From then on,
conversations like these work against your **live** pipeline:

> **"What came in overnight worth my time?"** Your assistant reads the new
> matches with their scores and the written rationale behind each number, and
> answers with judgment: two worth a look, one borderline, here's why.

> **"Tailor my resume for the Shapeways role."** The tailoring engine runs —
> the same one behind the web app, with the same provenance guard — and the
> docx lands in your pipeline.

> **"Where did I get to with Acme?"** Status history, notes, and the follow-up
> clock, read straight from the board.

The difference between this and pasting a job description into a chat window
is the difference between a colleague with access to your files and a stranger
with a good memory. Your assistant isn't improvising from what you told it —
it's reading your rubric, your verified history, and your actual pipeline.

## Reading is free. Acting is deliberate.

Handing an agent the keys to something that spends money and sends documents
raises an obvious question, so we made the answer structural:

- **Every tool declares its cost class in its own description** — an agent
  knows *before calling* whether a tool reads, spends, or destroys.
- **Anything that spends or changes state requires explicit confirmation.**
  Reading your matches is free; triggering a tailoring run is a deliberate,
  confirmed act.
- **Scopes are enforced server-side.** A read-only token cannot mutate your
  pipeline no matter what the agent asks for.

The same trust posture runs through the output itself. Scores come with
written rationales, never bare numbers. Tailored resumes pass a provenance
guard — a figure that doesn't exist verbatim in your own history kills the
draft in code, not in a promise. Outreach is draft-only by design: the system
prepares, you send.

## Discoverable by any agent, not just configured ones

Agent-native also means the platform announces itself the way agents discover
services: an OpenAPI description of the whole surface, a
[/.well-known catalog](https://jobably.com/.well-known/api-catalog), an MCP
server card, and [llms.txt](https://jobably.com/llms.txt). If your tooling can
read a spec, it can find and operate Jobably without a human writing glue code
first.

## Why this matters for a serious search

A senior search is a monitoring problem punctuated by short bursts of intense
work. The monitoring — scanning sources on a schedule, scoring what arrives,
noticing that a company you interviewed with went quiet — is exactly what
software should do. The bursts — deciding, preparing, showing up sharp — are
yours.

An agent-native platform puts your assistant on the monitoring side with you:
standing questions ("tell me when anything scores 9"), morning briefings, prep
on demand. Jobably supplies the system underneath — the scans, the rubric,
the guarded tailoring, the board — so the conversation has something real to
stand on.

[Connect your assistant →](https://jobably.com/agents)

### Why tailored resumes win: the data behind one-click tailoring

https://jobably.com/blog/why-tailored-resumes-win · 2026-08-01 · The Jobably team

Recruiters and hiring managers spend a famously short time on a first-pass resume read —
industry eye-tracking studies put the initial screen in the single-digit seconds. In that
window, one thing decides whether you survive the cut: **visible overlap between your resume
and the posting in front of them**.

## The overlap problem

A master resume is a compromise. It has to represent everything you have done, so it
represents nothing sharply. The posting for a platform-engineering role cares about your
Kubernetes migration; the posting for a data-heavy role cares about the warehouse you
rebuilt. Your master resume mentions both, briefly, buried in a bullet list optimized for
generality.

Tailoring is just editing for the reader you actually have. Reorder so the relevant work
leads. Rephrase using the vocabulary the posting itself uses — the same words the screener
was told to look for. Cut what this reader will never care about. None of this is
controversial; every career coach says it. Almost nobody does it, because doing it well
takes 30–45 minutes per application, and a serious search means dozens of applications.

## What automation usually gets wrong

The obvious move is to have an AI rewrite your resume per posting. The obvious failure is
that language models embellish. A model that "improves" your bullet from *"reduced infra
spend"* to *"reduced infra spend 40% ($2.1M annually)"* has written you into an interview
you cannot survive. One invented figure, one pointed follow-up question, and the interview
is over — along with your credibility at that company for years.

This is not a tail risk. Unconstrained rewriting drifts numbers constantly: rounding up,
merging adjacent claims, "typical" figures hallucinated from training data. If you would
not sign it under oath, it cannot go out under your name.

## The provenance rule

Jobably's tailoring engine applies one hard constraint: **every figure in the output —
every dollar amount, percentage, headcount, and large number — must exist verbatim in your
master resume or accomplishment bank.** Not paraphrased, not recalculated. Verbatim.

The tailored draft is checked mechanically after generation. If a figure appears that
cannot be traced to your own history, the draft is rejected and regenerated — you never see
it. If the model believes a claim is true but cannot evidence it from your documents, the
claim is surfaced as a *gap* ("the posting wants X; your history does not evidence it")
instead of being papered over. Gaps are useful; fabrications are fatal.

## What one click actually buys

With the safety rule in place, tailoring becomes cheap enough to do every time:

- **Lead reordering** — the experience this posting cares about moves to the top.
- **Vocabulary alignment** — your real work, described in the posting's own terms.
- **Honest emphasis** — the same facts, weighted for this reader.
- **A gap report** — what the posting wants that your history does not evidence, so you
  can address it in the cover note or the interview instead of being ambushed by it.

The result reads like you spent the 45 minutes. You spent one click — and everything in it
survives a follow-up question, because everything in it is yours.

## Pages

- https://jobably.com/ — home
- https://jobably.com/agents — bring your own agent: connect, capabilities, trust model, every tool
- https://jobably.com/pricing — plans and pricing questions
- https://jobably.com/faq — frequently asked questions
- https://jobably.com/swipe — Jobably Swipe, the phone app
- https://jobably.com/download — the Chrome extension
- https://jobably.com/teams — Jobably for Teams (in the works)
- https://jobably.com/about · /press · /brand · /contact · /support · /status
- https://jobably.com/legal/terms · /legal/privacy · /legal/cookies
- https://docs.jobably.com/ — product documentation