The Resume-Tailor MCP Server enables you to persistently store, tailor, score, and export your résumé to match any job posting — all driven by an AI assistant like Claude, running locally for full data privacy.
Save & load a master CV: Store a structured JSON résumé (contact info, summary, experience, skills, education, projects) that persists across sessions — set it once, reuse it for every application.
Fetch job postings: Scrape and clean a job description from a URL, or accept pasted text if the site is login-walled or blocked.
Extract ATS keywords: Deterministically rank skills, tools, and terms an Applicant Tracking System would scan for using frequency-based analysis.
ATS gap analysis: Compare your résumé against extracted keywords to get a match score, a list of matched terms, and the exact missing terms to address.
Export ATS-safe files: Render your tailored résumé as a clean PDF or DOCX — single-column layout, standard fonts, and real selectable text.
AI-driven tailoring: Claude uses your stored CV, job data, and gap analysis together to rewrite and optimize your résumé before export.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Resume-Tailor MCP Server Tailor my master resume for this job posting and export as PDF"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An open-source Model Context Protocol server that gives Claude Desktop (or any MCP client) a persistent master résumé, a real ATS keyword score, and clean PDF / DOCX export.
Quick start · Tools · How it works · Contributing · Releases
You: "Here's a job link — tailor my CV and export a PDF."
Claude reads the posting and your master CV, rewrites it to match, checks the ATS keyword score, and hands you a clean file ready to send.
Related MCP server: ats-resume-writer
Claude can already rewrite a CV in a normal chat. This MCP is worth installing for the three things a plain chat can't do:
Feature | What it gives you |
Persistent master CV | Stored locally as JSON. Set it up once, reuse it for every job. |
Real ATS gap score | Deterministic keyword math — not vibes. Tells you exactly which keywords you're missing. |
Clean file export | ATS-safe PDF / DOCX: single column, standard fonts, real selectable text. |
The MCP does not rewrite your CV — Claude does that. The server supplies the persistence, the job fetch, the ATS math, and the export. Claude ties it together.
load_master_resume ─┐ ┌─► export_resume
├─► Claude rewrites the CV ─► ats_gap_check ─►──┤
fetch_job_posting ─►│ ▲ └─► export_cover_letter
extract_keywords ───┘─────────────────────────────────────┘Load your master CV — load_master_resume
Analyze the job — fetch_job_posting → extract_keywords
Rewrite — Claude rewrites the CV to honestly surface the missing keywords
Check the rewrite — ats_gap_check (did the score go up?)
Export — export_resume → a clean PDF or DOCX
Cover letter (optional) — export_cover_letter → a matching PDF or DOCX
Tool | Purpose |
| Store/update the base CV (structured JSON: contact, summary, experience, projects, skills, education). |
| Return the stored master CV so Claude can work from it. |
| Fetch a job URL → clean text. Falls back to pasted text if the site is blocked or login-walled. |
| Deterministically pull the ranked skills/tools an ATS scans for. |
| Compare a CV against the job keywords → match score (%) + the exact missing terms. |
| Render finished CV content (markdown or JSON) → a clean PDF or DOCX. Returns the file path. |
| Render a finished cover letter → a matching PDF or DOCX. Optionally adds a letterhead (name + contact) from the master CV. Returns the file path. |
pip install resume-tailor-mcp # or: uvx resume-tailor-mcpThat installs a resume-tailor-mcp command that runs the MCP server.
git clone git@github.com:NmaaAlhawary/MCP-Resume-Tailor.git
cd MCP-Resume-Tailor
python3 -m venv .venv
source .venv/bin/activate # fish: source .venv/bin/activate.fish
pip install -r requirements.txtSmoke-test that all seven tools register:
python -c "import asyncio, server; print([t.name for t in asyncio.run(server.mcp.list_tools())])"PDF export usesreportlab (pure Python — no system libraries needed on macOS/Windows/Linux). DOCX export uses python-docx.
Add this to your claude_desktop_config.json
(~/Library/Application Support/Claude/claude_desktop_config.json on macOS).
If you installed from PyPI (simplest — uvx fetches and runs it):
{
"mcpServers": {
"resume-tailor": {
"command": "uvx",
"args": ["resume-tailor-mcp"],
"env": { "RESUME_STORE_PATH": "~/.resume-mcp/master.json" }
}
}
}If you installed from source, point at your venv's Python and server.py:
{
"mcpServers": {
"resume-tailor": {
"command": "/absolute/path/to/MCP-Resume-Tailor/.venv/bin/python",
"args": ["/absolute/path/to/MCP-Resume-Tailor/server.py"],
"env": { "RESUME_STORE_PATH": "~/.resume-mcp/master.json" }
}
}
}Restart Claude Desktop — the seven tools appear under the tools menu.
Copy master.template.json, fill in your details, then ask Claude:
"Save this as my master resume: (paste the JSON)"
Claude calls save_master_resume and it persists at RESUME_STORE_PATH.
You: Here's a job link — tailor my CV for it and export a PDF:
https://example.com/careers/senior-frontend
Behind the scenes Claude runs:
1. load_master_resume() → your stored CV
2. fetch_job_posting(url="…/senior-frontend") → clean job text
3. extract_keywords(job_text) → ["REST APIs", "GraphQL", "TypeScript",
"Docker", "AWS", "Next.js", "CI/CD", …]
4. ats_gap_check(resume_text, keywords) → { match_score: 20.0,
missing: ["GraphQL","Docker","AWS",…] }
5. ── Claude rewrites the CV to surface real, matching skills ──
6. ats_gap_check(new_resume_text, keywords) → { match_score: 85.0 }
7. export_resume(content=<rewritten>, format="pdf")
→ { path: "~/.resume-mcp/exports/….pdf" }
8. export_cover_letter(content=<letter>, format="pdf")
→ { path: "~/.resume-mcp/exports/…_cover_letter.pdf" }Claude: Tailored your CV — keyword match went from 20% → 85%. I added your Docker/AWS and testing experience to match their stack, and drafted a matching cover letter. Exported here:
~/.resume-mcp/exports/Jane_Developer_….pdf~/.resume-mcp/exports/Jane_Developer_…_cover_letter.pdf
Env var | Default | Purpose |
|
| Where the master CV JSON lives. Exports go to |
Everything runs locally. No secrets, no external accounts.
SSRF-guarded fetching — fetch_job_posting only follows http/https URLs to public hosts. Requests to localhost, private/LAN ranges, or cloud metadata (169.254.169.254) are refused, and redirects are re-checked on every hop. Downloads are capped at ~3 MB.
Synonym-aware ATS scoring — the gap check treats common equivalents as a match (e.g. K8s↔Kubernetes, JS↔JavaScript, Postgres↔PostgreSQL), so scores reflect real coverage.
Unicode-safe PDFs — a bundled Unicode font renders accented names (José, résumé) correctly instead of empty boxes.
Master-CV backup — saving over an existing master CV first writes a .bak copy.
Single column — no text boxes or multi-column tricks that break ATS parsers
Standard fonts (Calibri for DOCX, a Unicode sans for PDF)
Real, selectable text — never image-rendered
Plain headings and bullet lists that map cleanly to resume sections
Contributions of any size are welcome. The quickest way in: fork the repo, make your change, and open a pull request.
# 1. Fork on GitHub, then clone your fork
git clone git@github.com:YOUR-USERNAME/MCP-Resume-Tailor.git
cd MCP-Resume-Tailor
# 2. Set up and branch
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
git checkout -b my-improvement
# 3. Change, commit, push
git commit -am "Describe your change"
git push origin my-improvement
# 4. Open a Pull Request on GitHubGreat first contributions: add skills to KNOWN_TERMS / KNOWN_PHRASES in
server.py, filter a filler word in STOPLIST, or improve the export layout.
See CONTRIBUTING.md for the full step-by-step guide.
Released under the MIT License. By contributing, you agree your contributions are licensed under the same terms.
Built by Nmaa Hawary · If this helped, consider giving it a star.
Compare a CV against job keywords → match score (%) + missing terms.
This is the tool's killer feature: it tells the user concretely what to add. Pass the resume as plain text and the ranked keyword list from extract_keywords. Returns which keywords are present, which are missing, and a match percentage — so Claude knows exactly what to surface in the rewrite.
Returns {match_score, matched, missing, total_keywords}.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | ||
| resume_text | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It describes the return format (match_score, matched, missing, total_keywords) and states it 'tells the user *concretely* what to add.' However, it does not mention idempotency, permissions, side effects, or rate limits. For a read-like operation, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs plus a line showing the return format. The first sentence is front-loaded with the core purpose. The second paragraph adds context but could be slightly more concise without losing clarity. Overall, it efficiently communicates necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema exists) and the presence of sibling tools, the description provides sufficient context: it explains inputs, outputs, and usage with extract_keywords. The return format is described in text despite an output schema. It covers the essential information for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds valuable semantics: it clarifies that resume_text should be 'plain text' and that keywords should be 'the ranked keyword list from extract_keywords.' This goes beyond the schema to guide correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Compare a CV against job keywords → match score (%) + missing terms.' It clearly identifies the resources (CV/resume and keywords) and the outcome (match score and missing terms). It also distinguishes itself from sibling tools like extract_keywords by describing its unique value as a 'killer feature' that tells the user exactly what to add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use: 'Pass the resume as plain text and the ranked keyword list from extract_keywords.' It implies the tool should be used after extract_keywords and before rewriting. While it doesn't explicitly state when not to use or list alternatives, the context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render finished CV content to a clean, ATS-safe PDF or DOCX file.
Pass content as either markdown text (use #/##/### headings and -
bullets) OR structured CV JSON (same shape as the master resume). Choose
format = "pdf" or "docx". The layout is deliberately single-column with
standard fonts and real text (never image-rendered) so ATS parsers read it.
Returns {path, format, blocks} with the saved file path.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | docx | |
| content | Yes | ||
| filename | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses output format traits: ATS-safe, single-column, real text. It also describes the return object shape. It does not mention file overwrite behavior or error conditions, but covers key behavioral attributes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no wasted words. Purpose, content guidelines, format and layout, and return type are each clearly stated in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input formats, output format, layout properties, and return structure. Missing details on filename behavior or error handling are minor given the output schema exists. Complete for standard use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains the content parameter (markdown vs structured JSON with syntax hints) and format parameter (pdf/docx). The filename parameter is not described, but overall adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders CV content to PDF/DOCX, specifying both input formats and output options. It differentiates from sibling tools like load_master_resume and save_master_resume by focusing on final export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after resume completion ('Render finished CV content') and gives detailed formatting instructions. However, it does not explicitly contrast with siblings or specify when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull the skills/tools/keywords an ATS would scan for from a job posting.
Deterministic (no ML): tokenizes the text, filters filler words, recognizes known skills and multi-word phrases (e.g. "REST APIs"), and ranks by frequency — boosting terms that appear in skills/requirements sections.
Returns {keywords: [ranked strings], detail: [{keyword, score, known_skill}]}. Use the ranked keyword list as input to ats_gap_check.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| job_text | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: deterministic, tokenizes, filters filler words, recognizes skills and phrases, ranks by frequency with boosting. It also states the return format, leaving no ambiguity about what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a lead sentence explaining the purpose, a sentence on the algorithm, a sentence on the output format, and a final usage recommendation. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and no annotations, the description covers purpose, algorithm, output, and usage. It lacks details on error handling or input constraints (e.g., what happens with empty text or extreme top_n values), but for a straightforward extraction tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, so the description must compensate. It only implicitly covers job_text (the text to tokenize) but does not mention top_n at all, leaving a parameter undocumented. Although the output format is described, the optional parameter's effect on ranking is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool extracts skills/tools/keywords from job postings using a deterministic method. It specifies the exact verb 'pull' and resource 'job posting', and distinguishes itself from siblings by focusing on keyword extraction for ATS scanning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using the output as input to a sibling tool (ats_gap_check), providing clear usage context. However, it does not specify when not to use this tool or mention any prerequisites like using fetch_job_posting first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a job posting as clean readable text.
Pass a url to fetch and strip a posting to plain text, OR pass
pasted_text directly if you already have the description. URL fetching is
best-effort: if the site is blocked or login-walled, this returns a clear
message asking the user to paste the text instead — it never fails silently.
Returns {source, text, char_count}.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| pasted_text | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It transparently discloses that URL fetching is 'best-effort,' that it 'never fails silently,' and returns a clear message on failure. It also explicitly lists the return fields {source, text, char_count}, leaving no ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise: four sentences covering purpose, parameters, behavior, and return format. Every sentence adds essential information with no redundancy. It is well-structured with the first sentence as an effective summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers all relevant aspects: input modes, failure behavior (blocked/login-walled), and output structure ({source, text, char_count}). It is complete enough for an agent to understand when and how to invoke the tool without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does by explaining the roles of 'url' (to fetch and strip a posting) and 'pasted_text' (for direct input). This adds semantic meaning beyond the schema's type/default. However, it could include more detail like URL format expectations or text length limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a job posting as clean readable text.' It specifies two distinct modes (URL or pasted_text), making the tool's purpose unambiguous. While it doesn't explicitly contrast with siblings, the verb 'fetch' and resource 'job posting' are specific enough to differentiate from tools like ats_gap_check or export_resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage guidance by explaining when to use URL vs pasted_text, including the fallback behavior: 'if the site is blocked or login-walled, this returns a clear message asking the user to paste the text instead.' It doesn't compare to sibling tools, but within the tool itself, it gives clear context on effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the stored master CV so Claude can tailor it to a job.
This is the starting point of every tailoring session. If no resume is stored yet, raises a clear error telling the user to save one first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses core behavior (returns stored CV) and error handling (raises clear error if none stored), which is comprehensive given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, zero waste, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple read operation with output schema present; description covers purpose, usage context, and error case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (schema coverage 100%), so baseline 4 applies; description adds no param info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Return the stored master CV' with a specific verb and resource, and distinguishes from siblings like save_master_resume by calling it the 'starting point of every tailoring session'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use ('starting point of every tailoring session'), provides error context, and though no explicit exclusions, the sibling list implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store or update the user's base CV so it persists between sessions.
Provide the CV as structured JSON. Recommended keys: contact - {name, email, phone, location, links} summary - short professional summary (string) experience - list of {title, company, location, start, end, bullets[]} projects - list of {name, description, tech[], link} skills - list of strings (or {category, items[]}) education - list of {degree, school, location, start, end, details}
This is step 1 of the flow: set it up once, reuse it for every job. Returns a confirmation with the stored path.
| Name | Required | Description | Default |
|---|---|---|---|
| resume | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses persistence and returns a confirmation path, but lacks details on update behavior, validation, error handling, or constraints (e.g., size limits). The phrase 'Store or update' implies idempotence but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear first sentence, a helpful block of recommended keys, and a concluding sentence about the flow and return value. Slightly verbose due to the key list, but it's practical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one nested parameter and an output schema (not detailed in input), the description covers the input structure well but only briefly mentions the return value ('confirmation with the stored path'). Missing details on output format, behavior on overwrite, or error cases. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single object parameter 'resume' with additionalProperties: true, providing no structure. The description adds significant value by listing recommended keys and their structure (contact, summary, experience, projects, skills, education), though it notes these are recommended, not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Store or update the user's base CV so it persists between sessions.' It distinguishes from siblings by calling this 'step 1 of the flow' and contrasting with load_master_resume and export_resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'This is step 1 of the flow: set it up once, reuse it for every job.' It implies when to use but does not explicitly state when not to use or provide alternative tool names (though sibling context exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0ats_gap_checkexport_resumeextract_keywordsfetch_job_postingload_master_resumesave_master_resumeScored across 6 tools
Each tool has a distinct, non-overlapping purpose: fetching job posts, extracting keywords, analyzing gaps, managing the master resume, and exporting. An agent can clearly distinguish them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., fetch_job_posting, extract_keywords), making them predictable and easy to understand.
With 6 tools, the scope is well-balanced: each tool serves a necessary step in the resume tailoring workflow without redundancy or excessive complexity.
The set covers the core pipeline from job posting to export, but lacks a dedicated tool to save tailored resume versions separately from the master. This minor gap is manageable for agents.
A job-search companion: tailor your CV to a role, score fit, fix ATS issues. Also via MCP.
Tailor resumes, generate cover letters, render CVs as PDF, and browse 22+ templates.
Auto-apply to jobs: matches your CV, tailors a fresh CV per posting, and applies for you.
Score and tailor your CV/resume against a job posting — for AI agents and humans, no-login trial.
