Your AI assistant can drive iampro.io.

THE labour-market picture for the user's own occupation and area — use this for any question about their market, prospects, whether to stay or retrain, or where to move. Returns, from iampro's index of live postings: how many jobs exist near them vs nationwide vs across a reachable border, the weekly posting trend, jobs-per-100-seekers, the areas where their field is most CONCENTRATED (location quotient, not raw counts), median pay, the share of postings that are staffing agencies or anonymous, and — the core of it — career PIVOTS: occupations their skills transfer to, each with its real local and national market, median pay and pay delta, flagged when the transition is documented by O*NET (US Dept of Labor). Everything is scoped to their profile, worldwide. Never answer 'how is my market doing' from general knowledge — call this.

Employers who actually post FOR THE USER'S OCCUPATION near them — including across a commutable border. Discovered from iampro's own posting index and keyed on what each posting IS (occupation), not on the employer's declared sector, so results are profession-precise for any profile (knowledge work as much as trades) in any country and language we index, with no national business registry involved. Staffing agencies and anonymous postings are excluded. Prefer this over who_is_hiring_near (raw hiring volume, any trade) whenever the question is 'who could hire ME'. Set include_pivots to also cover the occupations their skills transfer to.

The user's analyzed job matches, scored against their profile (match_score 0-100; verdict APPLY/MAYBE/SKIP), strongest first. This is the live feed for 'which job should I apply to'. Defaults to jobs not yet applied to (and never hidden/declined). If the user has no analyzed jobs yet, returns the live profile-ranked feed instead (same engine as the site's 'For me') — the result's `source` field says which you got; live items have no match_score, use analyze_job for a scored verdict. Each item carries the iampro job_posting_id — pass it to log_application once the user applies.

Free keyword search over iampro's live job index — fresh, deduplicated, liveness-checked offers. Built for parameterized agent scans ('security architect near Denver, posted last 2 days'): keywords plus optional location/radius and recency window. Keyword-driven, not profile-filtered (recommended_jobs is the profile-ranked feed) — but when you omit location it centers on the user's profile location, so a bare 'jobs near me' stays local; pass an explicit location to scan elsewhere, or remote=true for remote-only. Results are compact — pass a job_posting_id to get_job_detail for the full description.

Full detail for one job posting (description, apply url, work mode, contract type, salary) — recommended_jobs only returns a summary. Use this before drafting a cover letter or answering questions about a specific listing.

Analyze a specific job the user pastes (description text, optionally a URL/title/company) against their profile — iampro's core match: a fit score, strengths, and the gaps to address. USES AI AND COSTS CREDITS (or a free-trial analysis); re-analyzing the same job returns the cached result with no extra charge. Tell the user it will use a credit before calling. For jobs already in iampro's index use recommended_jobs / get_job_detail instead — this is for an outside offer.

PREFER find_employers_to_approach for anything trade-matched — it scans the whole employer substrate by the user's trade + location (offer or not) and ranks it for them. Use who_is_hiring_near ONLY for raw hiring VOLUME regardless of trade (ranked by hiring_count), e.g. 'who's posting the most jobs near me'. Employers with a real hiring signal ('recrute N') near a point — the hidden market for a door-knocking / interim canvassing tour. Each result carries siret + name + lat/lng + distance_km + hiring_count + likely_roles + a propensity tier/reason. Use it to TRIAGE tour targets (start with high propensity, close, regularly hiring, matching the user's target). Pass exclude_sirets (from list_tours' already-canvassed stops) to propose a NEW tour that skips boxes already visited. Bounded: radius ≤ 30km, ≤ 25 results. Pass EITHER lat+lng OR location (a city, e.g. 'Houston, TX') — location is geocoded server-side, so you don't need to ask the user for coordinates.

