New CV Tool

Patches the ACTIVE tab in place: replaces the CV of one saved application in the tab open in the web app. applicationId defaults to the application get_session_focus reports. Takes the whole cv object (cv-edit-result/v1) and baseRevision, the updatedAt from get_application; if the application changed since then, the write is rejected and nothing is saved. It does not create a new version tab. The open web-app tab shows the change without a reload. The candidate name and contact details come from the profile: changes to them are not saved, and the response lists the fields that were kept.

apply_cv_edit

Patches the ACTIVE tab in place: replaces the cover letter of one saved application in the tab open in the web app. applicationId defaults to the application get_session_focus reports. Takes either `letter` (a letter-edit-result/v1 object) or `letterText` (plain prose; formatting is kept from the current letter), plus baseRevision, the updatedAt from get_application; a stale revision is rejected and nothing is saved. It does not create a new version tab. A found row has no letter. Every write is checked for structure: body lines repeating the printed closing or signature are removed (structureNormalized); a sign-off, greeting or subject inside the body, repeated paragraphs or placeholders are refused with LETTER_STRUCTURE_INVALID naming each check. The open web-app tab shows the change without a reload.

apply_letter_edit

Export active CV, letter and selected library documents as PDFs: privately in Cloud by default, or selected Drive. Drive is optional. Cloud returns PDF resources, documentIds for download_document and owner-authenticated downloadUrls. Stores bundleReady and readiness.bundle; other readiness checks stay explicit. merge=true combines; false keeps selected order as separate files. Missing requested documents fail the export. No email or submission.

export_application_bundle

Find typography settings that make a CV fit — fewer pages, no large empty blocks where a section jumped to the next page. Tries a ladder of settings from gentlest to most compact, measures each for real, and stops at the first that works, so the document is never squeezed harder than the page requires. Returns the options WITHOUT changing anything; show them to the user, then call again with apply: true and the first response's updatedAt as baseRevision. Applying also matches the cover letter's type size to the CV, because the two are a designed pair. A stale applying call is rejected without saving. If nothing in the readable range fits, it says so — that means the content is too long and the honest fix is cutting it, not shrinking the type.

fit_documents

Watch an employer, so it gets re-checked for new jobs instead of being rediscovered. status: following (default) | paused | off — off stops the watch and keeps the company record and its history. cadence: daily | weekly (default). Following is a private preference on the user's own account, not something the employer sees; it applies to nothing, sends nothing, and submits nothing. Following adds the employer to the user's own shortlist, so it records their choice. Pass companyId, or domain when the employer already has a record.

follow_company

Create a secure, owner-bound Google authorization URL for the user to connect Drive with the narrow drive.file scope. Drive is the FILE store: uploaded documents, generated PDFs and application bundles. Connecting it does not move the career record and never deletes it — profile, applications, statuses, history and facts stay in CV Tool Cloud, which is what keeps them queryable by the web app and by connected agents. The connection completes once the user opens the URL and approves Google. Account, billing, encrypted token metadata, and connector grants remain in CV Tool; career facts still pass through the service when requested. Drive being disconnected is a state the user can resolve with this URL, not a failure.

connect_google_drive

Get one saved application or found-job row by id, including listing/opportunity fields, apply feasibility, destination/applyWalls, tailored CV (cvTabs) when the row is drafted+, any cover letters (letterTabs), board fields (status, source, note, updatedAt, portal, followUp), structured portal executionState / preSubmissionProgress, sendReview.submittedAt (the real send clock), lastEmailSignal.receivedAt (the employer-email clock), and openUrl. writerAction on a Preparing row needing writer work; applicationAnswers with salaryFor (stated salary converted at the day's ECB rate; salaryCurrency/salaryPeriod pick a pair); blockerAnswer; applyRules (the owner's rule for the blocker, situations at risk). The clocks are independent, never fallbacks. letterArchitecture.brief is the letter's structure, never facts. For an in-place content or format edit, pass this response's updatedAt unchanged as baseRevision; a stale write is rejected without saving. Status is the board column, not a send action. Found rows have no CV — call set_opportunity_status with drafted before apply_cv_edit or save_application. This does not submit.

