Enables modification of LaTeX resume documents, ensuring formatting is preserved while updating bullet points and skills sections.
Click on "Install 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 resume to this data engineer job description."
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 MCP server that tailors your LaTeX resume to a job description using Claude. It returns a structured diff — keywords, gap summary, before/after bullet changes, and a guardrails report — without touching your formatting or inventing new facts.
You (or Claude Desktop)
│
│ job_description + resume_content
▼
tailor_resume tool ←── this server
│
│ calls Claude Sonnet with a constrained system prompt
▼
structured JSON response
│
├── jd_keywords top 3–5 repeated JD terms
├── gap_summary skills JD wants that aren't in your resume
├── bullet_changes before/after for each modified bullet only
├── skills_changes before/after for skills section (or null)
├── guardrails_report model's self-audit (new claims, removed metrics)
└── validation 5 deterministic checks run after the LLM responseWhat it will never do:
Add experiences, metrics, or skills not already in your resume
Remove numbers or percentages
Change LaTeX commands or document structure
Rewrite bullets you didn't ask it to touch
Related MCP server: Resume Forge MCP
server.py MCP server — exposes hello and tailor_resume tools
client.py Standalone MCP client (learning exercise / smoke test)
prompts.py System prompt that constrains Claude's output
guardrails.py Post-LLM validation (5 deterministic safety checks)
test_guardrails.py Offline unit tests for the guardrails module
pyproject.toml Project config and dependencies
.env Your ANTHROPIC_API_KEY (never committed)1. Clone and install
git clone <your-repo-url>
cd MCP_push1
uv sync2. Add your API key
Create a .env file:
ANTHROPIC_API_KEY=sk-ant-...Get a key at https://console.anthropic.com → API Keys.
3. Test in the MCP Inspector
uv run mcp dev server.pyOpen the URL it prints. You'll see two tools: hello and tailor_resume.
4. Run the offline guardrail tests
uv run python test_guardrails.pyAdd this to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"resume-tailor": {
"command": "/Users/your-username/.local/bin/uv",
"args": [
"--directory",
"/path/to/MCP_push1",
"run",
"server.py"
],
"env": {
"ANTHROPIC_API_KEY": "sk-ant-..."
}
}
}
}Why full paths? Claude Desktop spawns the server in a minimal environment that may not have your shell PATH. Full paths are required.
Restart Claude Desktop after saving. The resume-tailor server will appear
in the connectors list.
Once connected, ask Claude:
"Use the tailor_resume tool. Here's the job description: [paste JD]. Here's my resume: [paste LaTeX]."
Claude will call the tool automatically and explain the results to you.
Source | How to use |
Pasted text | Copy the JD text, pass it directly |
URL | Open the page, copy all text, paste it |
Open the PDF, copy text, paste it |
The tool takes plain text input. Claude Desktop can also read URLs and PDFs from your context window and pass the extracted text to the tool.
{
"jd_keywords": ["Python", "ETL", "SQL"],
"gap_summary": "No evidence of distributed systems experience.",
"bullet_changes": [
{
"section": "Acme Corp / Data Engineer",
"before": "\\resumeItem{Built pipeline tooling...}",
"after": "\\resumeItem{Built data pipeline tooling...}",
"rationale": "Targets 'ETL' keyword — no new facts added."
}
],
"skills_changes": { "before": null, "after": null, "rationale": null },
"guardrails_report": {
"new_claims": [],
"removed_metrics": [],
"formatting_changes": []
},
"validation": {
"passed": true,
"issues": []
}
}Five checks run after every LLM response:
Check | What it catches |
Self-reported new claims | Model admits hallucinating |
Self-reported removed metrics | Model admits stripping numbers |
"Before" not in resume | Model invented the source text |
LaTeX commands dropped | Formatting silently corrupted |
Word count >50% growth | Keyword stuffing |
If any check fails, validation.passed is false and issues lists exactly what went wrong.
Say hello — a health check tool. Always kept so we can confirm the server is alive.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| 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 burden. It indicates a simple, safe operation but lacks details on behavior, side effects, or return format.
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 short sentences, front-loaded with purpose, no extraneous 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?
For a simple health check tool, purpose is clear, but missing parameter explanation reduces completeness; has output schema but return values not described.
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 required 'name' parameter, and the description does not explain its role (e.g., used in greeting).
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 is a health check ('Say hello — a health check tool'), distinguishing it from sibling 'tailor_resume' which handles resume tailoring.
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?
Implies use for checking server health ('Always kept so we can confirm the server is alive'), but no explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tailor a LaTeX resume to match a job description.
Sends both inputs to Claude with a constrained system prompt that enforces:
No hallucinated facts or metrics
LaTeX formatting preserved exactly
Only experience bullets and skills section modified
Structured JSON output with before/after diffs and a guardrails report
Args: job_description: Full text of the job posting (paste directly) resume_content: Full LaTeX source of the resume (paste directly)
Returns: JSON string with keys: jd_keywords, gap_summary, bullet_changes, skills_changes, guardrails_report
| Name | Required | Description | Default |
|---|---|---|---|
| resume_content | Yes | ||
| job_description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully covers behavioral traits: it explains the internal process (sends inputs to Claude with a constrained system prompt), lists specific constraints (no hallucination, preserve LaTeX, only modify certain sections), and describes the output format.
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 moderately long but well-structured: a summary sentence, bulleted constraints, then parameter and return descriptions. It is front-loaded with purpose. The 'Args:' and 'Returns:' sections add clarity without being verbose.
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 purpose, behavior, parameters, and return format. It references an output schema ('returns JSON string with keys...'). Given the tool's complexity (2 params, no annotations, no nested objects), the description is comprehensive.
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 compensates by fully explaining both parameters: 'job_description' (full text of job posting, paste directly) and 'resume_content' (full LaTeX source). This adds meaning 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 the tool 'Tailor a LaTeX resume to match a job description', specifying a clear verb ('tailor') and resource ('LaTeX resume'). It distinguishes itself from the only sibling 'hello', which is unrelated.
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 explains when to use the tool (to tailor a resume) but does not provide explicit guidance on when not to use it or mention alternatives. The context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools serve completely distinct purposes: hello is a health check, and tailor_resume is the core functionality. No overlap or ambiguity.
The naming conventions are inconsistent: 'hello' is a bare verb while 'tailor_resume' follows a verb_noun pattern. Even with only two tools, the mismatch is notable.
With only two tools, the server feels under-scoped. A resume tailoring service would benefit from more tools covering related operations, such as validation or keyword extraction.
The server lacks essential operations beyond the core tailoring task. No support for resume validation, multiple version management, or user feedback mechanisms, leaving significant gaps.
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.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nishtobehonest/latex-resume-tailor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