Real employers to APPROACH DIRECTLY near a place — offer or NOT. The hidden market beyond posted jobs: who_is_hiring_near only sees boxes with a live signal; this scans the full establishment substrate by TRADE + geography, so it surfaces companies that would hire but haven't posted. Trade comes from `activity` (e.g. 'événementiel', 'restauration', 'logistique') OR, if you omit it, the user's ACTIVE TARGET — so you can just say 'find me places to approach'. Ranked SME-first weighted by hiring propensity; each result carries contact channels (phone/email/website), likely_roles, distance, an approachability note and a hiring_propensity reason. USE IT for orientation: pick the best-fit few, tell the user WHY each fits, draft a tailored spontaneous application per company, hand over the contact, and offer save_tour to build a door-knocking route. Bounded: radius ≤ 25km, ≤ 25 results. Pass EITHER lat+lng OR location (a city, geocoded server-side). Each employer may carry a `hiring_track_record` (first_seen, days_seen, offers_now, offers_peak): how many distinct days we have observed it carrying a live offer, and when we first did. Use it to QUALIFY — many days seen means it hires regularly, a first_seen of a few days ago means it JUST opened its hiring and few people know yet. Absent means we have no record, not that the employer is bad. Never surface or reason on demographics — trade, size and place only.

Sourced salary benchmark for one role in one city. Returns p10–p90 percentile dispersion from official statistics (Eurostat/BLS/INSEE/SCB/BfS) when the benchmark covers the role, with provenance; falls back to low/median/high with is_estimate=true otherwise. One role+city per call.

Read the user's full profile so you see what you're about to change instead of editing blind: name, title, summary, location, availability, contract type, target roles, skills, and every experience with its id, title, organization, dates and display_order. Call this before edit_experience / reorder_experiences / update_profile.

Update a small, safe subset of the user's profile on their behalf — only the field(s) passed are touched, everything else is left alone. Covers the public-profile text shown at profile.iampro.io (name, title/headline, summary, skills, online_accounts) plus search/matching metadata (location, availability, contract_type wanted, target_roles) and the CV contact phone. Use when the user mentions a change in conversation (moved city, new headline, reworded summary, a skill they now have, their LinkedIn or GitHub link) instead of telling them to go edit it in the app. For experiences, proof cards or stories use the dedicated tools.

Edit one experience the user already has (id from get_profile). Only the field(s) you pass change; the rest is left alone. Use it to fix a name (e.g. a company/product renamed), correct dates, rewrite the description, or curate skills_used — the per-role skill list that drives the public page's 'Proven by experience' tier.

Add a new experience to the profile (work, education, certification or project). At least a title is required; dates and description optional.

Set the display order of experiences by passing their ids (from get_profile) in the order you want them shown, first = top. Use it to lead a targeted CV with the most relevant experience.

Permanently remove an experience (and its achievements) from the profile. Irreversible — confirm with the user first. To only hide it on one target's CV, use set_experience_visibility instead.

The user's targets — the activable identities (capacité × canal × géo) they pursue. The active one drives search/tour/CV.

Is the user's evidence vault THIN for a target? Returns coverage and the missing capabilities the CV can't yet back. Use this BEFORE generating a CV for an interim/stopgap target: when `thin` is true, interview the user to surface transferable proof (volunteering, military, sports, side jobs, licenses, languages, physical/public-contact work) and write it with add_evidence — then the CV is grounded instead of hollow. Omit target_id to use the user's active target.

Make one of the user's targets the ACTIVE lens — search, the agency tour, and generated CVs all run against it. At most one active at a time; reversible. Use the id from list_targets.

Drop one of the user's targets from list_targets/the switcher without deleting it — status='active' is sticky (activate_target never reverts it), so a target that was ever briefly the working lens lingers forever unless explicitly archived. Reversible: activate_target or set_target on the same id brings it back. Use the id from list_targets.

Create or refine a target (a job-search identity: capability × channel × geography). Pass label to create a new one; pass id to edit. Activation is separate (activate_target). Set `language` when this identity's CV must be written in a specific language (e.g. a border-crosser pursuing both French and German-speaking-Swiss roles from the same evidence vault) — get_cv reads it instead of auto-detecting. Set `cv_format` to 'dossier' for markets that read for depth (ESN/consulting, Swiss/French enterprise, public sector) — get_cv then writes an explicit dossier de compétences per role instead of the concise 'impact' default.