get_application

Get one found job by id: full job text, evaluation (fitScore, matchReasons, concerns, hardFilterResults), URLs, notes, status, policy revision used, and relatedApplicationId when a CV already exists on the same row. Requires id (or its applicationId alias) from list_opportunities; an empty argument object is rejected. This never submits an application.

get_opportunity

Read the application the owner is looking at RIGHT NOW in the web tab. No arguments — this owner only. Returns applicationId, company, role, surface (cv|letter), activeTabLabel, selected blockId. Every tools/call and initialize also carry this on result _meta['cvtool/sessionFocus'], so repeated calls return what the caller already has. Until focused:true no application is open in the tab, so which one to edit is the owner's to name.

get_session_focus

What this account needs from you now, the same for every connected assistant: one nextAction chosen by fixed rules (claim a role, finish writer-queue rows, run a due review, put proposed learnings to the owner, or nothing), plus review state (reviewDue, unreviewed applications, whether the review policy is the owner's saved one or the default), learnings waiting on the owner, active experiments, writer-queue responsibility, declared roles, and which login this is. Meant to be read on connecting and after each unit of work. Nothing here runs by itself: a due review is done by the assistant that reads this.

get_work_state

Explain New CV Tool to the user: what it is, what these tools can and cannot do, what the user needs, and what to do first. Read-only and safe to call at any time. It answers what this connector is for, what it requires, and how to begin, and lists the playbooks: the working rules for one workflow at a time (set up the profile, find jobs, tailor for one job, write queued applications, apply, check replies, review and learn, grow the profile, calibrate documents). With playbook set, it returns that one playbook's rules instead of the overview.

get_started

Highlight on the owner's OPEN application tab so they can confirm you are looking. Omit applicationId and surface to use get_session_focus. Omit paragraphIndex to light the Edit CV or Edit letter button. Pass paragraphIndex or blockId p:N for a letter paragraph. The highlight appears immediately and stays until clear:true or apply_letter_edit / apply_cv_edit lands. Does not edit text. A found row has no letter, so it has no paragraph to select.

select_document_block

List the user's applications as text, most recent first. Filter instead of dumping the board. scope defaults to active (drafted, ready, fail_to_submit, sent, reply); use scope:"all" only when the user asks for discarded, closed, found, or look-closer rows. Narrow by company, role, location, status, atsFamily, blockerType, applicationProgress, source, fit score, free text, or explicit submit, confirmation, created, and updated date filters. submittedSince/submittedBefore use the real submission time; confirmationReceivedSince/confirmationReceivedBefore use the employer receipt time. createdAt and updatedAt are not application dates. Use query_applications for counts or status checks, list_writer_queue for unfinished production, and get_application for one row. State how many rows were hidden. Status is a board column, not a send action. employerGroups keeps separate roles at one employer separate. After a real portal submit call record_application_send; after an owner-triggered portal check call record_application_check.

list_applications

List applications needing writer-owned production through Ready: a tailored CV, required cover letter, selected pack, resolved destination, final PDF bundle, and explicit readiness handoff. Rows remain queued while any required artifact or packaging step is unfinished; Found, Look closer, Out, Sent, and completed packs are excluded. Look closer is owner-only. Each response carries a revision; get_writer_queue_revision returns that token for lightweight polling. A row leaves the queue through get_application → CV/letter edits → pack selection → export_application_bundle → Ready; with the owner's standing approval that path needs no additional owner prompt. ownerBlocker=null means nothing on the owner's side holds the row: the remaining work is the writer's. Hand a row back only when ownerBlocker names a required owner action. responsibility explains the split, packaging is the file brief, and employerSiblings keeps separate roles at one employer separate. This tool never submits, emails, or applies to an employer.

list_writer_queue

List the signed-in user's Documents-tab library: diplomas, certificates, references, CVs, and Google Drive-linked files. Each item explains known provenance, added/source/modified/processed times, storage location and Drive identity, aliases grouped by underlying file, a short notes/text excerpt, date coverage, generation-context use, and whether profile contribution is known. Legacy metadata that was never recorded comes back as null / unknownFields rather than as a value. export_application_bundle chooses an application's supporting files from this list. Does not return file bytes or full extracted text.

list_documents

The employers the user is watching, each with a company summary (id, name, domain, careersUrl, atsKind, feedSupported, watch counts such as lastTotalOpenRoles), cadence, when it was last checked, and whether it is due now. get_company returns one employer's full record and get_company_watch_stats its opening history. Read this before offering to look for new jobs, so you check what they actually asked to watch instead of re-searching the whole market. Returns nothing for a user who follows no one — that is a normal state, not an error.

list_followed_companies

Look up opportunity rows on the SAME store so you can update them. No CV required. The account's default opportunity view is applied when you do not pass an explicit filter; call get_opportunity_views to inspect it. You can override with a saved viewId or filter by status, company, role, listingChannel (linkedin | company | aggregator | other), since/until date, and/or section. This never changes lifecycle or starts document production. Saving an opportunity does not apply to the employer.

list_opportunities

Every learning on record for this account with its lifecycle status, plus the experiments and openQuestions. proposed is waiting on the owner; approved writing learnings are what writing agents read; testing is running as a bounded trial; rejected and retired stay on record so a later review does not propose the same thing again. openQuestions are the targeted questions a review earned the right to ask — put them to the owner in plain words and write a confirmed answer with add_profile_facts; never answer one from inference. It is the record of what is already proposed, decided or under test, so a new proposal or a status report can be checked against it.

list_learnings

List the CV and cover-letter templates the user can choose from — layout (single/two-column), ATS-safety, font class, photo support, the format keys each one honours and its colour schemes — with which ones are currently selected and which letter template is designed to match which CV. honouredFormatKeys says which formatting set_document_format can change on each template. The template is a profile-wide choice: changing it changes every document. The web app's picker warns about that before a switch.

list_templates

Measure how a saved CV or cover letter actually lays out on paper: page count, how full each page is, and any large empty gaps with the line of text directly above them. Renders the real PDF, so the numbers match what the user would export. Pass `format` to try settings WITHOUT saving them — measure, compare, then call set_document_format once you know what works. It reports the real rendered length; an edit that changed the content changes the answer.

measure_document

Move a found-job row: found | look_closer | out | apply. apply / drafted / promote_to_drafted is the Apply (Preparing) column — no CV required, never auto-send. Same store as applications. out is skip, not employer rejected. This never emails or submits. Into Look closer needs the stored ad and ownerQuestion. Moving Look closer to Apply/Preparing or Out requires ownerConfirmed=true, the record that the owner made that decision; recommendations and annotations never move a row on their own. The same rule covers recruitment intermediaries: a row whose employer is (or looks like) an agency sits in the Agencies review lane, and moving it to Apply/Preparing needs ownerConfirmed=true plus agencyDecision=approved. Agencies are not filtered out — they are chosen one at a time, so agencyDecision=declined keeps the row without applying, and a named agency on the hunt policy approvedAgencies list skips the lane entirely. Refuses to demote an application that already has a CV: promotion is one-way, so a drafted row cannot be pushed back to found. For deterministic policy triage, call classify_opportunity first. Ids from list_opportunities.

set_opportunity_status

Read before writing: approved owner rules with applicability, bounded active experiments, careerUnderstanding, documentCalibration (editorial baseline, howToUse and revision for set_document_calibration), and letterVoice (five concrete voices, same-facts fictional examples, active selection and scope). Follow the owner's decisions; use get_profile for facts. Record used rules/experiments in strategy.appliedLearningIds / strategy.experimentIds. With applicationId, includes letterArchitecture (posting-specific structure avoiding recent repetition, bounded by calibration) and the active letter.voice override. Architecture and voice shape writing, never facts. Without applicationId, includes the architecture library. No approved rules yet is normal.

get_writing_guidance

Read stored career facts and editorial decisions. This read-only SOURCE OF TRUTH means every returned career field is stored account data; missing remains missing. It is not model memory, not earlier conversations, application history, or inference. cvSkeleton is the resolved CV writing surface; profile patches take a baseRevision. Career Direction, exclusions, display titles, letterRecipe, voice, work-sample usage and banned language are user decisions. get_work_samples exposes each sample's reference/style/structure/template/custom permission; missing legacy values default visibly to reference_only. Profile roles group an employer and role.positions supplies CV titles. applicationAnswers holds owner-stated form answers and what is missing. profile.identity is candidate identity, not login/account proof; who_am_i and get_account return the login account. Document contents are omitted.

get_profile

Read the design settings of a saved application's CV and cover letter — typography, margins, colours, colour scheme, fonts, photo shape, section order — with the allowed range or choices for every setting AND the list of keys the currently selected template actually renders (templates.*.honouredKeys). An empty value means the template default is in force. It lists the legal values, ranges and choices the selected template honours, and the updatedAt that set_document_format takes as baseRevision.

get_document_format

Read the account-owned opportunity board views shared by every assistant and browser session. Returns the current default, custom saved views, built-in fallback, and a revision token. Read this before presenting or changing an opportunity list; a missing or malformed setting is normalised to the valid built-in default.

get_opportunity_views

Call before job search, recommendations, board review, opportunity evaluation, or a job-search onboarding write. Uses the active career store: CV Tool Cloud by default, or Google Drive only when chosen. Returns the user's explicit durable hunt policy and append-only huntJudgements — not Career Direction, profile facts, or CV inference. Response: policy (or null), revision, summary, and readiness. policy:null means exactly that no hunt policy is stored in this account. Suggestions are profile-derived proposals, not stored policy and not user-approved. They are not stored policy and carry no user approval. If incomplete, ask only for required target roles, allowed country/location, and hard exclusions (including an explicit empty list). Language and seniority are optional. New CV Tool does not search the web; you do, then save_opportunity. The policy's revision history is left out unless includeHistory is true, and only the 20 most recent huntJudgements are returned unless includeAllJudgements is true; omitted says what was left out.

get_hunt_policy

Returns the user's writing samples and the explicit permission for each one. Missing sampleUsage is a visible conservative reference_only default, never a template. Samples are shared across the app and all assistants; the response includes a baseRevision for the guarded write tool.

get_work_samples

Record an owner-triggered follow-up on one application. For employer mail pass lastEmailSignal {text, receivedAt} with the email's own Date; this never changes sendReview.submittedAt. It stores what was seen in the employer's mail or on the candidate page; it reads neither itself, sends no email, never logs in, strips passwords/OTPs/cookies/tokens, and does not submit. The board changes only with outcome: interview_request (any call or interview request, a Calendly link) → Interview, employer_response → Employer replied, rejection → Rejected, confirmation → unchanged. Pass applicationId when the row exists; search list_applications and list_companies under every name the employer may have been saved as first. company with applicationId corrects the employer on that row: the old name stays searchable in companyAliases and history records the change. company without applicationId creates a drafted row only when it is truly not on the board. A row never submitted stays unsent.

record_application_check

Record the OWNER'S decision on one learning. This is the only call in the loop that changes anything, and ownerConfirmed=true means they said so in this conversation — not that you judged it sound, and not that a previous chat approved it. approve: it becomes guidance every writing agent reads, and if it carries a patch that patch is applied, with the profile snapshot taken first kept as the undo. reject: refused, with the reason on record. defer: stays proposed with their reason attached. test: starts a bounded experiment instead of a durable rule — pass experiment.targetApplications or experiment.endsAt. retire: it stops reaching writers. rollback: restores the profile to the snapshot this learning replaced. An experiment never becomes permanent by running its course; adopting it is a separate approve.

resolve_learning

What happened with a bounded trial. Say how much it rests on: a handful of applications is a signal, never proof that one writing choice caused an interview or a rejection. outcome=adopted records your reading; making it durable is still a separate resolve_learning approve that the owner has to agree to.

record_experiment_outcome

Record a portal send that already happened as status=sent. Include apply/status URLs, email and portalAccount (identity only), every significant non-secret prompt with its exact answer, answersComplete=true, the uploaded documents in order (role/name/merge and openable url when available), and CV/letter versions. If prompts are missing, set answersComplete=false and answersMissing; this is not send-hygiene complete. A form still sitting on its submit control has not been sent. submissionConfirmed=true requires answersComplete=true; false is rejected. Portal identity and prompts are reused for later applications, but passwords, OTPs, cookies and tokens are never stored. This only records an already-completed send; it never submits or emails. Pass applicationId for an existing row, or company and role to create one.

record_application_send

Records an explicit user cancellation or blocker and their volunteered reason. Requires ownerConfirmed:true for a statement made by the user; inactivity and inferred preferences are insufficient evidence. It records an outcome without changing career facts or submitting anything.

record_journey_outcome

OBSERVE step of the learning loop. Assembles a cohort of applications for one review pass instead of a row at a time. Read-only, data only, no picker, and it persists nothing. Returns each application reduced to reviewable facts (component readiness, letter requirement, opening and closing sentence, pack size and rationale, bundle state, recorded strategy, whether a job ad is even stored), the contradictions the stored rows prove on their own (a row counting as sent with no CV, ready with no exported bundle, a note saying submit was never pressed), cross-batch signals such as repeated openings and closings, and `material`: verbatim recorded framing, which canonical evidence the batch actually used, and which roles reached no CV at all. It grades no writing — read the letters and CVs yourself against each job ad. Then record the pass with save_portfolio_review. Concluding that the batch is already strong and that nothing should change is a valid outcome and is recorded, not skipped. `reviewDue` says whether a review is worth offering and which rows nobody has read yet; `cohort` names exactly what this call looked at; cohort.excluded lists test, junk and duplicate rows left out.

review_application_batch

Records one review pass and everything it concluded. The summary is the report the owner reads and decides on; the learnings are the operational output, and the call is refused with neither — a narrative that persists nothing disappears with the conversation. applicationIds names the exact rows read, which is how the next review knows what is new rather than silently re-reading or skipping. noChangeNeeded:true is a real, expected result when the batch holds up. Otherwise each learning carries a targetType, a destination (writing reaches the next writing agent; profile belongs to the career record), a title, the observation the batch showed, and evidence — a learning with nothing behind it is an opinion the owner is asked to approve. evidenceStatus=likely_undercaptured means the owner probably has this and nobody captured it: it carries an ownerQuestion and no patch, because only a confirmed answer reaches the profile. Any patch stays UNAPPLIED until resolve_learning. targetType `other` with targetDetail exists so a finding need not be forced into the nearest box. Nothing here writes to the profile.

save_portfolio_review

Record where to go back to for an employer: careers page, apply URL, and the applicant-tracking system it runs on. Shared public record — one row per employer across all users, so the next application to the same employer already knows the portal. save_opportunity does this automatically from the job URL; call save_company yourself only when you researched the careers page and know more than the job link showed. Identity is the employer's own domain (roche.com), or the public ATS tenant when the employer only publishes through one (Workday). A job-board host (LinkedIn, Indeed, jobs.ch) is never a company domain. This record is public and shared across accounts: it stores no credentials, and passwords, cookies, session tokens and portal logins are rejected. Enriches an existing row without overwriting what is already known.

save_company

Saves the owner's document calibration (profile.steering.documentCalibration): the editorial baseline writers follow — which roles normally appear, CV length, evidence density and seniority framing, letter tone, directness and length, market conventions, phrases never to use, and the applications reviewed. roles merge by roleKey (from get_writing_guidance documentCalibration.roles or get_profile steering.roleImportance[].key) or roleId; null visibility drops a decision. never records the owner's decision to leave the role off every CV (excludedRoles and excludedRoleDecisions); it and showing an excluded role again need ownerConfirmed=true. cv and letter merge per field (null clears); conventions, dislikes and sampleApplicationIds replace their list. approve=true, or skip=true (the owner chose not to calibrate), needs ownerConfirmed=true. A content change bumps version and reopens an approved calibration unless the same call approves. baseRevision (documentCalibration.revision; dc1:none before the first save) is required and a stale one is rejected. Each change is appended to its history with who made it. Never changes roles, titles or facts.

set_document_calibration

WRITE a found job onto the application board the owner reads at app.newcvtool.com, WITHOUT a CV. Harvesting always records Found; triage belongs to classify_opportunity or set_opportunity_status. It never submits anything. Dedupes by ATS job id and canonical apply URL across LinkedIn, company ATS and aggregator listings, then company + role + location. Prefer the company apply URL when known. listingChannel (linkedin | company | aggregator | other) is inferred from the URL host or set explicitly; it is not writer source. A check_company_jobs posting carries listingChannel=company, companyId and externalId; with both ids and no jobText (or one under 600 characters), the ad is read from that employer's own feed and stored verbatim as jobText, and feedAd says whether it was. A supplied status is retained only for compatibility and does not bypass the Found harvest boundary (a named hard policy exclusion may still be filed Out). jobText is the only place the posting itself is readable in the web app. It records whether the ad asks for a letter and flags, never drops, a work-authorization requirement the owner lacks. out is skip, not rejected.

save_opportunity

Merge standing job-search criteria into the user's one hunt policy. This is a permanent write: memory from earlier conversations, profile-derived suggestions, CV inference and application history are indistinguishable from stated criteria once saved. get_hunt_policy returns what is stored and what is missing, and the baseRevision this call needs. Uses the active career store. Send patch + changelog + baseRevision from get_hunt_policy; untouched fields survive and conflicts reject stale writes. Save only standing criteria stated now or explicitly reconfirmed now. Keep one-time requests as session overrides unless asked to save them. Does not write Career Direction or profile facts. Returns policy, revision, readiness, and changed fields. Each save is measured against the owner's board: replay counts the rows the change newly excludes or no longer excludes, kept rows (look_closer through sent) named first, and its verdict is kept in the policy history; dryRun: true measures without saving. Alias: update_hunt_policy.

set_hunt_policy

Save a tailored CV into the user's account as a new application; it appears on their application board at app.newcvtool.com ready to refine and export as an ATS-safe PDF. New applications default to status drafted and source manual unless you pass those fields. Status is not required on create and must be drafted or later — found jobs without a CV use save_opportunity. Pass opportunityId to link the CV onto an existing found job without a duplicate row. This does not send, email, or submit the application. Provide `cv` — a cv-edit-result/v1 `cv` object with a roles[] array. The tool stamps the user's real identity onto it. Optional applyUrl / answers / packDocuments / extrasNone / componentReadiness store the send-review pack; componentReadiness reports missing|in_progress|ready (with letter not_required and documents none_required) so agents can see what is actually complete before the five owner checkboxes are set.

save_application

Search the shared company database. query matches name, former names/aliases, domain, HQ location, industry, website and careers URL; every word must match (e.g. 'pharma basel'). location, industry and atsKind narrow further. Use it whenever the user remembers an employer only partly, before asking them, and alongside list_applications when reconstructing an application. Returns careers URL, apply host, ATS kind/token, confidence (reported | observed | verified), followStatus (following | paused | off | null), cadence, lastCheckedAt, nextCheckAt, due, and feedSupported (true for greenhouse | lever | ashby | smartrecruiters | recruitee). Use it as a hunt engine: find employers worth following, then follow_company and check_company_jobs. A job-board host is never a company domain. Holds no credentials. Following none is a normal state, not an error.

list_companies