MCP (Model Context Protocol) server for CV Forge. Lets AI assistants generate professional CVs as PDF/DOCX from conversation data.
You describe your experience to the AI (or paste LinkedIn profile text)
AI fills in the CV template using the generate_cv tool
AI calls generate_pdf or generate_docx to produce the document
You get a PDF/DOCX file and a link to the visual editor for manual tweaks
The MCP server automatically pulls and starts the CV Forge Docker container — no manual setup needed.
Related MCP server: resume-mcp
claude mcp add cv-forge -- uvx cv-forge-mcpAdd to ~/.config/claude/claude_desktop_config.json (Linux) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"cv-forge": {
"command": "uvx",
"args": ["cv-forge-mcp"]
}
}
}pip install cv-forge-mcpTool | Description |
| Returns an empty CV JSON template for the AI to fill in |
| Generates ATS PDF from CV data, returns file path + editor URL |
| Generates ATS DOCX from CV data, returns file path + editor URL |
See INSTRUCTIONS.md for the full system prompt and workflow guidelines for AI assistants using CV Forge.
CV Forge: https://github.com/Guid-Lab/cv-forge
Live Demo: https://cv.guidlab.pl
Docker Hub: https://hub.docker.com/r/guidlab/cv-forge
Set up CV Forge backend. MUST be called before generate_pdf or generate_docx.
Detects the environment and lets the user choose how to run CV Forge:
"local": Run locally via Docker (pulls image if needed, ~1.7 GB)
"remote": Use the hosted demo at cv.guidlab.pl (no install needed)
"auto": Auto-detect — use local if Docker is available, otherwise remote
If mode is "auto", present the user with the available options and ask which they prefer. If only one option is available, use it automatically.
Args: mode: "local", "remote", or "auto" (default).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | auto |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Rich behavioral details: environment detection, Docker image size (~1.7 GB), hosted demo URL (cv.guidlab.pl), auto-detection logic, and interactive user-prompting behavior for mode selection.
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?
Well-structured with critical prerequisite front-loaded. Clear separation of mode explanations. Slightly verbose in describing auto-mode interaction logic, but all sentences provide actionable value. 'Args:' section effectively bridges schema gap.
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?
Single-parameter tool with output schema present (so return values need no description). Despite 0% schema coverage and no annotations, description fully explains the setup workflow, environment requirements, and sibling dependencies. Complete for tool complexity.
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?
Schema has 0% description coverage. Description compensates by documenting all valid enum values ('local', 'remote', 'auto'), their meanings, and noting the default. Could explicitly state the parameter is optional (implied by 'default' mention but not explicit).
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?
Clear specific verb ('Set up') + resource ('CV Forge backend'). Explicitly distinguishes from sibling generation tools by stating 'MUST be called before generate_pdf or generate_docx', establishing the prerequisite relationship.
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?
Explicit prerequisite declaration ('MUST be called before...'). Clear when-to-use guidance for each mode: local requires Docker, remote needs no install, auto detects availability. Explains interactive behavior for 'auto' mode (present options to user).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return an empty CV JSON template for the AI to fill in.
IMPORTANT: Before calling this tool, gather the user's information first. Ask the user about each section they want to include:
Full name, job title, contact details (email, phone, LinkedIn, GitHub, location)
Work experience: company names, roles, dates, key achievements/responsibilities
Education: institutions, degrees, dates
Skills: categorized technical and soft skills
Certifications, projects, courses, languages (if applicable)
Do NOT generate a CV with placeholder or empty fields. Ask follow-up questions for any missing critical sections (at minimum: personal info, experience, education, skills).
IMPORTANT: Always fill in URLs for employers, education institutions, and certification issuers. Use their official website URLs (e.g. url: "https://www.google.com" for Google, issuer_url: "https://www.offensive-security.com" for OffSec). The editor uses these URLs to automatically fetch company/institution logos.
Template field reference:
Dates: 'Month YYYY' format (e.g. 'January 2023'), use 'Present' for current positions
employer_groups: group_name is the company name, display_company in each position should also be set to the company name (or subsidiary/brand name if different)
bullets: array of achievement/responsibility strings for each position
Contact values: use plain text, NOT prefixed with mailto: or tel: schemes (e.g. "john@example.com" not "mailto:john@example.com", "+48123456789" not "tel:+48123456789")
Contact types: location (no link), email, phone, linkedin, github, website
Flag codes: 2-letter country code (gb, us, de, pl, fr, es, etc.)
Language levels (keys): native, full_professional, professional_working, limited_working, elementary (labels are auto-translated based on cv_language)
desc_format: 'bullets' (list) or 'paragraph' (rich_description field)
disabled_sections: array of section names to hide (e.g. ['projects', 'courses'])
theme: sidebar, topbar, minimal, executive, modern, elegant
color_scheme: navy, ocean, forest, wine, slate, charcoal
font_preset: calibri, helvetica, georgia, garamond, inter, roboto
heading_color: black, auto, navy, graphite, steel, ocean, forest, wine, brown, indigo
Args: language: CV language for section headers — en, pl, de, fr, or es.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | en |
| 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 full disclosure burden. It comprehensively explains behavioral constraints: URLs must be official websites, date format is 'Month YYYY', contact values must not use mailto/tel prefixes, and language level keys must use specific values. Explains that the returned template requires AI population before use.
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 front-loaded with critical workflow instructions, but the extensive 'Template field reference' section (covering dates, employer_groups, bullets, contact types, themes, etc.) makes it quite verbose. While the semantic constraints add value beyond what a schema typically provides, the length approaches over-documentation for a single-parameter tool.
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 complexity of CV generation and the presence of an output schema, the description provides sufficient context: it explains the empty-template behavior, the pre-call data gathering requirement, and detailed field semantics. It appropriately focuses on how to populate the template rather than repeating output schema structure.
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?
Schema has 0% description coverage for the single 'language' parameter. The description fully compensates by documenting: 'CV language for section headers — en, pl, de, fr, or es', adding both purpose and valid enum values absent from 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 explicitly states the tool 'Return an empty CV JSON template for the AI to fill in' — specific verb (Return), resource (CV JSON template), and scope (empty, for AI to fill). It clearly distinguishes this data/template generation step from sibling tools like generate_docx/pdf which likely render the final document.
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?
Provides explicit workflow guidance: 'Before calling this tool, gather the user's information first' and lists required sections to collect. Includes explicit prohibitions: 'Do NOT generate a CV with placeholder or empty fields.' Clearly defines prerequisites and when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an ATS-optimized DOCX from CV data.
Takes a complete CV JSON object (same structure as generate_cv template). All required fields (personal, experience, education, skills) must be filled in.
Returns:
file: absolute path to the generated DOCX file (saved in system temp directory)
editor_url: URL to open in the browser (http://localhost:5000/?load=) where the user can preview their CV visually, adjust layout/colors, and download alternative formats. The link expires after 5 minutes.
Args: cv_data: Complete CV data dictionary with all sections filled in.
| Name | Required | Description | Default |
|---|---|---|---|
| cv_data | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals the file is saved to 'system temp directory,' describes the interactive editor capabilities including layout/color adjustments, and discloses the critical 5-minute expiration on the URL. This comprehensive coverage includes side effects (temporary file creation) and resource constraints.
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 uses an efficient structure with clear sections for purpose, input requirements, return values, and arguments. While slightly redundant in mentioning cv_data requirements twice (prose and Args section), each sentence conveys specific information without excessive verbosity. The format earns its length by documenting complex output behavior including expiration semantics.
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?
For a file generation tool with nested object inputs, the description provides comprehensive coverage including input validation rules, output file location (temp directory), and interactive features (editor URL with token). It adequately prepares the agent for both successful invocation and handling of returned resources including the time-limited browser interface.
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 for the cv_data object, the description compensates effectively by documenting required sections (personal, experience, education, skills) and referencing the generate_cv template structure. It clarifies that additionalProperties are accepted through 'Complete CV data dictionary' while emphasizing completeness requirements, successfully bridging the schema documentation gap.
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 opens with 'Generate an ATS-optimized DOCX from CV data,' providing a specific verb, resource format, and optimization criteria. It distinguishes itself from sibling tools by referencing the generate_cv template structure, clarifying data expectations. The scope is precisely bounded to DOCX generation with ATS formatting requirements.
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 specifies clear prerequisites ('All required fields... must be filled in') and input requirements ('complete CV JSON object'). While it references generate_cv for structural guidance, it lacks explicit guidance on when to select this over generate_pdf or generate_cv. The temporal constraint (5-minute link expiration) adds important usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an ATS-optimized PDF and provide a link to the visual editor.
Takes a complete CV JSON object (same structure as generate_cv template). All required fields (personal, experience, education, skills) must be filled in.
Returns:
ats_pdf: absolute path to the generated ATS PDF file (saved in system temp directory)
editor_url: URL to open in the browser (http://localhost:5000/?load=) where the user can preview their CV with full visual styling, customize colors/layout, and download a Pretty PDF version. The link expires after 5 minutes.
The ATS PDF is a clean, text-based document optimized for applicant tracking systems. For a visually styled PDF with colors, logos, and layout — direct the user to open the editor_url in their browser and click "Download Pretty PDF" there.
Args: cv_data: Complete CV data dictionary with all sections filled in.
| Name | Required | Description | Default |
|---|---|---|---|
| cv_data | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses substantial behavioral context: files are saved to the system temp directory, the editor_url expires after 5 minutes, the ATS PDF is text-based for ATS compatibility, and the Pretty PDF requires browser interaction. It details the return values (absolute path and URL format) that would otherwise be unknown.
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 with clear sections for purpose, input requirements, return values, and Args. The length is justified by the complexity (dual outputs, file locations, expiration timing). Every sentence adds necessary context, though the Args section slightly repeats information provided earlier in the description.
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 absence of annotations and 0% schema coverage, the description adequately compensates by detailing the return values (ats_pdf path and editor_url), file locations, URL expiration, and the distinction between ATS and visual PDF outputs. It successfully explains what the tool produces without needing to reference an external output schema.
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 entirely. It identifies cv_data as a 'Complete CV data dictionary' and references the generate_cv template structure, listing the four required top-level sections (personal, experience, education, skills). However, it does not detail the nested object schemas or data types within those sections, leaving significant semantic gaps given the freeform nature of the parameter (additionalProperties: true).
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 generates an 'ATS-optimized PDF' and provides a visual editor link, using specific verbs and resources. It distinguishes between the ATS PDF (text-based) and Pretty PDF (visually styled) outputs. However, it does not explicitly differentiate from sibling tool generate_docx (which presumably outputs Word documents rather than PDFs).
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 prerequisites (complete CV JSON with personal, experience, education, skills fields filled) and references the generate_cv template structure. It explains the workflow (get ATS PDF immediately vs. use editor_url for styled PDF). However, it lacks explicit guidance on when to choose this over generate_docx or the relationship to cv_forge_setup in the broader workflow.
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. Dates show when Glama detected each change.
v1.3.0cv_forge_setupgenerate_cvgenerate_docxgenerate_pdfEach tool has a distinct, non-overlapping purpose: setup initializes the backend, generate_cv creates a template, generate_docx produces a DOCX file, and generate_pdf produces a PDF file. The descriptions clearly differentiate their roles in the CV creation workflow, with no ambiguity about which tool to use for each step.
All tool names follow a consistent verb_noun pattern with snake_case: cv_forge_setup, generate_cv, generate_docx, and generate_pdf. The naming is predictable and readable, making it easy for an agent to understand the action each tool performs based on its name alone.
With 4 tools, this server is well-scoped for its purpose of CV generation and formatting. Each tool earns its place by covering essential steps: setup, template creation, and output generation in two common formats. The count is neither too thin nor excessive for the domain.
The tool set covers the core CV creation workflow from setup to final output, with no obvious dead ends. A minor gap exists in the lack of tools for updating or deleting CV data, but agents can work around this by regenerating from scratch, and the domain focus on generation rather than management makes this acceptable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate tailored, ATS-optimized resume PDFs and cover letters from a job description, over MCP.
Resume builder with native MCP — create and edit resumes from your AI assistant.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Guid-Lab/cv-forge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