Read the user's evidence vault (the claims backing their CVs) — verified and unverified. Use it BEFORE add_evidence to avoid asking about / duplicating something already captured, and before get_cv to know what the generated CV will actually be grounded in.

Read the user's return-to-employment pathways — the routes iampro projects from their evidence vault (each a direction with its own angle and CV). Use it to discuss options and pick a target to pursue. Returns null if none have been generated yet.

The user's OWN past employers that are hiring RIGHT NOW — warm doors. Crosses their work history (from the active profile) with the live hiring signal. A former employer already knows the candidate → a warm reintroduction, not a cold application, and it makes an employment gap invisible. This is the top lever for a stalled search or a long career gap: reactivate people who already know them. Surface these FIRST when the user has a gap or feels stuck. Returns each former employer with its live hiring_count + likely_roles + links. No input — reads the active profile.

List the documents the user uploaded to their iampro vault (CVs, diplomas, certificates, attestations) — id, filename, type, title, status, and how many evidence claims each produced. Use read_document to get a document's full text.

Read one uploaded document's faithful full-text transcription (plus metadata and the evidence extracted from it). Use it to pull an exact detail the user can't remember — a precise qualification title, a date, an issuer — straight from their own uploaded proof, instead of asking them to re-upload it. document_id from list_documents.

Write one piece of verified-capability evidence into the user's vault on their behalf — the way a connected LLM closes the elicitation loop after interviewing the user. Added UNVERIFIED: the user confirms it on iampro before it counts. Reversible (returns an undo_token). One claim per call.

Mark an evidence item as confirmed by the user (verified=true) after they've told you it's accurate — or retract it (verified=false). ONLY a user-verified claim is citeable on a CV, so unverified evidence is why a CV comes out hollow; walking the user through confirming their evidence unblocks it. Never verify on your own judgement — the user must confirm the claim is true. evidence_id from list_evidence.

Re-edit the CONTENT of one existing evidence item in the user's vault — the claim wording, claim_type, confidence, impact metric, keywords or skills — e.g. after the user corrects or sharpens a claim. Editing the content RESETS it to UNVERIFIED: the user re-confirms it on iampro before it counts again (their prior confirmation was of the old wording). Only the field(s) passed are changed. evidence_id from list_evidence. To create a new claim use add_evidence; to only confirm/retract use verify_evidence.

Remove one evidence item from the user's vault — the missing piece for DEDUPLICATION (the same certification or diploma saved several times bloats the vault without proving more). Confirm with the user first and delete only on their explicit go-ahead; to fix wording keep the item and use edit_evidence instead. Soft-delete: the row is kept for audit but disappears from every surface (vault, CV grounding, pathways). evidence_id from list_evidence.

Recompute the user's return-to-employment pathways from their CURRENT evidence vault + profile, then return the fresh set. Use this when get_pathways came back stale (its 'stale' flag is true, or the user just added/verified evidence or changed their profile) instead of only telling them it's out of date — this closes the loop. Costs one iampro AI generation; call it when the vault actually changed, not on every turn.

Delete one uploaded document (piece) from the user's iampro vault — use it to clear a duplicate or a wrong upload the user asked to remove. The evidence claims that document produced are KEPT (they may already be verified or cited on a CV) — only the file and its metadata go. Irreversible: the original scan is gone. Get explicit user go-ahead naming the piece before calling. document_id from list_documents.

Generate (or return the cached) profile-view CV for a target, grounded in the user's VERIFIED evidence — works for any target, whether or not it came from a reviewed pathway. Check target_gaps first — if `thin` is true, interview the user and add_evidence before calling this, or the CV will be hollow. Omit target_id to use the active target.

Get everything you (the assistant) need to COMPOSE a CV for a target YOURSELF — free, no iampro AI call: the target framing, the user's profile with visible experiences, their VERIFIED evidence (the only citeable claims), their real `contact` block (email, phone, links — so you never leave [email]/[phone]/[LinkedIn] placeholders), the honesty rules, and the exact JSON schema to hand back to save_cv. Prefer this over get_cv when the user is chatting with you: you write the CV, then save_cv stores it (renders to PDF). get_cv triggers iampro's own paid generation instead. Omit target_id for the active target.

Hand-edit a target's current CV content — the mechanism for helping the user build an optimal profile through conversation: draft/refine the professional_summary, a headline, per-experience bullets, skills emphasis, or which certifications to feature, one or several at a time. This is a direct edit, NOT a regeneration — it never overwrites the user's own prior edits with a fresh LLM pass, and it doesn't consume a version-history slot the way get_cv's regeneration does. Call get_cv first (there must be a CV to edit) and target_gaps to know what's thin. Omit target_id to use the active target.

Hide or show one Experience in a target's CV/profile view — e.g. hide a hospitality role from the 'Data Engineer' identity while keeping it visible on 'Restaurant Manager'. Hidden experiences are excluded from future CV generations for this target AND stripped from what's shown right now, with no regeneration needed. Fully reversible — hiding never deletes the experience or its reformulated bullets. Omit target_id to use the active target.

Store a CV YOU composed (from get_cv_material) for a target so iampro renders it to PDF and keeps it. iampro validates it first: any quantified claim (%, ×, money) not backed by the user's verified evidence or profile is REJECTED and returned to you to fix — iampro's promise is a CV the user can defend, so never invent figures. On success the saved CV becomes the one get_cv returns.

Read the user's showcase stories — STAR-format proof cards that can be made public on their profile.iampro.io page (a shareable link, separate from the private CV). Each item: id, title, is_public, is_highlight, experience_id, has_article (whether a long-form article_md body exists). Use it BEFORE write_showcase_story to avoid drafting a duplicate of something already captured. This is an index, not the content: call get_showcase_story to read one.

Read ONE showcase story in full — every field write_showcase_story can set, the long-form article_md body included. list_showcase_stories only returns titles and metadata, so call this BEFORE editing an existing story: write_showcase_story is a partial update, and any change that depends on the current text — fixing a URL inside the article, appending a section, translating it — is guesswork without reading it first. Rewriting a body you have not read silently discards whatever was there. Pass lang to also get one stored translation; article_langs always lists which translations exist.

Create or edit (pass achievement_id) a showcase story — a.k.a. a PROOF CARD on the public profile (profile.iampro.io): this is THE tool for rewording or correcting one (its title included — e.g. a card that overstates a prototype as a production system). Find its id with list_showcase_stories. It is the mechanism for helping the user turn a conversation about a project into a public-ready STAR narrative: situation/action/result, plus optional depth (constraints, why_this_approach, challenges_faced, what_i_learned) — and, for the full recruiter-facing case study, an article_md long-form body (see that field's description; analyzing the user's actual repo before writing it produces far better articles than working from conversation alone). New stories start PRIVATE (is_public defaults false) — call set_showcase_visibility once the user has reviewed it. Protect the employer this story is about: never include unpublished financials or metrics, named clients or deals covered by an NDA, proprietary internal strategy, security details, or source code, or identifying details about named colleagues who haven't consented to being mentioned. Reframe around what the CANDIDATE did and the impact they had — describe the shape of a result (e.g. "cut latency 60%") without disclosing the specific confidential numbers or systems behind it when those would only be known internally. Reversible (returns an undo_token).

Store an image on the user's own bucket and return its public URL, to be passed back as write_showcase_story's image_url. Use this when you are holding the bytes — a screenshot the user just gave you, a render you produced — rather than a URL. Hot-linking someone else's host works until it doesn't; this keeps the card's visual on the user's storage. Send the raw bytes base64-encoded; JPEG, PNG, WebP and GIF are accepted and the format is detected from the content, not from what you claim it is. Keep a card hero around 200-400 KB: it is rendered a few hundred pixels tall, and the base64 payload is a third larger than the file. Only publish images the user owns or is entitled to republish — a screenshot of their own work, not a page lifted from a client's publication.

Approve (or hide) a showcase story for public display on profile.iampro.io, and/or feature it (is_highlight) at the top of the page. A story is never public until the user (or the user, via this tool, on their explicit instruction) approves it — always confirm with the user before setting is_public true.

Set the top-to-bottom order of the proof cards on the public profile (ids from list_showcase_stories), first = top. This is the ranking the page had no way to express: a reader gets through two or three cards, so which two lead decides what the profile argues. Order for the role being targeted — the strongest checkable artifact and the most on-message engagement first, self-reported work last. Ids you omit keep their current position behind the ones you pass.

Where the user's applications actually die: stage-by-stage funnel (applied → answered → interview or beyond), median days to an answer, silence rate after 30 days, split by channel applied through and by company. Rates are null when the sample is too small to mean anything — report them as unknown, never round a 2-application streak into a percentage. Pair with market_outlook to separate a personal problem (low answer rate in a healthy market) from a market one. If the journal is thin, offer to reconstruct it from the user's mailbox: read their application confirmations and outcome emails yourself and record each with log_application, passing status_at = the date on the email.

The user's job-application journal (status, follow-ups), newest first.

The user's prospecting pipeline — every employer they're pursuing, with the follow-ups that are DUE surfaced first (follow_up_at ≤ today, still open). Use it to open a session ('you said you'd follow up with X today') and to see the whole outreach funnel at a glance. Advance a company with log_contact.

Log (or update) a job application on the user's behalf. Upserts by job_posting_id (our index), by url, or — for off-platform applications that have neither — by company+title, so logging the same job twice doesn't duplicate. An application remembered or reconstructed from a mailbox needs nothing but a company. Reversible. When the user mentions an interview, a rejection or an offer, ALSO offer to capture what it revealed — new skills, accomplishments or lessons — as evidence (add_evidence) or a story (write_showcase_story): career memory grows from exactly these moments.

Remove ONE application from the journal — the missing piece for cleaning up a wrong or duplicate entry (log_application only adds or updates). Confirm with the user and delete only on their explicit go-ahead; to record a candidacy the user pulled out of, prefer log_application with status 'withdrawn' (that keeps the funnel history). Reversible via undo_token. application_id from list_applications.

Record or update the user's outreach state for ONE employer — the prospecting CRM that sits between 'who is hiring' and 'where my prospection stands'. Upserts by company: re-logging the same company advances its state instead of duplicating. Use it after the user reaches out ('contacted QIM Info today, follow up in a week'), and set follow_up_at so list_prospects can surface it as due. Distinct from log_application (a submitted application) and tours (door-knocking).

The user's saved field tours (door-knocking routes) with their per-stop canvassed state. Each tour: id, name, place, active, done, stops_count, visited_count, and stops [{siret, name, visited}]. Use it to (a) know which boxes are already canvassed (collect visited sirets → pass as exclude_sirets to who_is_hiring_near), (b) spot tours that look walked but aren't fully confirmed, and prompt the user to confirm states / mark done.

Create or edit a field tour from a list of stops (the triaged employers). Pass stops as objects with at least siret + name + lat + lng (take them straight from who_is_hiring_near). Omit id to create; pass id to edit (the canvassed state of kept stops is preserved). The tour becomes the active one shown on the user's phone. Reversible (deletable). Confirm the stop count with the user first (8 / 15 / 25…).

Mark a field tour as walked (done) — or reopen it (done=false). A walked tour stops being the active one and its boxes drop out of new tours. Ask the user whether they actually completed the tour before marking it done.

Confirm the per-stop canvassed state of a tour: which boxes were actually visited and which couldn't be. Pass visited as {siret: true|false}; it is merged into the tour's ledger. Use it to help the user reconcile a tour they've walked (some stops done, some skipped) before marking it done.